Planificación de la configuración de redes de pods para Azure Kubernetes Service (AKS)

Elija una configuración de red de los pods en función de si se necesita acceder directamente mediante IP a los pods desde las redes conectadas y de los requisitos de escalabilidad de direcciones IP.

¿Necesita acceso IP directo a los pods?

Las redes de pods controlan cómo los pods obtienen direcciones IP y definen cómo se comunican los pods entre sí, los nodos de clúster y los destinos fuera del clúster. Kubernetes implementa la red de pods mediante un complemento de interfaz de red de contenedores (CNI), que administra las direcciones IP de los pods y la conectividad de red.

Al configurar la red de pods, debe planificar la administración de direcciones IP (IPAM) y el enrutamiento y transporte (plano de datos).

Si sus cargas de trabajo requieren que se pueda acceder a los pods mediante una IP privada desde redes conectadas a la red virtual (VNet) del clúster de Azure Kubernetes Service (AKS), use un modelo de red plano. De lo contrario, use Azure CNI Overlay.

Opciones de administración de direcciones IP (IPAM)

Al configurar IPAM, puede elegir entre un modelo de redes superpuestas con Azure CNI Overlay y un modelo de redes planas con subred de pod de Azure CNI o subred de nodo de Azure CNI:

En la tabla siguiente se comparan las opciones de IPAM disponibles para las redes de pods de AKS, incluidas sus características clave y los límites de escala.

Opciones de IPAM Diagrama de componentes de red Características y funcionalidades
Modelo de Red Superpuesta (con Azure CNI Overlay) Captura de pantalla de un diagrama de los componentes de red de un modelo de redes superpuestas. • Las direcciones IP de pod proceden de un intervalo de superposición que no forma parte del espacio de VNet.
• Redes altamente escalables, con hasta 5000 nodos y 200 000 pods por clúster. Los límites de nodo, pod por nodo y pod agregado son independientes.
• El espacio de direcciones de la red superpuesta de los pods se puede reutilizar en clústeres independientes. El CIDR del pod no debe superponerse con redes directamente conectadas, incluidas las VNets emparejadas, las redes conectadas a través de ExpressRoute o de una red VPN, y otras rutas que expongan espacio de direcciones privadas.
• Compatibilidad con pila doble (IPv4/IPv6).
• No se puede acceder a los pods directamente desde fuera del clúster.
Modelo de red plana (con subred de pods de Azure CNI o subred de nodos) Captura de pantalla de un diagrama de los componentes de red de un modelo de redes planas. • Las direcciones IP de nodo y pod proceden del espacio de red virtual.
• Se puede acceder a los pods mediante sus direcciones IP privadas desde redes conectadas. Azure CNI Pod Subnet conserva la dirección IP de origen del pod a través de las redes virtuales conectadas, mientras que los destinos fuera de la VNet del clúster ven la dirección IP de origen del nodo con Azure CNI Node Subnet.
• Las opciones de subred de pod de Azure CNI incluyen la asignación dinámica de IP para la eficacia o la asignación de bloques estáticos para la escala.

Consideraciones para las opciones del modelo de redes planas

Tenga en cuenta las siguientes consideraciones al decidir entre la subred de pod de Azure CNI con asignación dinámica de IP, la subred de pod de CNI de Azure con asignación de bloques estáticos y la subred de nodo de Azure CNI:

Opción de modelo de red plana Consideraciones
Subred de pod de CNI de Azure con asignación de IP dinámica • Requiere subredes de nodo y pod independientes que se pueden ajustar y escalar de forma independiente.
• Asigna direcciones IP de pod a los nodos de la subred de pod en lotes de 16.
• Sujeto a límites de direcciones IP privadas configuradas por la red virtual.
Subred de pods de Azure CNI con asignación estática de bloques • Requiere un planeamiento cuidadoso, ya que necesita asignar un intervalo específico de direcciones IP para los pods y asegurarse de que no se superpone con otras subredes.
• Puede obtener hasta 1.000.000 de direcciones IP.
• Es posible que las direcciones IP no se utilicen de forma eficaz, lo que podría dar lugar a un desfase.
Subred de nodo de CNI de Azure • Opción heredada que puede usar una red virtual administrada por AKS o una red virtual y una subred administradas por el cliente.
• Los nodos y los pods comparten la subred de nodo, por lo que debe planificar la capacidad de antemano para nodos, pods, escalado y actualizaciones.
• Sujeto a límites de direcciones IP privadas configuradas por la red virtual.

Opciones de enrutamiento y transporte (plano de datos)

Al configurar el plano de datos, puedes elegir entre Azure CNI Powered by Cilium, plano de datos de Azure basado en iptables y BYO CNI:

En la tabla siguiente se comparan las opciones del plano de datos disponibles para las redes de pods de AKS y sus funcionalidades clave.

Opciones del plano de datos Características y funcionalidades
Azure CNI con tecnología de Cilium • Se ha mejorado la escala y el rendimiento de los grupos de nodos de Linux. No se admiten los grupos de nodos de Windows.
• Aplicación integrada de políticas de red de Cilium.
• El filtrado de FQDN requiere Advanced Container Networking Services y Kubernetes 1.29 o posterior.
Azure iptables • Use Calico para aplicar directivas de red en Windows. El soporte de Azure Network Policy Manager (NPM) finaliza el 30 de septiembre de 2026 para Windows y el 30 de septiembre de 2028 para Linux. Las nuevas suscripciones ya no pueden habilitar Azure NPM.
• Para los clústeres de Linux, use Azure CNI Powered by Cilium en lugar de Azure NPM.
• Admite la NetworkPolicy de Kubernetes.
BYO CNI • No hay instalado ningún complemento CNI administrado: puede usar cualquier opción que admita AKS.
• Microsoft no ofrece soporte para ningún problema relacionado con CNI.

Recomendaciones de redes para pods de AKS

Nuestra recomendación general es usar Azure CNI Overlay. Si necesita acceso directo a las IP de los pods desde redes conectadas y tiene requisitos de eficiencia o escalabilidad, considere usar Azure CNI Pod Subnet with Dynamic IP Allocation o Azure CNI Pod Subnet with Static Block Allocation. Azure CNI Node Subnet es una opción heredada; en general, úsela solo si necesita una VNet administrada por AKS para su clúster.