Actualizar redes_internet.md

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-
+# 1. Crear el bridge (br-srv) y ponerle IP si quieres conectividad L3 
-kubectl taint nodes --all node-role.kubernetes.io/master-
+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”.
+* **IMPORTANTE:** Repite en todos los nodos, y asigna una IP distinta del mismo rango a cada uno si es posible.
-* Ejecuta ambos para máxima compatibilidad entre versiones.
+* El bridge debe estar **UP y con IP activa** para funcionar correctamente a nivel L2/L3.
-
-### **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).
 
 ---
 
-# 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)
+Despliega:
-* `multus/test-multus-pod.yaml`   (pod Alpine multi-homed)
-
-**Despliega la NAD:**
 
 ```bash
 kubectl apply -f multus/nad-br-servicios.yaml
 ```
 
-**Despliega el pod de test:**
+---
 
-```bash
+## 1.5 Despliega pods multi-homed de prueba
-kubectl apply -f multus/test-multus-pod.yaml
+
+```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