Entender las diferencias entre Azure CNI, CNI Overlay y Kubenet es clave para tomar buenas decisiones de arquitectura de red en AKS. El modelo de red que elijas determina cómo se comunican los pods, cómo se asignan las direcciones IP y qué capacidades quedan disponibles en tu cluster. Las tres opciones permiten la conectividad entre pods, pero se diferencian en su implementación, su rendimiento y su escalabilidad. Esta visión técnica analiza las principales diferencias entre Azure CNI (en sus modos tradicional y overlay) y Kubenet, con foco en la gestión de direcciones IP, el rendimiento de red y las capacidades de integración, para ayudarte a definir tu estrategia de red en AKS.
Gestión de direcciones IP
En el Azure CNI tradicional, cada pod recibe una dirección IP directamente desde la subred de tu Azure Virtual Network. Esto convierte a los pods en ciudadanos de primera clase dentro de tu VNet y habilita la comunicación directa con otros recursos de tu entorno de Azure. Las IPs de los pods son enrutables y cualquier recurso con conectividad a la subred puede acceder a ellas.
Azure CNI ahora también ofrece un modo Overlay, en el que solo los nodos del cluster se despliegan en una subred. A los pods se les asignan direcciones IP desde un CIDR privado lógicamente distinto al de la VNet que aloja a los nodos. El tráfico entre pods y nodos dentro del cluster utiliza una red Overlay, mientras que la traducción de direcciones de red (NAT) usa la IP del nodo para alcanzar recursos fuera del cluster. Con esta solución se ahorra una cantidad importante de direcciones IP y se puede escalar el cluster a tamaños mucho mayores.
Kubenet también implementa una red overlay. Los pods reciben direcciones IP de un espacio de direcciones independiente que no forma parte de tu VNet. Cuando los pods necesitan comunicarse con recursos fuera del cluster, Kubenet usa NAT para enrutar el tráfico a través de la IP del nodo. Esto agrega un salto de red adicional, pero conserva las direcciones IP de la VNet, ya que solo los nodos requieren IPs de tu subred.
Requisitos de espacio en la subred
Cuando se usa Azure CNI tradicional, la planificación de la subred requiere especial atención, ya que cada pod potencial necesita una IP dedicada de tu subred. Esto significa que debes asignar una subred lo suficientemente grande para alojar todos los nodos y el máximo de pods posibles. Por ejemplo, si cada nodo puede ejecutar 30 pods y planeas escalar a 10 nodos, necesitarás al menos 300 direcciones IP para los pods, además de IPs adicionales para los nodos. Este requisito muchas veces obliga a elegir rangos CIDR más amplios y puede impactar el diseño general de tu red.
Azure CNI Overlay ofrece un uso más eficiente de las direcciones IP al asignar un espacio /24 a cada nodo desde un CIDR privado especificado durante la creación del cluster. El bloque /24 es fijo y admite hasta 250 pods por nodo. Puedes reutilizar el mismo espacio CIDR de pods en varios clusters AKS independientes dentro de la misma VNet, lo que amplía considerablemente el espacio de IPs disponible para aplicaciones en contenedores.
Kubenet también ofrece un uso eficiente de IPs, ya que solo requiere IPs de la VNet para los nodos. Los pods utilizan un rango CIDR interno para la red overlay, normalmente con valor predeterminado 10.244.0.0/16, que no consume el espacio de direcciones de tu VNet. Esto convierte a Kubenet en una buena opción en entornos con disponibilidad limitada de IPs o cuando se trabaja con restricciones estrictas. Sin embargo, esa eficiencia tiene como contrapartida la necesidad de configuración adicional de enrutamiento mediante User Defined Routes (UDRs).
Rendimiento de red
El Azure CNI tradicional ofrece un rendimiento de red superior gracias a su modelo de integración directa. Como los pods tienen conectividad directa con la VNet sin pasar por una red overlay, la sobrecarga en el stack de red es mínima. Los paquetes fluyen directamente entre los pods y otros recursos de la VNet sin capas adicionales de encapsulación o traducción, lo que se traduce en menor latencia y mayor throughput para los workloads con uso intensivo de red.
Azure CNI Overlay mantiene un rendimiento comparable al de las VMs en una VNet. No es necesario aprovisionar rutas personalizadas ni recurrir a métodos de encapsulación para tunelizar el tráfico entre pods, lo que entrega un rendimiento de conectividad equivalente al de las VMs en una VNet.
Kubenet introduce sobrecarga adicional de red porque requiere NAT y enrutamiento a través de la interfaz de red del nodo. Cada paquete tiene que ser procesado por la red overlay y traducido entre la IP interna del pod y la IP externa del nodo. Aunque este impacto es mínimo para muchas aplicaciones, puede notarse en escenarios con altos requisitos de throughput o workloads sensibles a la latencia.
Control con Network Security Groups (NSG)
Azure CNI funciona con NSGs a nivel de subred y de interfaz de red, y las reglas pueden apuntar a las IPs de los pods, ya que forman parte de la VNet. Si bien los NSGs no se pueden adjuntar directamente a pods individuales, sí puedes crear reglas específicas dirigidas a pods o grupos de pods a través de sus IPs de la VNet.
Con Azure CNI Overlay, el tráfico pod a pod no se encapsula y se aplican las reglas de NSG de la subred. Para que el cluster funcione correctamente se requieren reglas específicas, incluido el tráfico entre los rangos CIDR de nodos y de pods. Se recomienda usar políticas de red para controlar el tráfico de los workloads.
Con Kubenet, el control de seguridad de red se limita al nivel de nodo, ya que los pods no tienen IPs directas de la VNet. Las reglas de NSG solo pueden aplicarse a la interfaz de red del nodo, lo que significa que todos los pods de un nodo comparten las mismas reglas de seguridad. Esta limitación dificulta implementar políticas de red específicas por pod y puede requerir soluciones alternativas, como Kubernetes Network Policies, para un control de tráfico más granular dentro del cluster.
Integración con la VNet
El Azure CNI tradicional ofrece una integración integral con la VNet y permite a los pods comunicarse directamente con cualquier recurso de tu entorno Azure conectado a la VNet. Esto incluye servicios como SQL Managed Instances, Azure Cache for Redis o recursos en VNets emparejadas. Como los pods reciben sus IPs directamente desde la subred de la VNet, pueden establecer conexiones directas sin configuración de red adicional, lo que lo vuelve ideal para escenarios que requieren una integración fluida con otros servicios de Azure.
Azure CNI Overlay ofrece integración con la VNet mediante NAT, donde el tráfico saliente de los pods utiliza la IP del nodo. Aunque a los pods no se puede acceder directamente desde fuera del cluster, puedes publicar las aplicaciones de los pods como servicios Kubernetes Load Balancer para que sean alcanzables en la VNet.
Kubenet ofrece capacidades de integración con la VNet más limitadas. Si bien los pods aún pueden comunicarse con recursos externos, esa comunicación requiere UDRs para enrutar correctamente el tráfico entre la red overlay de pods y la VNet. Esta complejidad adicional de enrutamiento puede afectar la conectividad con ciertos servicios de Azure y puede requerir configuración extra al trabajar con peering de VNets o escenarios de red híbrida. Además, los requisitos de enrutamiento se vuelven más complejos a medida que crece tu arquitectura de red.
Gestión de tablas de rutas y complejidad de configuración
La gestión de tablas de rutas varía bastante entre las opciones. El Azure CNI tradicional simplifica la gestión de rutas porque los pods se comunican directamente en la VNet y no hace falta agregar entradas adicionales para manejar el tráfico de los pods. La configuración de enrutamiento se mantiene sencilla incluso a medida que el cluster escala. La contrapartida está en la complejidad inicial de configuración, que requiere una planificación cuidadosa de las direcciones IP.
Azure CNI Overlay simplifica la red de pods porque, a diferencia de Kubenet, no requiere UDRs para la conectividad básica. Aunque sí exige configurar reglas específicas de NSG para el correcto funcionamiento del cluster, la solución gestiona automáticamente el enrutamiento pod a pod y mantiene un rendimiento comparable al de la comunicación tradicional en VNet. Las UDRs pueden seguir siendo necesarias para escenarios específicos como tunelización forzada o requisitos de enrutamiento personalizados.
Kubenet utiliza UDRs y reenvío de IP para la conectividad de los pods, que el servicio AKS crea y mantiene de forma automática por defecto. Si bien puedes optar por aportar tu propia tabla de rutas para una gestión personalizada, la configuración estándar no requiere mantenimiento manual. La principal limitación es que Azure admite un máximo de 400 rutas por UDR, lo que en la práctica limita tu cluster a 400 nodos. La configuración inicial es más simple que con Azure CNI tradicional, ya que no necesitas una planificación extensa de IPs; solo debes considerar las IPs de los nodos en tu subred. Sin embargo, la arquitectura UDR agrega un salto de red adicional que introduce una latencia menor en la comunicación de los pods, y no puedes compartir subredes entre múltiples clusters Kubenet.
Características adicionales
Cada opción de red admite distintas funciones avanzadas. El Azure CNI tradicional ofrece el soporte más amplio, incluyendo contenedores Windows, Azure Network Policies e integración con Application Gateway. Azure CNI Overlay admite contenedores Windows y varias opciones de políticas de red (Azure, Calico, Cilium), pero no puede usar Application Gateway como Ingress Controller. Ambos modos CNI admiten redes dual-stack, aunque Overlay tiene algunas limitaciones. Kubenet tiene un soporte más acotado: solo funciona con contenedores Linux y políticas de red Calico. Además, se limita exclusivamente a contenedores Linux, admite hasta 400 nodos con 250 pods por nodo y está restringido a Calico para políticas de red. No admite contenedores Windows ni funcionalidades avanzadas de red de Azure.
¿Cuál elegir?
La elección entre las opciones de red depende de los requisitos específicos de tus workloads y de las restricciones de tu infraestructura:
El Azure CNI tradicional es la mejor opción para workloads empresariales que requieren integración directa de red, alto rendimiento o integración avanzada con servicios de Azure. Elígelo cuando:
- Tienes espacio de direcciones IP disponible
- La mayor parte de la comunicación de los pods se dirige a recursos fuera del cluster
- Recursos fuera del cluster necesitan llegar directamente a los pods
- Necesitas funciones avanzadas de AKS como virtual nodes
- Se requiere integración con Application Gateway
Azure CNI Overlay es ideal para despliegues a gran escala con espacio limitado de direcciones IP. Elígelo cuando:
- Necesitas escalar a un gran número de pods pero tienes espacio limitado de IPs
- La mayor parte de la comunicación de los pods ocurre dentro del cluster
- Quieres una configuración de red más simple
- Necesitas soporte para contenedores Windows pero no requieres Application Gateway Ingress Controller.
- Quieres reutilizar rangos CIDR de pods entre distintos clusters
Kubenet funciona bien para workloads básicos en Linux y entornos con restricciones de IP. Elígelo cuando:
- Tienes workloads básicos solo en Linux
- Tienes restricciones de IP pero no necesitas la escala de CNI Overlay
- No necesitas funciones avanzadas de red
- Estás configurando entornos de desarrollo o pruebas
La elección del plugin de red para tu cluster AKS tiene implicaciones a largo plazo en escalabilidad, rendimiento y complejidad operativa. Comprender las características y limitaciones de cada opción es clave para tomar una decisión informada que se alinee con los requisitos de tu infraestructura y tus planes de crecimiento futuro. Ten presente que cambiar entre opciones de red normalmente exige recrear el cluster, así que esta decisión debe tomarse temprano en el proceso de planificación de AKS.
Una nota adicional: el 31 de marzo de 2028, la red kubenet para AKS quedará retirada. Considera migrar a Azure CNI Overlay como un reemplazo adecuado, que resuelve muchas de las limitaciones de Kubenet manteniendo un uso eficiente de las direcciones IP.
Contacta a DoiT hoy para conversar sobre cómo podemos ayudarte a llevar al máximo la eficiencia, la rentabilidad y la seguridad de tu entorno cloud. Con DoiT accedes a expertise cloud exclusivamente senior para consultoría, capacitación y soporte; estamos disponibles cuando necesites asesoría experta, una opinión externa, ayuda para adoptar nuevas tecnologías o apoyo para apagar incendios en producción.
Si te interesa profundizar en otros temas de seguridad y arquitectura cloud, revisa nuestros posts del blog de cloud engineering.