Comprender las diferencias entre Azure CNI, CNI Overlay y Kubenet es crucial para las decisiones de arquitectura de red de AKS, ya que las opciones de red determinan cómo se comunican tus pods, cómo se asignan las direcciones IP y qué capacidades están disponibles para tu clúster. Todas las soluciones permiten la conectividad de los pods, pero difieren en su implementación, características de rendimiento y consideraciones de escalabilidad. Este resumen técnico examina las diferencias clave entre Azure CNI (incluidos sus modos tradicional y superpuesto) y Kubenet, centrándose en la gestión de direcciones IP, el rendimiento de la red y las capacidades de integración para ayudarte a informar sobre tu estrategia de red AKS.
Gestión de direcciones IP
En la CNI Azure tradicional, cada pod recibe una dirección IP directamente de la subred de tu Red Virtual Azure. Esto significa que los pods son ciudadanos de red de primera clase dentro de tu VNet, lo que permite la comunicación directa con otros recursos de tu entorno Azure. Las IP de los pods son enrutables y puede acceder a ellas cualquier recurso que tenga conectividad de red con la subred.
Azure CNI ofrece ahora también un modo Superpuesto, en el que sólo se despliegan los nodos del clúster en una subred. A los pods se les asignan direcciones IP de un CIDR privado lógicamente distinto de la VNet que aloja los nodos. El tráfico de nodos y pods dentro del clúster utiliza una red superpuesta, mientras que la Traducción de Direcciones de Red (NAT) utiliza la dirección IP del nodo para llegar a recursos fuera del clúster. Esta solución ahorra una cantidad significativa de direcciones IP y te permite escalar tu clúster a un tamaño mucho mayor.
Kubenet también implementa una red superpuesta. 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 externos al clúster, Kubenet utiliza NAT para dirigir el tráfico a través de la dirección IP del nodo. Esto crea un salto de red adicional, pero conserva las direcciones IP de la VNet, ya que sólo los nodos necesitan IPs de tu subred.
Espacio de subred necesario
Cuando se utiliza Azure CNI tradicional, la planificación de la subred requiere una cuidadosa consideración, ya que cada pod potencial necesita una dirección IP dedicada de tu subred. Esto significa que debes asignar una subred lo suficientemente grande como para acomodar todos los nodos y sus pods potenciales máximos. Así, si cada nodo puede ejecutar 30 pods y planeas escalar a 10 nodos, necesitarás al menos 300 direcciones IP para los pods más IP adicionales para los propios nodos. Este requisito a menudo te obliga a elegir rangos CIDR mayores y puede repercutir en el diseño general de tu red.
Azure CNI Overlay ofrece una utilización más eficiente de las direcciones IP asignando un espacio de direcciones /24 a cada nodo a partir de un CIDR privado especificado durante la creación del clúster. El bloque /24 es fijo y puede soportar hasta 250 pods por nodo. Puedes reutilizar el mismo espacio CIDR de pods en varios clústeres AKS independientes de la misma VNet, ampliando significativamente el espacio IP disponible para aplicaciones en contenedores.
Kubenet también ofrece una utilización eficiente de las direcciones IP, ya que sólo requiere IPs de VNet para los propios nodos. Los pods utilizan un rango CIDR interno para la red superpuesta, normalmente por defecto 10.244.0.0/16, que no consume el espacio de direcciones de tu VNet. Esto hace que Kubenet sea una buena opción en entornos con disponibilidad limitada de IP o cuando se trabaja con restricciones estrictas de direcciones IP. Sin embargo, esta eficiencia conlleva la contrapartida de requerir una configuración de enrutamiento adicional a través de Rutas Definidas por el Usuario (UDR).
Rendimiento de la red
La CNI tradicional de Azure proporciona un rendimiento de red superior gracias a su modelo de integración directa en la red. Como los pods tienen conectividad directa con la VNet sin una red superpuesta, hay una sobrecarga mínima en tu pila de red. Los paquetes de red 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 una menor latencia y un mayor rendimiento para las cargas de trabajo intensivas en red.
Azure CNI Overlay mantiene un rendimiento comparable al de las máquinas virtuales en una VNet. No es necesario aprovisionar rutas personalizadas ni utilizar métodos de encapsulación para tunelizar el tráfico entre pods, lo que proporciona un rendimiento de conectividad entre pods equiparable al de las máquinas virtuales en una VNet.
Kubenet introduce una sobrecarga de red adicional porque requiere NAT y enrutamiento a través de la interfaz de red del nodo. Cada paquete debe ser procesado por la red superpuesta y traducido entre la dirección IP interna del pod y la dirección IP externa del nodo. Aunque este impacto en el rendimiento es mínimo para muchas aplicaciones, puede llegar a ser notable en escenarios con altos requisitos de rendimiento de red o cargas de trabajo sensibles a la latencia.
Control del Grupo de Seguridad de Red (NSG)
Azure CNI trabaja con las NSG a nivel de subred e interfaz de red, donde las reglas pueden dirigirse a las IP de los pods, ya que forman parte de la VNet. Aunque las NSG no pueden adjuntarse directamente a pods individuales, puedes crear reglas NSG específicas que se dirijan a pods individuales o grupos de pods a través de sus IP de VNet.
Con Azure CNI Overlay, el tráfico de pod a pod no se encapsula, y se aplican reglas NSG de subred. Se requieren reglas específicas para la correcta funcionalidad del clúster, incluido el tráfico entre rangos CIDR de nodos y rangos CIDR de pods. Se recomiendan las políticas de red para el control del tráfico de la carga de trabajo.
Con Kubenet, el control de la seguridad de la red se limita al nivel de nodo, ya que los pods no tienen direcciones IP directas de VNet. Las reglas NSG sólo 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 de red. Esta limitación dificulta la aplicación de políticas de red específicas para pods y puede requerir soluciones alternativas como las Políticas de Red de Kubernetes para un control más granular del tráfico dentro del clúster.
Integración VNet
La CNI tradicional de Azure proporciona una integración completa de VNet, lo que permite a los pods comunicarse directamente con cualquier recurso de tu entorno Azure que esté conectado a la VNet. Esto incluye servicios de Azure como SQL Managed Instances, Azure Cache para Redis, o recursos en VNets peered. Dado que los pods obtienen sus direcciones IP directamente de la subred de la VNet, pueden establecer conexiones directas sin configuración adicional de red, lo que resulta ideal para escenarios que requieren una integración perfecta con otros servicios de Azure.
Azure CNI Overlay proporciona integración VNet a través de NAT, donde el tráfico saliente del pod utiliza la dirección IP del nodo. Aunque no se puede acceder directamente a los pods desde fuera del clúster, puedes publicar aplicaciones pod como servicios Kubernetes Load Balancer para que sean accesibles en la VNet.
Kubenet ofrece capacidades de integración en VNet más limitadas. Aunque los pods pueden seguir comunicándose con recursos externos, esta comunicación requiere UDR para encaminar correctamente el tráfico entre la red superpuesta del pod y la VNet. Esta complejidad de enrutamiento adicional podría afectar potencialmente a la conectividad con determinados servicios de Azure y puede requerir una configuración adicional cuando se trabaja con escenarios de peering de VNet o de red híbrida. Los requisitos de enrutamiento también pueden volverse más complejos a medida que crece tu arquitectura de red.
Gestión de la tabla de rutas y complejidad de la configuración
La gestión de la tabla de rutas varía significativamente entre las opciones. La CNI tradicional de Azure simplifica la gestión de rutas porque los pods se comunican directamente en la VNet y no hay necesidad de entradas adicionales en la tabla de rutas para gestionar el tráfico de los pods. La configuración del enrutamiento sigue siendo sencilla incluso cuando el clúster se amplía. La contrapartida es la complejidad de la configuración inicial, que requiere una cuidadosa planificación de las direcciones IP.
Azure CNI Overlay simplifica la interconexión de pods al no requerir UDRs para la conectividad básica, a diferencia de Kubenet. Aunque requiere la configuración de reglas NSG específicas para la correcta funcionalidad del clúster, la solución gestiona automáticamente el enrutamiento de pod a pod y mantiene un rendimiento comparable al de la comunicación VNet tradicional. Los UDR pueden seguir siendo necesarios para situaciones específicas, como la tunelización forzada o requisitos de enrutamiento personalizados.
Kubenet utiliza UDRs y reenvíos IP para la conectividad de los pods, que el servicio AKS crea y mantiene automáticamente por defecto. Aunque opcionalmente puedes traer tu propia tabla de rutas para una gestión personalizada, la configuración estándar no requiere el mantenimiento manual de la tabla de rutas. La principal limitación es que Azure admite un máximo de 400 rutas en una UDR, lo que de hecho limita tu clúster a 400 nodos. La configuración inicial es más sencilla que la CNI tradicional de Azure, ya que no necesitas una planificación exhaustiva de las direcciones IP, sólo tienes que tener en cuenta las IP de los nodos de tu subred. Sin embargo, la arquitectura UDR añade un salto de red adicional que introduce una latencia menor en la comunicación de los pods, y no puedes compartir subredes entre varios clusters Kubenet.
Características adicionales
Cada opción de red admite distintas funciones avanzadas. Azure CNI tradicional ofrece el soporte de funciones más amplio, incluidos los contenedores de Windows, las políticas de red de Azure y la 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 utilizar Application Gateway como controlador de entrada. Ambos modos CNI admiten redes de doble pila, aunque Overlay tiene algunas limitaciones. Kubenet tiene un soporte de funciones más limitado, ya que sólo funciona con contenedores Linux y políticas de red Calico. Además, Kubenet se limita sólo a contenedores Linux, admite hasta 400 nodos con 250 vainas por nodo, y está restringido a Calico para las políticas de red. No admite contenedores Windows ni funciones avanzadas de red de Azure.
¿Cuál elegir?
La elección entre las opciones de red depende de los requisitos específicos de tu carga de trabajo y de las limitaciones de tu infraestructura:
La CNI tradicional de Azure es la más adecuada para cargas de trabajo empresariales que requieren integración directa en red, alto rendimiento o integración avanzada de servicios Azure. Elígela cuando:
- Tienes espacio disponible para direcciones IP
- La mayor parte de la comunicación de los pods se realiza con recursos externos al clúster
- Los recursos externos al clúster necesitan llegar directamente a los pods
- Necesitas funciones AKS avanzadas como los nodos virtuales
- Se requiere la integración de la pasarela de aplicaciones
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 un espacio limitado de direcciones IP
- La mayor parte de la comunicación de los pods se realiza dentro del clúster
- Quieres una configuración de red más sencilla
- Necesitas soporte para contenedores Windows pero no necesitas Application Gateway Ingress Controller.
- Quieres reutilizar rangos CIDR de pods entre clusters
Kubenet funciona bien para cargas de trabajo básicas de Linux y entornos con limitaciones de direcciones IP. Elígelo cuando:
- Tienes cargas de trabajo básicas sólo Linux
- Tienes limitaciones de direcciones IP pero no necesitas la escala de la Superposición CNI
- No necesitas funciones de red avanzadas
- Estás configurando entornos de desarrollo o de prueba
La elección del plugin de red para tu clúster AKS tiene implicaciones a largo plazo para la escalabilidad, el rendimiento y la complejidad operativa. Comprender las distintas características y limitaciones de cada opción es crucial para tomar una decisión informada que se ajuste a tus requisitos de infraestructura y a tus planes de crecimiento futuro. Recuerda que el cambio entre opciones de red suele requerir la recreación del clúster, por lo que esta decisión debe tomarse al principio de tu proceso de planificación del AKS.
Una nota adicional: el 31 de marzo de 2028 se retirará la red kubenet para AKS. Considera la posibilidad de migrar a Azure CNI Overlay como un sustituto adecuado que resuelve muchas de las limitaciones de Kubenet al tiempo que mantiene una utilización eficiente de las direcciones IP.
Ponte en contacto con DoiT hoy mismo para hablar de cómo podemos ayudarte a maximizar la eficacia, rentabilidad y seguridad de tu entorno en la nube. Con DoiT, tendrás acceso a expertos en la nube con experiencia exclusiva en consultoría, formación y asistencia, y estaremos aquí siempre que necesites asesoramiento experto, una opinión externa, asistencia para adoptar nuevas tecnologías o ayuda para apagar fuegos en la producción.
Si te interesa profundizar en otros temas de seguridad y arquitectura de la nube, consulta nuestras entradas del blog sobre ingeniería de la nube.
