Este documento explica qué es Multus, qué problema resuelve y cómo encaja —y deja de encajar— en la arquitectura actual del clúster.
No es solo una guía técnica.
Es una reflexión arquitectónica.
Por defecto, Kubernetes utiliza una única red para los pods.
En nuestro caso, esa red está gestionada por Flannel.
Esto significa que:
En muchos casos esto es suficiente.
Pero existen escenarios donde puede ser necesario que un pod tenga más de una interfaz de red:
👉 Aquí es donde entra Multus.
Multus es un plugin CNI que permite que un pod tenga más de una interfaz de red.
Normalmente un pod tiene:
eth0 → red principal (Flannel)Con Multus puede tener:
eth0 → red principal (overlay interna)net1 → red secundaria (bridge físico, VLAN, etc.)net2 → redes adicionales si fueran necesariasEn términos simples:
👉 Permite que un pod sea multi-homed (conectado a varias redes).
Multus no sustituye a la red principal.
Funciona como una capa adicional que:
eth0.Esas redes adicionales se definen mediante objetos llamados:
Una NAD describe:
Ejemplo conceptual:
La NAD no crea el bridge.
Solo lo referencia.
Aquí es donde Multus deja de ser teórico y pasa a ser infraestructura real.
Para que funcione correctamente:
br-srv) debe existir en todos los nodos.Si el bridge no tiene IP activa:
👉 Multus depende directamente de la configuración de red Linux en cada servidor.
En nuestro caso, Multus se implementó principalmente para:
Es decir, no nació para microservicios.
Nació como soporte para virtualización dentro del clúster.
Desde el punto de vista del modelo que perseguimos con este clúster:
La virtualización tradicional dentro de Kubernetes empieza a generar fricción.
KubeVirt introduce:
En términos estratégicos:
👉 Contraviene parcialmente el modelo cloud-native que estamos intentando consolidar.
Por este motivo se está reconsiderando el enfoque.
En lugar de ejecutar VMs dentro de Kubernetes mediante KubeVirt, la línea evolutiva apunta hacia:
Esto aporta:
En este escenario, Multus deja de ser un componente central.
Y pasa a ser una herramienta puntual, casi heredada (legacy) dentro de la arquitectura.
No.
Multus es una herramienta potente y válida cuando:
Pero no debe utilizarse por defecto.
Debe existir una justificación arquitectónica clara.
Después de leer este documento debe quedar claro que:
Multus no es obligatorio.
Es una herramienta avanzada.
Y su uso debe estar alineado con la visión estratégica del sistema.
Redes múltiples cuando la arquitectura lo exige. Si no, simplicidad por diseño.