Redes de Contenedores y CNI en Kubernetes

El problema: “el Pod tiene IP” no explica por qué el flujo funciona

En los módulos anteriores seguiste un paquete por Linux y validaste una identidad TLS. Kubernetes añade otra capa de abstracción: un Pod puede cambiar de IP, un Service puede tener una IP virtual sin endpoints sanos y una NetworkPolicy puede existir sin que el CNI la aplique. Cuando un frontend no llega a una API, “revisa la red de Kubernetes” no es un diagnóstico. [1]

Aquí aprenderás a construir una explicación por planos: “el nombre resolvió el ClusterIP; kube-proxy eligió este endpoint; el CNI llevó el paquete al Pod remoto; la policy permitió o negó este puerto”. Esa secuencia conecta cada objeto de Kubernetes con una evidencia verificable.

Mapa mínimo: del Pod al Service y de vuelta al Pod

frontend Pod
   │ IP de Pod + namespace de red
   ▼
DNS / Service ── nombre → ClusterIP estable
   │
   ▼
kube-proxy ── DNAT hacia un endpoint real
   │
   ▼
CNI ── ruta directa u overlay VXLAN entre nodos
   │
   ▼
api Pod ── NetworkPolicy/CNI decide el flujo

Un Service ayuda a descubrir y balancear; no cifra, no autentica y no abre una excepción de firewall. Una NetworkPolicy define intención, pero sólo es control efectivo cuando el CNI correspondiente la aplica. [2]

Ruta de estudio y conexión con el roadmap

1. Distingue IP de Pod, ClusterIP y NodePort; cada una responde a una necesidad distinta.
2. Sigue una conexión desde Service hasta EndpointSlice y Pod.
3. Compara overlay VXLAN con routing directo para entender MTU y rutas.
4. Empieza con default deny y abre DNS más el flujo de negocio mínimo.

El módulo siguiente desciende otro nivel: si el datapath de Kubernetes no es suficiente para ver o controlar un comportamiento, eBPF permite observarlo y aplicar decisiones dentro del kernel.

Referencia técnica: modelo de red Kubernetes

Cada Pod tiene IP alcanzable y sus contenedores comparten network namespace. CNI provisiona interfaz, IP, ruta e IPAM. VXLAN encapsula L3 del Pod sobre underlay y reduce MTU; direct routing instala rutas a Pod CIDR y exige underlay alcanzable. [3]

ClusterIP es VIP estable; kube-proxy la redirige a Endpoints/EndpointSlices por iptables/IPVS. NodePort abre puerto por nodo. Service no es identidad, cifrado ni autorización. [2]

NetworkPolicy exige CNI con enforcement. policyTypes Ingress+Egress sin reglas es default deny de pods seleccionados; añada selector+puerto+protocolo. DNS necesita egress UDP/TCP 53. Selector vacío cubre namespace completo. [4]

La IP del Pod no es una abstracción decorativa

Cada Pod tiene IP alcanzable y CNI provisiona veth, dirección, ruta e IPAM. VXLAN encapsula IP-pod/TCP dentro de IP-nodo/UDP/VXLAN y reduce MTU; direct routing evita overhead pero exige rutas y anti-spoofing correctos en underlay. [3]

[eth][IP nodo A][UDP 4789][VXLAN][eth][IP pod A][TCP][payload]
                                    └─ MTU útil para payload disminuye

Service no equivale a conexión directa

ClusterIP estabiliza descubrimiento. Frontend usa 10.96.12.34:80; kube-proxy selecciona endpoint y DNAT hacia 10.244.2.20:8080. Service con selector correcto pero endpoints vacíos parece fallo de red, pero es descubrimiento/readiness. [2]

frontend → ClusterIP:80 → kube-proxy DNAT → api Pod:8080
                                          └─ CNI ruta/overlay/direct

NetworkPolicy es aditiva: conjunto permitido es unión de reglas que seleccionan Pod; no hay deny de prioridad superior. Empiece con aislamiento y abra selector+puerto+protocolo. [4]