Todos los pods necesitan una IP y comunicarse con otros pods. Quien entrega esto es la CNI (Container Network Interface). Pero hay una trampa que hace caer a mucha gente: no toda CNI aplica NetworkPolicy.

Ya vi un clúster con políticas de red creadas, revisadas y “aprobadas” — y ningún efecto. Flannel estaba manejando la red; la política era solo un objeto decorativo en etcd.

Sello del curso: probado en Kubernetes 1.35 y Ubuntu 24.04.

Qué hace la CNI

• Asigna IP al pod.
• Configura rutas entre nodos.
• Gestiona el reenvío entre pods y Services (junto con kube-proxy).
• En algunas implementaciones, aplica políticas de red.

Modelos comunes:

Modelo	Cómo funciona	Ejemplos
Overlay (VXLAN)	encapsula paquetes entre nodos	flannel, Canal
Enrutado	rutas/BGP entre nodos	Calico (BGP), Cilium (native routing)
eBPF	datapath en el kernel	Cilium

flannel: simple y honesto

flannel es excelente para laboratorio: se instala fácil, funciona y tiene poco mantenimiento. Crea una red VXLAN y distribuye un /24 por nodo.

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
kubectl -n kube-flannel get pods -o wide

Limitación importante: flannel no implementa NetworkPolicy. El objeto es aceptado por la API y almacenado, pero no hay agente aplicando la regla. Si necesitas segmentar, necesitas Cilium, Calico u otro motor de políticas.

Cilium y Calico: política de verdad

• Cilium usa eBPF, tiene observabilidad de flujo (Hubble), políticas L3/L4/L7 y puede reemplazar a kube-proxy.
• Calico es maduro, basado en iptables/eBPF, con políticas y BGP.

En este curso no vamos a cambiar la CNI ahora — cambiar la CNI en un clúster en vivo requiere una ventana de mantenimiento. Pero vamos a entender lo suficiente para no caer en el cuento de flannel.

NetworkPolicy en 5 minutos

Una política selecciona pods por etiqueta y define quién puede entrar o salir.

Default-deny de ingress en el namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: demo
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Permitir solo desde el pod client:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-client
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app: server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: client
      ports:
        - protocol: TCP
          port: 80

Permitir desde ingress-nginx:

  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx

Permitir probes del kubelet (que vienen de la IP del nodo):

  ingress:
    - from:
        - ipBlock:
            cidr: 192.168.56.0/24

Laboratorio: probar (o no) la política

Crea el namespace y dos pods:

kubectl create ns demo
kubectl -n demo run server --image=nginx:1.27 --port=80 --labels=app=server
kubectl -n demo run client --image=curlimages/curl:8.10.1 --labels=app=client --command -- sleep 3600

Prueba antes de la política:

kubectl -n demo exec client -- curl -s -o /dev/null -w '%{http_code}\n' http://server
# 200

Aplica el default-deny y el allow-client:

kubectl apply -f default-deny.yaml
kubectl apply -f allow-client.yaml

Prueba de nuevo:

kubectl -n demo exec client -- curl -s -o /dev/null -w '%{http_code}\n' http://server

• En Cilium/Calico: el cliente autorizado sigue recibiendo 200; un pod sin la etiqueta client recibe timeout.
• En flannel: probablemente todos sigan obteniendo 200 — la política no se aplica.

Esta prueba es la más importante del capítulo. Si no bloquea, tu segmentación es ficción.

Cambiar la CNI sin derribar todo

Si decidiste migrar a Cilium:

1. Planifica una ventana de mantenimiento.
2. Haz backup (etcd/Velero).
3. Instala Cilium con kubeProxyReplacement=false (mantiene kube-proxy) e IPAM compatible con el podCIDR.
4. Valida cilium status en todos los nodos.
5. Elimina flannel nodo a nodo, con drain/cordon, garantizando pods saludables.
6. Aplica las NetworkPolicies y ejecuta la prueba negativa.
7. Ten un plan de rollback: reinstalar flannel y restaurar la configuración de CNI.

No hagas esto en producción sin ensayo previo. En laboratorio, rompe a gusto.

Errores comunes

Síntoma	Causa probable
Pods Pending o NotReady	CNI no instalada o DaemonSet con error
DNS roto	CoreDNS sin red o política bloqueando el 53
Política “no hace nada”	CNI sin soporte para NetworkPolicy
Probes fallando después de aplicar la política	kubelet bloqueado; permite la IP del nodo
Tráfico entre namespaces bloqueado	falta de un namespaceSelector explícito
Agotamiento de IP	CIDR pequeño para el número de pods

Checklist

• [ ] Sé qué CNI está en el clúster.
• [ ] Sé si aplica NetworkPolicy.
• [ ] Probé default-deny con un pod no autorizado.
• [ ] Habilité DNS y probes.
• [ ] Tengo plan de rollback si cambio la CNI.
• [ ] Documenté las políticas en el repositorio.

Glosario

• CNI: interfaz que configura la red de los pods.
• overlay: red encapsulada sobre la red física.
• NetworkPolicy: regla de ingress/egress por selector.
• default-deny: niega todo lo que no esté explícitamente permitido.
• eBPF: ejecución de programas en el kernel, utilizada por Cilium.

Siguiente

Ahora que la red está bajo control, vamos a organizar el clúster: namespaces, etiquetas, cuotas, PDB y lo que realmente protege una carga durante un mantenimiento.

Siguiente: Curso Kubernetes 07 — Namespaces, etiquetas, cuotas y PDB