Cerrábamos el módulo 3 señalando que la red de Rutas Norte es completamente plana: cualquier pod de rutas-norte-pro puede abrir una conexión a postgres-reservas:5432, y ningún cliente de internet puede llegar todavía a www.rutasnorte.example. Antes de poner puertas (las políticas de red de 04-06) y ventanas (el Ingress de 04-04), hay que entender cómo está construida la casa. Esta lección es la que explica qué hay realmente debajo de esa 10.244.x.x que ves en kubectl get pods -o wide, quién crea esa interfaz de red, por qué la IP de un Service no aparece en ninguna tarjeta de red de ninguna máquina, y cómo un paquete que sale de api-reservas acaba entrando en postgres-reservas. Es la lección más "de fontanería" del curso, y también la que hace que todo lo demás deje de parecer magia.

1. El modelo de red de Kubernetes y sus cuatro reglas
2. Por qué ese modelo simplifica todo lo demás
3. Los cuatro planos de comunicación
4. CNI: la interfaz que conecta el pod a la red
5. Los plugins: Flannel, Calico, Cilium y Weave Net
6. Superposición (VXLAN), enrutamiento nativo (BGP) y eBPF
7. Los rangos de direcciones del clúster
8. Cómo se implementa de verdad un ClusterIP: kube-proxy
9. Recorrido completo de un paquete en Rutas Norte
10. Comprobación práctica en minikube

Kubernetes no implementa la red. Lo que hace es imponer un contrato: define un modelo que cualquier implementación de red debe cumplir, y deja que otros lo cumplan como quieran. El contrato tiene cuatro reglas.

La cuarta regla parece redundante, pero es la que prohíbe explícitamente el modelo de Docker clásico. En un docker run -p 8080:80, el contenedor cree que es 172.17.0.4:80 mientras el resto del mundo lo ve como 192.168.1.10:8080. Esa discrepancia rompe cualquier protocolo que anuncie su propia dirección: bases de datos en clúster, sistemas de descubrimiento, registros de servicio. Kubernetes la elimina de raíz.

Fíjate en lo que no dice el contrato: nada sobre cómo se enrutan los paquetes, si hay encapsulación, qué rango de IPs se usa o si hay cortafuegos. Todo eso es libertad de implementación.

El modelo se resume en una frase: "IP por pod, red plana". Sus consecuencias son enormes.

• Los puertos dejan de ser un recurso escaso. En un mundo de mapeo de puertos, desplegar tres réplicas de api-reservas en el mismo nodo obliga a asignarles 3000, 3001 y 3002, y a que alguien lleve la cuenta. Con IP por pod, las tres escuchan en el 3000. El manifiesto no cambia según dónde caiga el pod.
• Las aplicaciones no necesitan saber que están en Kubernetes. Una aplicación que funciona en una máquina virtual funciona en un pod: abre su puerto y conecta a host:puerto. Esto es lo que permitió migrar tanto software sin reescribirlo.
• El descubrimiento se vuelve trivial. Como no hay NAT, la IP que el EndpointSlice de 02-05 apunta es directamente conectable. Sin esa garantía, cada Service tendría que traducir direcciones y puertos por nodo.
• La migración de pods es transparente. Un pod muere y otro nace con otra IP, pero la mecánica de conexión es idéntica.

El precio es que por defecto no hay ningún aislamiento. La regla 2 dice "todo pod puede hablar con todo pod", y eso es exactamente lo que significa: el pod más insignificante de rutas-norte-pro puede intentar conectar con postgres-reservas. Las NetworkPolicies de 04-06 existen precisamente para recortar ese permiso universal.

Cuando alguien dice "la red de Kubernetes" suele estar mezclando cuatro problemas distintos, con soluciones distintas.

Un error de diagnóstico muy común es atacar el plano equivocado. Si api-reservas no llega a postgres-reservas por IP de pod, el problema es del CNI. Si llega por IP de pod pero no por el nombre del Service, el problema es de kube-proxy o del DNS de 04-03. Separar los planos ahorra horas.

CNI (Container Network Interface) es una especificación de la CNCF, muy corta y deliberadamente aburrida: define cómo un runtime de contenedores le pide a un programa externo que conecte o desconecte un contenedor de una red. No es un producto: es un contrato entre dos partes.

La cadena de invocación al crear un pod es esta:

Los puntos que conviene fijar:

• Quien invoca al plugin es el kubelet a través del runtime (containerd, en nuestro clúster). El apiserver no toca la red.
• El plugin se instala como un binario en /opt/cni/bin y se configura con un fichero JSON en /etc/cni/net.d. Por eso los plugins se despliegan casi siempre como un DaemonSet (06-02): un pod por nodo que copia el binario y el fichero de configuración al arrancar y luego se queda ejecutando su agente.
• Las operaciones son ADD, DEL, CHECK y VERSION. Al borrar el pod se invoca DEL y la IP vuelve al pool.
• IPAM (IP Address Management) es un subcomponente: decide qué IP concreta se asigna dentro del rango que le toca al nodo.

Lo que hace el plugin en un ADD típico, traducido a comandos que ya conoces de Linux:

1. Crea un par veth (dos interfaces virtuales unidas como un cable).
2. Deja un extremo en el network namespace del host (con nombre tipo veth3a7f2c1@if3) y mueve el otro dentro del namespace del pod, donde se llama eth0.
3. Pide una IP al IPAM y se la asigna a eth0.
4. Añade la ruta por defecto del pod, apuntando al puente o a la puerta de enlace del nodo.
5. En el host, conecta su extremo al puente (cni0, docker0, cbr0) o crea la ruta correspondiente.
6. Devuelve al runtime la IP asignada, que acaba en status.podIP del pod.

Si el CNI falla o no está instalado, verás el síntoma clásico:

Pods eternamente en ContainerCreating con errores de sandbox casi siempre son problema de red del nodo, no de tu manifiesto.

Elegir plugin es una de las decisiones más duraderas de un clúster: cambiarlo con carga en producción es una operación delicada. Estos son los cuatro históricamente más usados.

Consecuencia práctica para Rutas Norte, y hay que subrayarla: si el clúster usa Flannel, las NetworkPolicies que escribas en 04-06 se aplicarán sin error y no harán absolutamente nada. El objeto se crea, kubectl get networkpolicy lo lista, y el tráfico sigue pasando. Es el fallo silencioso más peligroso de esta parte del curso, y por eso lo verificaremos explícitamente.

Los clústeres gestionados de 10-06 traen su propio plugin (Amazon VPC CNI, Azure CNI, el de GKE), que suele asignar a los pods IPs de la red real de la nube. Eso hace que un pod sea directamente enrutable desde otras máquinas de la VPC, con la contrapartida de consumir direcciones del espacio corporativo.

El problema que resuelven todos es el mismo: el pod 10.244.1.5 está en el nodo A y quiere hablar con 10.244.2.4, que está en el nodo B. La red física entre nodos no sabe nada de 10.244.0.0/16: si le entregas ese paquete tal cual, lo descarta.

Se construye una red virtual encima de la física. El nodo origen mete el paquete original entero dentro de un paquete UDP dirigido a la IP real del nodo destino (puerto 8472 en VXLAN), que lo desencapsula y lo entrega al pod.

• Ventaja decisiva: funciona sobre cualquier red, sin tocar routers ni pedir nada al equipo de redes. Por eso es el modo por defecto de tanta instalación.
• Coste: la cabecera añade unos 50 bytes, lo que reduce la MTU efectiva (de 1500 a 1450 típicamente) y provoca fragmentación si algo la ignora; hay trabajo extra de encapsular y desencapsular en cada paquete; y el tráfico es opaco para los cortafuegos y analizadores de la red física, que solo ven UDP entre nodos.

No se encapsula nada. Cada nodo anuncia por BGP a los routers de la red física: "el rango 10.244.2.0/24 se alcanza a través de mí". La red física aprende las rutas y entrega los paquetes de pod directamente.

• Ventaja: sin sobrecoste, MTU íntegra, el tráfico de pods es visible y filtrable con las herramientas de red existentes.
• Requisito: la red debe permitirlo. En un centro de datos propio con routers que hablen BGP, es lo ideal. En muchas nubes o en redes corporativas cerradas, no es posible y se cae de vuelta a encapsulación.

eBPF permite cargar programas verificados dentro del kernel de Linux y engancharlos a puntos concretos de la pila de red. Cilium lo usa para tomar decisiones de enrutamiento, balanceo y política antes de que el paquete recorra toda la maquinaria de iptables.

• Puede sustituir por completo a kube-proxy, eliminando las cadenas de iptables que veremos en el apartado 8.
• Escala mucho mejor: donde iptables degrada con miles de Services, eBPF usa tablas hash de coste constante.
• Habilita políticas con conocimiento de HTTP (por ruta y método) e identidad de carga de trabajo.
• A cambio, exige un kernel razonablemente reciente y sube el listón de conocimiento para depurar.

En un clúster conviven tres espacios de direcciones que no hay que confundir nunca.

El cluster CIDR global se reparte: el kube-controller-manager, con --allocate-node-cidrs, asigna a cada nodo una porción (por defecto un /24, es decir 254 pods útiles por nodo) y la escribe en spec.podCIDR del objeto Node. El IPAM del plugin CNI reparte IPs dentro de esa porción. Así se garantiza que dos nodos nunca asignen la misma IP.

Dónde se configuran:

Tres avisos que ahorran incidentes:

1. No se pueden cambiar en caliente. Cambiar el serviceCIDR de un clúster vivo no es una operación soportada; se planifica antes de crearlo.
2. No deben solaparse con la red corporativa. Si tu empresa usa 10.96.0.0/16 para servidores, los pods de Rutas Norte no podrán hablar con ellos: el nodo creerá que esas IPs son Services del clúster.
3. El /24 por nodo es un límite real. Un nodo grande con 300 pods se queda sin direcciones aunque le sobre CPU y memoria.

Aquí está la revelación de la lección. Cuando en 02-05 creaste el Service postgres-reservas con clusterIP: 10.96.140.22, esa dirección no se asignó a ninguna interfaz de ninguna máquina. Es una ficción. No responde a ping. No hay ningún proceso escuchando en ella.

Lo que existe son reglas de reescritura de destino instaladas en cada nodo por kube-proxy, un DaemonSet del namespace kube-system que observa la API y, cada vez que cambia un Service o un EndpointSlice, actualiza esas reglas.

Para cada Service, kube-proxy crea una cadena KUBE-SERVICES que casa por IP y puerto de destino, salta a una cadena KUBE-SVC-XXXX propia del Service, y de ahí reparte entre las cadenas KUBE-SEP-YYYY, una por endpoint, cada una con su regla DNAT.

De aquí salen tres hechos importantes:

• El balanceo es aleatorio por conexión, no por petición. Una conexión TCP larga (una sesión de PostgreSQL, un WebSocket) queda pegada a un pod hasta que se cierra. Por eso una API que multiplexa peticiones sobre pocas conexiones puede repartir mal la carga.
• La probabilidad es en cascada: con 3 endpoints, las reglas llevan 1/3, luego 1/2, luego el resto. Así sale uniforme.
• El coste es lineal: iptables evalúa reglas en orden. Con decenas de miles de Services, cada actualización obliga a reprogramar tablas enormes y aparecen latencias de sincronización. Es el motivo de que existan IPVS y eBPF.

IPVS es el balanceador de carga L4 del kernel de Linux, con tablas hash en lugar de listas de reglas.

En modo IPVS sí aparece una interfaz kube-ipvs0 en el nodo con las IPs de los Services asignadas, pero es una interfaz dummy: sirve para que el kernel acepte los paquetes, no para responder.

La regla mental que hay que llevarse: el Service es una regla, no una máquina. Si un ClusterIP no responde, no busques un proceso caído: busca endpoints vacíos (selector que no casa, como viste en 02-05) o un kube-proxy que no está sincronizando.

Sigamos una conexión real: el pod api-reservas-7d9f5c8b4-x2kp9 (10.244.1.5, nodo 1) abre una conexión a postgres-reservas:5432 (ClusterIP 10.96.140.22), cuyo único endpoint es 10.244.2.4 en el nodo 2. El clúster usa VXLAN.

Los detalles que importan:

• La resolución del nombre ocurre primero y es independiente de todo lo demás (04-03).
• El DNAT ocurre en el nodo de origen, antes de enrutar. El nodo 2 nunca ve la IP del Service.
• postgres-reservas ve como origen 10.244.1.5, la IP real del pod cliente, no la del nodo. Esto es la regla 2 (sin NAT de origen) y es lo que permite que las NetworkPolicies de 04-06 puedan identificar al emisor por sus etiquetas. Ojo: esto cambia cuando el tráfico entra desde fuera con externalTrafficPolicy: Cluster (04-02).
• conntrack es imprescindible: el kernel recuerda la traducción para deshacerla en la respuesta. Una tabla conntrack llena provoca conexiones que se pierden aleatoriamente bajo carga, un síntoma clásico en los picos de puentes de Rutas Norte.

Todo lo anterior se puede tocar con las manos en el perfil rutas-norte.

Es un truco muy útil: el mensaje de error te revela el rango exacto.

Las IPs de pod están en 10.244.0.x (el podCIDR del único nodo) y la del Service en 10.96.x.x. Rangos distintos, naturalezas distintas.

Ni rastro de 10.96.140.22. Ahora las reglas:

El comentario incluye <namespace>/<servicio>: es la forma más rápida de localizar las reglas de un Service concreto.

La imagen nicolaka/netshoot trae dig, curl, nc, tcpdump, traceroute e ipvsadm. Es la navaja suiza para depurar redes en Kubernetes.

Dentro del pod:

Si el paso 2 funciona y el 3 no, el CNI está bien y el problema es de Service o DNS. Si el 2 tampoco funciona, es el CNI o una política de red. Esa bifurcación es el 80 % del diagnóstico de red en Kubernetes.

• Confundir los tres rangos. Ver 10.96.x.x y buscar en qué nodo está ese pod es un clásico. Regla: 10.244.x.x es un pod (existe), 10.96.x.x es un Service (es una regla), 192.168.x.x es un nodo.
• Hacer ping a un ClusterIP. No responde y eso es normal: las reglas de kube-proxy solo casan TCP/UDP en el puerto declarado, no ICMP. Un ping fallido a un Service no prueba nada. Usa nc -zv o curl.
• Solapar el podCIDR o el serviceCIDR con la red corporativa. Provoca fallos incomprensibles al hablar con servicios externos, como la pasarela de pagos. Compruébalo antes de crear el clúster, no después.
• Ignorar la MTU con VXLAN. Conexiones que abren bien pero se cuelgan al transferir bloques grandes (una restauración de PostgreSQL, una respuesta JSON de 2 MB) suelen ser MTU mal ajustada. Diagnóstico: ping -M do -s 1400 <ip>.
• Elegir Flannel y escribir NetworkPolicies. Se aplican sin error y no filtran nada. Antes de confiar en una política, verifica que el CNI la implementa con una prueba real.
• Culpar al CNI de todo. Antes de eso, comprueba los planos por orden: localhost dentro del pod, IP de pod, ClusterIP, nombre DNS. El primero que falle señala la capa culpable.
• Consejo: guarda un alias para el pod de depuración. alias kshoot='kubectl run netshoot-$RANDOM --rm -it --restart=Never --image=nicolaka/netshoot -- bash'. Con --rm no dejas basura en el clúster.
• Consejo: en producción, revisa las métricas de conntrack (nf_conntrack_count frente a nf_conntrack_max). En los picos de puentes de Rutas Norte, la tabla llena se manifiesta como errores de conexión intermitentes sin ningún pod caído.

Sobre el perfil rutas-norte, documenta: el podCIDR del nodo, el serviceCIDR, la IP del nodo, y las IPs de los pods y Services de rutas-norte-pro. Clasifica cada dirección en su rango y explica cuáles existen físicamente y cuáles no.

Elige el Service redis-cache. Demuestra con tres comprobaciones que su IP no existe en ninguna interfaz, que sí existen reglas de iptables para ella, y que aun así se puede conectar. Explica quién hace la traducción y en qué nodo ocurre.

Un compañero dice que api-reservas "no ve la base de datos". Diseña una secuencia de comprobaciones, de la capa más baja a la más alta, que permita decidir si el problema es del CNI, del Service, del DNS o de la propia aplicación. Ejecútala con netshoot y anota qué salida esperarías en cada caso de fallo.

Ejercicio 1

Clasificación esperada:

Ejercicio 2

La traducción (DNAT) la hace el kernel del nodo donde corre el pod cliente, usando las reglas que kube-proxy programó a partir del EndpointSlice. El paquete sale del nodo ya con la IP real del pod destino.

Ejercicio 3

Secuencia de menor a mayor nivel, con la conclusión de cada fallo:

Cada escalón que funciona descarta una capa entera. El primero que falla nombra al culpable.

Ya sabes qué hay debajo de la red de Kubernetes. El modelo se apoya en cuatro reglas obligatorias —IP por pod, comunicación pod a pod sin NAT, los agentes del nodo alcanzan a sus pods, y la IP que el pod ve de sí mismo es la que ven los demás— y es esa uniformidad la que permite que las aplicaciones no sepan que están en un clúster y que los puertos dejen de ser un recurso a administrar. Distingues los cuatro planos de comunicación y sabes cuál diagnosticar primero cuando algo falla.

Has visto que Kubernetes delega la implementación en un plugin CNI, que el kubelet invoca a través del runtime al crear cada pod, y que hace un trabajo muy concreto: crear un par veth, pedir una IP al IPAM dentro del podCIDR del nodo y programar las rutas. Conoces las diferencias reales entre Flannel, Calico, Cilium y Weave Net, y en particular que Flannel no implementa NetworkPolicy, un detalle que condicionará la lección 04-06. Entiendes el compromiso entre encapsular con VXLAN (funciona en cualquier sitio, cuesta 50 bytes y MTU) y enrutar de forma nativa con BGP (gratis, pero exige colaboración de la red física), y por qué eBPF está desplazando a ambos enfoques en los clústeres exigentes.

Y sobre todo, has desmontado la ficción más útil de Kubernetes: el ClusterIP no existe. No está en ninguna interfaz, no responde a ping y no hay ningún proceso detrás. Solo hay reglas de iptables o entradas de IPVS que kube-proxy mantiene sincronizadas con los EndpointSlices, haciendo DNAT en el nodo de origen y deshaciéndolo en la respuesta gracias a conntrack. Has seguido un paquete de api-reservas a postgres-reservas de principio a fin y lo has comprobado en tu propio minikube.

Con la fontanería entendida, toca subir un piso. En 04-02 veremos que ClusterIP es solo uno de los cuatro tipos de Service, que cada uno se construye sobre el anterior, y cómo NodePort, LoadBalancer y ExternalName empiezan a abrir la plataforma al exterior: el primer paso para que un cliente que quiere comprar un billete de autobús pueda, por fin, llegar a tienda-web.