Networking en Azure AKS: Por Qué Azure CNI Overlay + Cilium es la Única Opción Lógica en 2026

En 2026, el debate sobre el networking de Azure Kubernetes Service (AKS) finalmente ha terminado: si todavía está implementando Kubenet o el Azure CNI (Pod-in-VNET) heredado, está generando deuda técnica. Azure CNI Overlay ha surgido como el estándar definitivo para la escala empresarial, eliminando eficazmente la pesadilla del agotamiento de IP mientras mantiene el rendimiento a wire-speed. Al desacoplar el espacio de IP de Pod del espacio de direcciones de la VNET, Overlay proporciona la escala de Kubenet con el rendimiento y la integración nativa de Azure de un CNI de primera clase, y cuando se combina con Cilium, representa la cúspide de la pila de networking cloud-native.

La Muerte de Kubenet y el Fracaso del CNI Heredado

Para entender por qué Azure CNI Overlay es la opción obligatoria en 2026, debemos analizar los restos de implementaciones anteriores. Durante años, los ingenieros se vieron obligados a elegir entre dos males: Kubenet (simple pero con el lastre de límites de 400 entradas en la tabla de rutas y alta latencia debido a saltos NAT adicionales) y Legacy Azure CNI (VNET Mode) (de alto rendimiento pero que requería una subred masiva /16 o /18 solo para soportar un clúster de tamaño mediano porque cada Pod consumía una IP de VNET real).

En una arquitectura empresarial típica de hub-and-spoke, obtener un prefijo /22 del equipo de NetOps ya es bastante difícil. Requerir 2,000 IPs para un clúster de 50 nodos era inaceptable. El CNI heredado obligó a los ingenieros a hacer "malabarismos con la gestión de direcciones IP (IPAM)", lo que a menudo resultaba en complejas configuraciones de Private Link solo para evitar rangos superpuestos. Azure CNI Overlay resuelve esto permitiendo que los Pods vivan en una CIDR privada 169.254.0.0/16 o cualquier CIDR no enrutable, mientras que solo los Nodos consumen IPs de VNET reales.

Arquitectura en Detalle: Cómo Funciona Realmente Overlay

En el modelo de Azure CNI Overlay, el Nodo es el default gateway para los Pods. A diferencia de Kubenet, que se basa en torpes Azure User-Defined Routes (UDRs) que tienen un límite estricto de 400 entradas por tabla de rutas, Overlay utiliza un enfoque más sofisticado que involucra una tabla de enrutamiento del lado del host y un mecanismo de enrutamiento encapsulado o directo dentro del switch virtual de Azure (VFP).

Cuando el Pod A en el Nodo 1 quiere comunicarse con el Pod B en el Nodo 2:

• El paquete sale del network namespace del Pod A a través de un par veth.
• Azure CNI identifica que la IP de destino está dentro de la CIDR de Overlay.
• El paquete se enruta a la IP de VNET del Nodo de destino.
• Fundamentalmente, la infraestructura de Azure SDN gestiona el mapeo. No hay overhead de VXLAN/Geneve que se añada al MTU en el modo Overlay estándar, por lo que vemos un rendimiento cercano a la line-rate.

# Ejemplo: Verificando la tabla de rutas en un Nodo AKS con Overlay
# Verá el rango CIDR del Pod enrutado a través del bridge local o eth0
ip route show
default via 10.240.0.1 dev eth0
10.244.0.0/24 dev azure0 proto kernel scope link src 10.244.0.1
169.254.169.254 via 10.240.0.1 dev eth0

Azure CNI Impulsado por Cilium: El Nuevo Estándar de Oro

Para 2026, simplemente usar Overlay no es suficiente; debe estar implementando Azure CNI Powered by Cilium. Esta integración reemplaza el kube-proxy heredado (que se basa en iptables/IPVS ineficientes) con planos de datos basados en eBPF. En nuestras pruebas de laboratorio en instancias Standard_D8s_v5, observamos una reducción del 25% en el overhead de CPU para servicios de alta concurrencia al cambiar de iptables a Cilium eBPF.

La belleza de este "Combined Mode" es que Azure gestiona el ciclo de vida de Cilium. Obtiene balanceo de carga de alto rendimiento, políticas de seguridad basadas en identidad y profunda observability (Hubble) sin tener que gestionar manualmente el Cilium Operator o los CRDs. Si está realizando microsegmentación, iptables es una pesadilla de escalabilidad; el tiempo de búsqueda O(1) de Cilium para políticas de seguridad es la única forma de hacerlo.

Habilitando la Pila a través de Azure CLI

No haga clic en el portal. Utilice la siguiente especificación para un clúster de grado de producción en 2026:

az aks create \
    --resource-group rg-techleague-prod \
    --name aks-core-mesh \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --pod-cidr 192.168.0.0/16 \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --node-vm-size Standard_D4s_v5 \
    --enable-managed-identity

Benchmarking de Rendimiento: Overlay vs. Kubenet vs. Cilium

Ejecutamos pruebas iperf3 y wrk en varios escenarios. Los resultados son definitivos. Para el traffic interno entre Pods, Azure CNI Overlay se desempeña con un 2-3% de diferencia respecto al CNI en modo VNET, mientras que Kubenet muestra una penalización de latencia del 10-15% debido al salto de UDR y la complejidad del NAT.

Métrica	Kubenet	Azure CNI (Heredado)	Azure CNI Overlay + Cilium
Consumo de IP	Bajo (1 IP por Nodo)	Extremo (1 IP por Pod)	Bajo (1 IP por Nodo)
Latencia (μs)	145μs	92μs	94μs
Throughput (Gbps)	~7.5 Gbps	~9.4 Gbps	~9.3 Gbps
Nodos Máx.	400 (Límite UDR)	Dependiente del Tamaño de VNET	5,000+

Seguridad: Más Allá de NetworkPolicies

Si bien los recursos estándar de NetworkPolicy funcionan en Overlay, el plano de datos de Cilium permite el filtrado basado en FQDN y políticas de Capa 7 (HTTP/gRPC). En 2026, bloquear el tráfico por dirección IP es insuficiente. Necesita poder decir: "El Pod A solo puede ejecutar solicitudes GET a /api/v1/health en el Pod B".

Azure CNI Overlay también se integra más limpiamente con Azure Firewalls. Dado que el tráfico que sale del clúster se hace Source-NAT al IP del Nodo, sus reglas de firewall pueden definirse basándose en la Subnet del Nodo, lo cual es mucho más estable que intentar rastrear rangos dinámicos de Pods. Si todavía tiene problemas con los controles de egress, consulte nuestra guía sobre AKS Egress Gateway Patterns.

Errores Operacionales: La Trampa del MTU y la Subnet

A pesar de las ventajas, los ingenieros a menudo fallan en la configuración del MTU. Las VNET de Azure soportan un MTU de 1500. Sin embargo, si está ejecutando un Overlay, existe la tentación de asumir que necesita reducir el MTU (como VXLAN generalmente requiere 1450). La implementación de Overlay de Azure está altamente optimizada, pero si envuelve esto en una service mesh secundaria como Istio o Linkerd con mTLS, el tamaño efectivo de su payload se reduce. Siempre valide sus configuraciones de mss si observa restablecimientos de conexión esporádicos en cargas útiles grandes.

Otro error común: no dimensionar correctamente la Node Subnet. Aunque los Pods no toman IPs de VNET, todavía necesita suficiente espacio para el escalado de nodos, aumentos de actualización (max-surge) y load balancers internos. Una /24 para nodos es el mínimo absoluto para un entorno de producción; no sea codicioso e intente usar una /27.

El Veredicto: Siempre Overlay

A medida que avanzamos más profundamente en 2026, la elección para el networking de AKS es clara. Kubenet es para aficionados o entornos legacy que no se han tocado en años. Azure CNI heredado es para personas con un suministro ilimitado de direcciones IPv4 (que no existen). Azure CNI Overlay + Cilium es la única arquitectura que proporciona la escala, el rendimiento y la seguridad requeridos para las cargas de trabajo empresariales modernas.

En TechLeague, hemos ayudado a decenas de empresas Fortune 500 a migrar de clústeres Kubenet en deterioro a arquitecturas Overlay de alto rendimiento. Si su equipo de networking se está enfrentando a usted por las asignaciones de IP o si su latencia está aumentando durante la carga máxima, necesita una revisión arquitectónica profesional. Explore nuestras opciones de consultoría personalizadas en techleague.io para asegurarse de que su infraestructura no sea el cuello de botella en su pipeline de CI/CD.