Interfaces de red de contenedores (CNI) heredadas de AKS

2025-05-06

Importante

El 31 de marzo de 2028 , se retirarán las redes kubenet para Azure Kubernetes Service (AKS).

Para evitar interrupciones del servicio, deberáactualizar a la superposición de Azure Container Networking Interface (CNI)antes de esa fecha, cuando ya no se admita la ejecución de cargas de trabajo en kubenet para AKS.

En Azure Kubernetes Service (AKS), aunque Azure CNI Overlay y Azure CNI Pod Subnet se recomiendan para la mayoría de los escenarios, los modelos de red heredados como Azure CNI Node Subnet y kubenet siguen estando disponibles y son compatibles. Estos modelos heredados ofrecen diferentes enfoques para la administración de direcciones IP pod y la creación de redes, cada uno con su propio conjunto de capacidades y consideraciones. Este artículo ofrece una información general de estas opciones de red heredadas, detallando sus requisitos previos, parámetros de implementación y características clave para ayudarle a comprender sus funciones y cómo pueden utilizarse eficazmente en sus clústeres AKS.

Requisitos previos

Se requieren los siguientes requisitos previos para la subred del nodo de CNI de Azure:

La red virtual del clúster AKS debe permitir la conectividad saliente de Internet.
Los clústeres de AKS no pueden usar 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 ni 192.0.2.0/24 para el intervalo de direcciones del servicio de Kubernetes, el intervalo de direcciones de pod, o el intervalo de direcciones de la red virtual del clúster.
La identidad de clúster utilizada por el clúster AKS debe tener al menos permisos de Colaborador de red en la subred dentro de la red virtual. Si desea definir un rol personalizado en lugar de utilizar la función de colaborador de red incorporada, se requieren los siguientes permisos:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
- Microsoft.Authorization/roleAssignments/write
La subred asignada al grupo de nodos AKS no puede ser una subred delegada.

AKS no aplica grupos de seguridad de red (NSG) a su subred y no modificará ninguno de los grupos de seguridad de red asociados a esa subred. Si proporciona su propia subred y agrega NSG asociadas con esa subred, asegúrese de que las reglas de seguridad en las NSGs permiten el tráfico dentro del rango CIDR del nodo. Para más información, consulte Grupo de seguridad de red.

Subred del nodo Azure CNI

Con Azure Container Networking Interface (CNI), cada pod obtiene una dirección IP de la subred, y se puede acceder a él directamente. Los sistemas de la misma red virtual que el clúster de AKS ven la IP del pod como la dirección de origen para todo el tráfico del pod. Los sistemas que están fuera de la red virtual del clúster de AKS ven la IP del nodo como la dirección de origen para todo el tráfico del pod. Estas direcciones IP deben ser únicas en el espacio de red y deben planearse de antemano. Cada nodo tiene un parámetro de configuración para el número máximo de pods que admite. Luego, el número equivalente de direcciones IP por nodo se reserva por adelantado para ese nodo. Este enfoque requiere más planificación y a menudo lleva al agotamiento de direcciones IP o a la necesidad de volver a generar los clústeres en una subred mayor, a medida que crecen las exigencias de la aplicación.

Con Azure CNI Node Subnet, cada pod recibe una dirección IP en la subred IP y puede comunicarse directamente con otros pods y servicios. Los clústeres pueden ser tan grandes como el intervalo de direcciones IP que especifique. Sin embargo, debe planearse el intervalo de direcciones IP por adelantado, y los nodos de AKS consumen todas las direcciones IP en función del número máximo de pods que pueden admitir. Las funciones y escenarios de red avanzados, como los nodos virtuales o las directivas de red (Azure o Calico), son compatibles con Azure CNI.

Parámetros de implementación

Cuando crea un clúster de AKS, los parámetros siguientes son configurables para redes de Azure CNI:

Red virtual: la red virtual en la que desea implementar el clúster de Kubernetes. Puede crear una nueva red virtual o utilizar una ya existente. Si desea utilizar una red virtual existente, asegúrese de que se encuentra en la misma ubicación y suscripción de Azure que su clúster Kubernetes. Para información acerca de límites y cuotas para Azure Virtual Network, vea Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

Subred: la subred dentro de la red virtual en la que desea implementar el clúster. Puede agregar nuevas subredes a la red virtual durante el proceso de creación del clúster. Para la conectividad híbrida, el intervalo de direcciones no debe solaparse con ninguna otra red virtual de su entorno.

Complemento de red de Azure: cuando se usa el complemento de red de Azure, no se puede acceder al servicio Load Balancer interno con "externalTrafficPolicy=Local" desde la máquina virtual con una dirección IP en clusterCIDR que no pertenezca al clúster de AKS.

Intervalo de direcciones de servicio de Kubernetes: es parámetro es el conjunto de direcciones IP virtuales que Kubernetes asigna a servicios internos del clúster. Este intervalo no se puede actualizar después de crear el clúster. Puede usar cualquier intervalo de direcciones privado que cumpla los requisitos siguientes:

No debe estar dentro del rango de direcciones IP de la red virtual de su clúster.
No debe sobreponerse a ninguna otra red virtual con la que la red virtual del clúster esté emparejada.
No debe sobreponerse a ninguna IP local.
No debe estar dentro del rango 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 ni 192.0.2.0/24.

Aunque es posible especificar un rango de direcciones de servicio dentro de la misma red virtual que su clúster, no lo recomendamos. La sobreposición de rangos IP puede resultar en un comportamiento impredecible. Para más información, consulte las preguntas más frecuentes. Para más información sobre los servicios de Kubernetes, consulte Servicios en la documentación de Kubernetes.

Dirección IP del servicio DNS de Kubernetes: la dirección IP del servicio DNS del clúster. Esta dirección debe estar dentro del intervalo de direcciones del servicio Kubernetes. No use la primera dirección IP del intervalo de direcciones. La primera dirección del intervalo de la subred se usa para la dirección kubernetes.default.svc.cluster.local.

Azure CNI: ese mismo intervalo de subred básico de /24 solo podría admitir un máximo de 8 nodos en el clúster. Este número de nodos solo puede admitir hasta 240 pods con una capacidad máxima predeterminada de 30 pods por nodo.

Nota:

Estos valores máximos no tienen en cuenta las operaciones de actualización o escalado. En la práctica, no puede ejecutar el número máximo de nodos que el intervalo de direcciones IP de la subred admite. Debe dejar algunas direcciones IP disponibles para operaciones de escalado o actualización.

Emparejamiento de redes virtuales y conexiones de ExpressRoute

Puede usar el emparejamiento de redes virtuales de Azure o las conexiones de ExpressRoute con Azure CNI para proporcionar conectividad local. Asegúrese de planificar cuidadosamente sus direcciones IP para evitar que se sobrepongan y un enrutamiento incorrecto del tráfico. Por ejemplo, muchas redes locales usan un intervalo de direcciones 10.0.0.0/8 que se anuncia a través de la conexión ExpressRoute. Le recomendamos que cree sus clústeres AKS en subredes de redes virtuales Azure fuera de este intervalo de direcciones, como 172.16.0.0/16.

Para obtener más información, consulte Comparar modelos de red y sus ámbitos de compatibilidad.

Preguntas frecuentes sobre Azure CNI Pod Subnet

¿Puedo implementar máquinas virtuales en la subred del clúster?

Sí, para Azure CNI Node Subnet, las máquinas virtuales pueden implementarse en la misma subred que el clúster AKS.
¿Qué dirección IP de origen ven los sistemas externos para el tráfico que se origina en un pod habilitado para Azure CNI?

Los sistemas de la misma red virtual que el clúster de AKS ven la IP del pod como la dirección de origen para todo el tráfico del pod. Los sistemas que están fuera de la red virtual del clúster de AKS ven la IP del nodo como la dirección de origen para todo el tráfico del pod. Pero para la asignación dinámica de IP de Azure CNI, no importa si la conexión es dentro de la misma red virtual o a través de redes virtuales, la IP del pod es siempre la dirección de origen para cualquier tráfico del pod. Esto se debe a que el CNI de Azure para la asignación dinámica de IP implementa la infraestructura de red de contenedores de Microsoft Azure, que ofrece una experiencia de extremo a extremo. Por lo tanto, elimina el uso de ip-masq-agent, que todavía se usa en Azure CNI tradicional.
¿Puedo configurar las directivas de red por pod?

Sí, la directiva de red de Kubernetes está disponible en AKS. Para comenzar, consulte Protección del tráfico entre pods mediante directivas de red en Azure Kubernetes Service (AKS).
¿Es configurable el número máximo de pods que se puede implementar en un nodo ?

Con Azure Container Networking Interface (CNI), cada pod obtiene una dirección IP de la subred, y se puede acceder a él directamente. Los sistemas de la misma red virtual que el clúster de AKS ven la IP del pod como la dirección de origen para todo el tráfico del pod. Los sistemas que están fuera de la red virtual del clúster de AKS ven la IP del nodo como la dirección de origen para todo el tráfico del pod. Estas direcciones IP deben ser únicas en el espacio de red y deben planearse de antemano. Cada nodo tiene un parámetro de configuración para el número máximo de pods que admite. Luego, el número equivalente de direcciones IP por nodo se reserva por adelantado para ese nodo. Este enfoque requiere más planificación y a menudo lleva al agotamiento de direcciones IP o a la necesidad de volver a generar los clústeres en una subred mayor, a medida que crecen las exigencias de la aplicación.
¿Puedo implementar máquinas virtuales en la subred del clúster?

Sí. Pero para Azure CNI para la asignacióndinámica de IP, las máquinas virtuales no se pueden implementar en la subred del pod.
¿Qué dirección IP de origen ven los sistemas externos para el tráfico que se origina en un pod habilitado para Azure CNI?

Los sistemas de la misma red virtual que el clúster de AKS ven la IP del pod como la dirección de origen para todo el tráfico del pod. Los sistemas que están fuera de la red virtual del clúster de AKS ven la IP del nodo como la dirección de origen para todo el tráfico del pod.

Pero para Azure CNI para la asignacióndinámica de IP, independientemente de que la conexión esté dentro de la misma red virtual o entre redes virtuales, la dirección IP del pod siempre es la dirección de origen de cualquier tráfico del pod. Esto se debe a que el CNI de Azure para la asignación dinámica de IP implementa la infraestructura de red de contenedores de Microsoft Azure, que ofrece una experiencia de extremo a extremo. Por lo tanto, elimina el uso de ip-masq-agent, que todavía se usa en Azure CNI tradicional.
¿Puedo usar otra subred dentro de mi red virtual de clúster en el intervalo de direcciones de servicio de Kubernetes?

Aunque no se recomienda, esta configuración es posible. El rango de direcciones de servicio es un conjunto de direcciones IP virtuales (VIP) que Kubernetes asigna a los servicios internos del clúster. Las redes de Azure no tiene ninguna visibilidad sobre el intervalo de direcciones IP de servicio del clúster de Kubernetes. La falta de visibilidad en el intervalo de direcciones del servicio del clúster puede provocar problemas. Es posible crear posteriormente una nueva subred en la red virtual del clúster que se superponga con el intervalo de direcciones de servicio. Si se produce una superposición de este tipo, Kubernetes podría asignar a un servicio una dirección IP que ya esté en uso por otro recurso de la subred, lo que provocaría un comportamiento impredecible o errores. Al tener la seguridad de usar un intervalo de direcciones que se encuentra fuera de la red virtual del clúster puede evitar este riesgo de superposición. Sí, al implementar un clúster con la CLI de Azure o una plantilla de Resource Manager. Consulte Pods máximos por nodo.
¿Puedo usar otra subred dentro de mi red virtual de clúster en el intervalo de direcciones de servicio de Kubernetes?

Aunque no se recomienda, esta configuración es posible. El rango de direcciones de servicio es un conjunto de direcciones IP virtuales (VIP) que Kubernetes asigna a los servicios internos del clúster. Las redes de Azure no tiene ninguna visibilidad sobre el intervalo de direcciones IP de servicio del clúster de Kubernetes. La falta de visibilidad en el intervalo de direcciones del servicio del clúster puede provocar problemas. Es posible crear posteriormente una nueva subred en la red virtual del clúster que se superponga con el intervalo de direcciones de servicio. Si se produce una superposición de este tipo, Kubernetes podría asignar a un servicio una dirección IP que ya esté en uso por otro recurso de la subred, lo que provocaría un comportamiento impredecible o errores. Al tener la seguridad de usar un intervalo de direcciones que se encuentra fuera de la red virtual del clúster puede evitar este riesgo de superposición.