diff --git a/redes_internet.md b/redes_internet.md index fae71fe..3ac2769 100644 --- a/redes_internet.md +++ b/redes_internet.md @@ -1,4 +1,6 @@ -# 1. Instala Multus (opcional, para múltiples redes) +# 1. Guía avanzada de Multus en Kubernetes + +## 1.1 Instala Multus (opcional, para múltiples redes) Multus permite que un pod tenga más de una interfaz de red (multi-homed), útil para appliances, firewalls, balanceadores, gateways, etc. Instálalo si necesitas conectar pods a varias redes físicas o VLANs (por ejemplo, mediante bridges y NADs). @@ -16,7 +18,7 @@ kubectl get pods -n kube-system | grep multus --- -# 2. (Opcional) Quita el taint del nodo master para poder programar pods en él +## 1.2 (Opcional) Quita el taint del nodo master para poder programar pods en él Por defecto, Kubernetes no programa pods de usuario en el nodo principal (control-plane). Elimina este bloqueo para poder desplegar aplicaciones ahí. @@ -24,92 +26,141 @@ Por defecto, Kubernetes no programa pods de usuario en el nodo principal (contro kubectl taint nodes --all node-role.kubernetes.io/control-plane- kubectl taint nodes --all node-role.kubernetes.io/master- ``` -## Nota: Uso de taints en nodos control-plane (alta disponibilidad y ejecución de cargas) - -### ¿Qué es un taint? - -* Un **taint** en Kubernetes es una marca especial que se pone a un nodo para **evitar que los pods se programen ahí**, salvo que declaren una “toleration” explícita. -* Se usa para reservar nodos solo para tareas especiales (por ejemplo, el control-plane). -* Por defecto, los nodos control-plane llevan un taint: - - * `node-role.kubernetes.io/control-plane:NoSchedule` - -### ¿Por qué quitar el taint? - -* Si quieres que **los nodos control-plane puedan ejecutar pods de usuario** (además del plano de control), necesitas **quitar el taint**. -* Esto es común en clústeres pequeños o medianos, donde **todos los nodos cumplen doble función** (alta disponibilidad y ejecución de cargas). --- -### **Comandos para quitar el taint de todos los nodos control-plane:** +## 1.3 Crea el bridge físico en todos los nodos + +Para que Multus pueda conectar pods a una red física o VLAN, debes crear un bridge Linux con el mismo nombre en **todos** los nodos del clúster. Ejemplo usando NetworkManager/nmcli: ```bash -kubectl taint nodes --all node-role.kubernetes.io/control-plane- -kubectl taint nodes --all node-role.kubernetes.io/master- +# 1. Crear el bridge (br-srv) y ponerle IP si quieres conectividad L3 +nmcli con add type bridge ifname br-srv con-name br-srv +nmcli con mod br-srv ipv4.addresses 192.168.200.1/22 +nmcli con mod br-srv ipv4.method manual +nmcli con up br-srv + +# 2. Crear la VLAN asociada (vlan20) sobre el bond +nmcli con add type vlan ifname vlan20 dev bond0 id 20 con-name vlan20 +nmcli con mod vlan20 ipv4.method disabled ipv6.method ignore +nmcli con mod vlan20 master br-srv connection.slave-type bridge +nmcli con up vlan20 ``` -* El `-` final indica “quitar”. -* Ejecuta ambos para máxima compatibilidad entre versiones. - -### **Comando para añadir el taint (dejar el nodo solo como control-plane):** - -```bash -kubectl taint nodes NOMBRE_DEL_NODO node-role.kubernetes.io/control-plane=:NoSchedule -``` - -* Así, ese nodo **solo ejecuta el plano de control** (salvo pods con toleration específica). +* **IMPORTANTE:** Repite en todos los nodos, y asigna una IP distinta del mismo rango a cada uno si es posible. +* El bridge debe estar **UP y con IP activa** para funcionar correctamente a nivel L2/L3. --- -# 3. Test rápido de Multus (NAD + pod con 2 interfaces) +## 1.4 Crea la NetworkAttachmentDefinition (NAD) -Puedes comprobar que Multus funciona creando una red secundaria y un pod de prueba con dos interfaces (una por defecto, una secundaria). +Ejemplo: -En la carpeta `/opt/cni/bin/multus/` de tu repositorio, debes tener: +```yaml +apiVersion: "k8s.cni.cncf.io/v1" +kind: NetworkAttachmentDefinition +metadata: + name: br-srv + namespace: default +spec: + config: '{ + "cniVersion": "0.3.1", + "type": "bridge", + "bridge": "br-srv", + "ipam": { + "type": "host-local", + "subnet": "192.168.200.0/22", + "rangeStart": "192.168.200.100", + "rangeEnd": "192.168.200.200" + } + }' +``` -* `multus/nad-br-servicios.yaml` (NetworkAttachmentDefinition) -* `multus/test-multus-pod.yaml` (pod Alpine multi-homed) - -**Despliega la NAD:** +Despliega: ```bash kubectl apply -f multus/nad-br-servicios.yaml ``` -**Despliega el pod de test:** +--- -```bash -kubectl apply -f multus/test-multus-pod.yaml +## 1.5 Despliega pods multi-homed de prueba + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: multus-test + annotations: + k8s.v1.cni.cncf.io/networks: br-srv +spec: + containers: + - name: alpine + image: alpine + command: ["sleep", "infinity"] + securityContext: + capabilities: + add: ["NET_ADMIN"] ``` -**Comprueba las interfaces:** +--- + +## 1.6 Verifica la conectividad L2/L3 entre pods ```bash kubectl exec -it multus-test -- sh ip a ``` -* El pod debe mostrar una interfaz extra (además de la de Flannel), conectada a tu red secundaria (`br-servicios`, etc.). +* Deberías ver dos interfaces: una de Flannel (eth0) y una de la red secundaria (net1). +* **IMPORTANTE:** Si el bridge físico (`br-srv`) está up pero SIN IP, la conectividad entre pods en nodos diferentes **NO funcionará**. Los bridges deben tener una IP asignada y activa. -**Para limpiar:** +### **¿Por qué es necesario que el bridge tenga IP?** + +* El bridge sólo se comporta como una red L2 completa entre nodos cuando está “activo”, es decir, con una IP asociada en todos los hosts. +* Si no tiene IP, sólo funcionará el tráfico entre pods del mismo nodo (unicast y broadcast entre nodos puede no funcionar). +* Al asignar una IP al bridge, Linux activa la tabla ARP y gestiona correctamente los vecinos y el reenvío entre interfaces del bridge. + +--- + +## 1.7 Limpieza de recursos ```bash kubectl delete pod multus-test +kubectl delete pod multus-test2 +kubectl delete -f multus/nad-br-servicios.yaml ``` --- -> **Nota:** Puedes crear tantas NADs (NetworkAttachmentDefinition) como bridges/VLANs quieras conectar a pods específicos (con Multus), ideal para appliances de red, gateways, SDN, pruebas de seguridad, etc. +## 1.8 Ejemplo de estructura de archivos + +``` +multus/ +├── nad-br-servicios.yaml +├── test-multus-pod.yaml +├── test-multus-pod2.yaml +└── readme.md +``` --- -# 4. Instalación y configuración de MetalLB (LoadBalancer local) +## 1.9 Resumen rápido + +* Multus + bridge = pods multi-homed en redes físicas. +* El bridge **debe estar vivo y con IP** en todos los nodos. +* Sin IP en el bridge, no hay tráfico entre pods en nodos distintos. +* Puedes crear tantas NAD como bridges/VLANs requieras. + +--- + +# 2. Instalación y configuración de MetalLB (LoadBalancer local) MetalLB permite asignar IPs flotantes de tu red LAN a servicios `LoadBalancer`, igual que hacen los clústeres en la nube. Es fundamental si quieres exponer servicios como ingress, dashboards, etc., accesibles desde tu red local. --- -## a) Instala MetalLB +## 2.1 Instala MetalLB ```bash kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml @@ -119,7 +170,7 @@ Esto crea el namespace `metallb-system` y despliega los pods necesarios. --- -## b) Define un pool con múltiples rangos +## 2.2 Define un pool con múltiples rangos En lugar de crear múltiples `IPAddressPool` por separado, puedes declarar varios rangos de IP en un **solo** `IPAddressPool`. Esto simplifica la gestión. @@ -164,7 +215,7 @@ kubectl apply -k metallb/ --- -## c) Asignar una IP concreta al Service (`loadBalancerIP`) +## 2.3 Asignar una IP concreta al Service (`loadBalancerIP`) Puedes indicar directamente la IP deseada usando el campo `loadBalancerIP`, y MetalLB la asignará si pertenece a uno de los rangos definidos. @@ -207,7 +258,7 @@ MetalLB seleccionará automáticamente una IP libre de **cualquier** rango decla --- -## d) Verificar los resultados +## 2.4 Verificar los resultados ```bash kubectl get svc