Qué es CNI en Kubernetes y para qué sirve
CNI conecta los sandboxes de Pods con la red mediante un contrato entre el runtime y plugins. Qué cubre, qué no hace y qué revisar al operarlo.
CNI en Kubernetes significa Container Network Interface: una especificación y un ecosistema de plugins que conectan los entornos de ejecución de contenedores con la red. Kubernetes necesita un plugin de red para que los Pods puedan comunicarse según el modelo de red del clúster. CNI no es un producto único ni un componente que, por sí solo, resuelva todo el tráfico entre Services, balanceadores y políticas de red.
Qué aporta CNI al clúster
Un plugin CNI es un programa que el runtime puede invocar cuando crea o elimina el sandbox de red de un Pod. Recibe información del contenedor y de una configuración de red, prepara interfaces y devuelve resultados como las direcciones asignadas. El estándar define cómo se pasan configuración, argumentos y resultados entre el runtime y el plugin; implementaciones como Calico, Cilium o Flannel añaden su propia arquitectura y capacidades.
En Kubernetes, el CNI instalado contribuye a implementar el modelo donde cada Pod obtiene una dirección y puede comunicarse con otros Pods según la red del clúster. El runtime de contenedores ejecuta el plugin: en versiones modernas de Kubernetes, kubelet dejó de gestionar directamente los binarios CNI y sus parámetros de red desde Kubernetes 1.24. Por eso, al diagnosticar un fallo, la versión y configuración de containerd o CRI-O importan junto con la del plugin y el plano de control.
La especificación CNI incluye operaciones de ciclo de vida como ADD para conectar un contenedor, DEL para retirar su conexión y CHECK para comprobar estado, además de la negociación de versiones. No obliga a que todos los plugins construyan la red de la misma forma. CNI es una interfaz de integración, no una receta universal de túneles, rutas o asignación de IP: los detalles dependen del plugin que se haya elegido y de sus valores de configuración.
-InfraCrew dice: Que aparezca «CNI» en la documentación del clúster no te dice qué plugin hizo el trabajo; mira los binarios y el runtime.-
Qué hace y qué no hace
CNI se centra en conectar interfaces de contenedores a una red. La asignación de IP puede formar parte del plugin principal o delegarse a un componente de IPAM. Algunos plugins configuran rutas, encapsulación, conectividad entre nodos y controles de red; otros delegan esas funciones en componentes aparte. La lista de funciones depende del proveedor, así que no asumas que dos instalaciones que cumplen la interfaz tienen idéntico rendimiento, política o requisitos de kernel.
El tráfico de Pods tampoco es toda la red Kubernetes. Los Services dan una dirección estable y distribuyen tráfico hacia un conjunto de Pods; la implementación puede usar kube-proxy u otra solución integrada. Ingress y Gateway gestionan entrada desde fuera del clúster con controladores propios. NetworkPolicy define reglas declarativas, pero aplicarlas requiere un plugin que la implemente. Instalar cualquier CNI no garantiza compatibilidad con todas estas funciones.
Instalación y ciclo de vida
Cada nodo debe tener la configuración y los binarios esperados por el runtime, además de una versión CNI compatible. La documentación de Kubernetes exige al menos compatibilidad con CNI 0.4.0 y recomienda el soporte de CNI 1.0.0 o posterior. La compatibilidad real también incluye la distribución y el plugin: comprueba la guía del proveedor para la versión concreta del clúster, el runtime, el sistema operativo y las opciones de red elegidas.
En una instalación nueva, el plano de control puede estar disponible antes de que exista red funcional para los Pods. El plugin debe instalarse y configurarse con los CIDR del clúster, parámetros de IPAM y requisitos del proveedor. En upgrades, conviene revisar primero la tabla de compatibilidad y el procedimiento soportado; cambiar binarios o configuración manualmente en los nodos puede dejar el runtime incapaz de crear nuevos sandboxes. La red del clúster es parte del camino de actualización, no una dependencia externa que se pueda improvisar después.
-InfraCrew dice: Un nodo Ready no demuestra que el plugin CNI esté sano; solo demuestra que el kubelet consiguió contar su versión de la historia.-
Diagnóstico operativo
Cuando un Pod queda en estado de creación, revisa eventos del Pod, logs del runtime y mensajes del plugin, además de los archivos de configuración y los binarios del nodo. Errores de asignación de IP, rutas repetidas, permisos o versiones incompatibles pueden parecer iguales desde la aplicación. Empieza por la operación que falló: ADD suele señalar creación de conexión; DEL puede dejar recursos residuales si algo interrumpió la limpieza.
Antes de sustituir un plugin, registra la configuración actual, CIDR, modo de encapsulación, soporte de NetworkPolicy, requisitos de kernel y compatibilidad con la versión de Kubernetes. Cambiar la capa de red puede afectar conectividad entre nodos, salida a servicios externos y políticas de seguridad. La interfaz común simplifica la integración, pero no hace intercambiables las implementaciones. El plugin es una decisión de arquitectura y de operación del clúster.
Diccionario de la Crew
CNI — Especificación para integrar runtimes de contenedores con plugins de red.
Pod — Unidad desplegable de Kubernetes que contiene uno o más contenedores con red compartida.
Sandbox — Entorno aislado que el runtime prepara para ejecutar un Pod.
IPAM — Gestión de asignaciones y reservas de direcciones IP.
NetworkPolicy — Recurso de Kubernetes que declara qué tráfico puede entrar o salir de determinados Pods.