Saltar al contenido principal

Container Network Interface (CNI) en Kubernetes

Kubernetes Header

La red de un cluster de Kubernetes no la implementa Kubernetes en sí: la delega a un plugin CNI (Container Network Interface). El kubelet conoce un contrato muy simple — "configura la red para este pod" — y deja que el plugin haga el trabajo: crear interfaces virtuales, asignar IPs, programar rutas y aplicar políticas.

Entender dónde vive esa configuración te ayuda a diagnosticar problemas de red que parecen "magia".

Dónde vive la configuración​

En cada nodo, la configuración del CNI está en:

/etc/cni/net.d/

Allí encontrarás uno o más archivos *.conf o *.conflist con la configuración del plugin instalado (Calico, Cilium, Flannel, Weave, AWS VPC CNI, etc.). Por ejemplo:

ls /etc/cni/net.d/
# 10-calico.conflist
# calico-kubeconfig

Y los binarios del plugin viven en:

/opt/cni/bin/

Si alguno de estos directorios está vacío o corrupto, los pods nuevos quedarán en estado ContainerCreating con error network plugin is not ready.

Cómo se invoca el plugin​

Cuando el kubelet va a arrancar un pod:

  1. Crea el sandbox del pod (un contenedor pause con su propio network namespace).
  2. Lee la primera config válida de /etc/cni/net.d/ (orden lexicográfico).
  3. Ejecuta el binario CNI correspondiente desde /opt/cni/bin/, pasando los datos por stdin.
  4. El plugin asigna IP, crea la interfaz dentro del namespace y devuelve el resultado.

Por eso kubectl get pod puede mostrar el pod como Pending o ContainerCreating durante segundos: está esperando a que el CNI devuelva la IP.

Comprobaciones rápidas cuando "la red no funciona"​

Desde el nodo afectado:

# ¿Hay configuración?
ls -l /etc/cni/net.d/

# ¿Existen los binarios?
ls /opt/cni/bin/

# ¿Qué dice el kubelet?
journalctl -u kubelet -n 200 --no-pager | grep -i cni

Desde el cluster:

# ¿Los pods del CNI están corriendo?
kubectl get pods -n kube-system -l k8s-app=calico-node      # ajusta el label al plugin
kubectl describe pod <cni-pod> -n kube-system
kubectl logs <cni-pod> -n kube-system

Si el pod del CNI está caído en un nodo, ese nodo no podrá programar pods nuevos aunque tenga CPU y memoria libre.

Cosas que vale la pena recordar​

  • La config de /etc/cni/net.d/ la suele instalar el DaemonSet del plugin. No la edites a mano salvo que sepas lo que haces; el DaemonSet la sobreescribirá.
  • Solo se usa el primer archivo (orden lexicográfico). Por eso los plugins se nombran 10-…, 20-…, etc.
  • Cambiar de CNI en un cluster en producción es una operación delicada: requiere drenar nodos y normalmente reiniciar la red de los pods.
  • Las NetworkPolicies solo funcionan si el plugin las implementa. Flannel "puro", por ejemplo, no lo hace; Calico y Cilium sí.

Conocer /etc/cni/net.d/ parece un detalle menor, pero es el primer lugar al que debes mirar cuando un nodo aparentemente sano deja de aceptar pods.