Información general de las redes de Azure CNI en Azure Kubernetes Service (AKS)
De manera predeterminada, los clústeres de AKS usan kubenet y crean una red virtual y una subred. Con kubenet, los nodos obtienen una dirección IP de una subred de la red virtual. Luego, la traducción de direcciones de red (NAT) se configura en los nodos, y los pods reciben una dirección IP "oculta" detrás de la dirección IP del nodo. Este enfoque reduce el número de direcciones IP que se deben reservar en el espacio de red para su uso por parte de los pods.
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.
Nota:
Este artículo solo presenta Azure CNI tradicional. Para la superposición de Azure CNI, la red virtual de Azure CNI para la asignación dinámica de IP y la red virtual de Azure CNI: asignación de bloques estáticos (versión preliminar). Consulte la documentación en su lugar.
Requisitos previos
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/16ni192.0.2.0/24para 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 que usa el clúster de AKS debe tener como mínimo permisos de Colaborador de la red en la subred de la red virtual. Si quiere definir un rol personalizado en lugar de usar el rol integrado de colaborador de red, se requieren los permisos siguientes:
Microsoft.Network/virtualNetworks/subnets/join/actionMicrosoft.Network/virtualNetworks/subnets/readMicrosoft.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 grupos de seguridad de red asociados a ella, debe asegurarse de que las reglas de seguridad de los NSG permiten el tráfico entre dentro del rango CIDR del nodo. Para más información, consulteGrupo de seguridad de red.
Planeamiento de direccionamiento IP del clúster
Los clústeres configurados con redes de Azure CNI requieren planeamiento adicional. Los tamaños de red virtual y de subred deben ajustarse al número de pods que tiene previsto ejecutar, así como al número de nodos del clúster.
Se asignan direcciones IP para los pods y los nodos del clúster desde la subred especificada dentro de la red virtual. Cada nodo se configura con una dirección IP principal. Azure CNI preconfigura 30 direcciones IP adicionales de forma predeterminada. Estas direcciones IP se asignan a pods programados en el nodo. Cuando se escala horizontalmente el clúster, cada nodo del mismo modo se configura de modo similar con direcciones IP de la subred. También puede ver el número máximo de pods por nodo.
Importante
El número de direcciones IP necesarias debe incluir consideraciones sobre las operaciones de actualización y escalabilidad. Si establece el intervalo de direcciones IP para que solo se admita un número fijo de nodos, no se podrá actualizar o escalar el clúster.
Al actualizar el clúster de AKS, se implementa un nuevo nodo en el clúster. Los servicios y las cargas de trabajo comienzan a ejecutarse en el nuevo nodo y el nodo antiguo se quita del clúster. Para realizar este proceso de actualización gradual es necesario que haya disponible un bloque adicional de direcciones IP. El recuento de nodos es entonces
n + 1.- Esta consideración es especialmente importante al utilizar grupos de nodos de Windows Server. Los nodos de Windows Server en AKS no aplican automáticamente las actualizaciones de Windows. En su lugar, realice una actualización en el grupo de nodos. Esta actualización implementa los nuevos nodos con las revisiones de seguridad y de la imagen de nodo base de Windows Server 2019 más recientes. Para más información sobre cómo actualizar un grupo de nodos de Windows Server, consulte el artículo de actualización de un grupo de nodos en AKS.
Al escalar un clúster de AKS, se implementa un nuevo nodo en el clúster. Los servicios y las cargas de trabajo comienzan a ejecutarse en el nuevo nodo. El intervalo de direcciones IP debe tener en cuenta cómo podría escalar verticalmente el número de nodos y los pods que el clúster puede admitir. También se debe incluir un nodo adicional para las operaciones de actualización. El recuento de nodos es entonces
n + number-of-additional-scaled-nodes-you-anticipate + 1.
Si espera que los nodos ejecuten el número máximo de pods, y destruye e implementa pods con regularidad, también debe contar con algunas direcciones IP adicionales por nodo. Es posible que se necesiten unos segundos para eliminar un servicio y liberar su dirección IP para que se implemente un nuevo servicio y adquiera la dirección. Estas direcciones IP adicionales consideran esta posibilidad.
El plan de direcciones IP de un clúster AKS consta de una red virtual, al menos una subred para los nodos y pods, y un intervalo de direcciones del servicio de Kubernetes.
| Intervalo de direcciones / recurso de Azure | Límites y tamaño |
|---|---|
| Virtual network | El tamaño de Azure Virtual Network puede ser de /8, pero se limita a 65 536 direcciones IP configuradas. Antes de configurar el espacio de direcciones, tenga en cuenta todos sus requisitos de red, incluida la comunicación con los servicios de otras redes virtuales. Por ejemplo, si configura un espacio de direcciones demasiado grande, es posible que surjan problemas de superposición con otros espacios de direcciones dentro de la red. |
| Subnet | Debe ser lo suficientemente grande como para dar cabida a los nodos, los pods y a todos los recursos de Kubernetes y de Azure que se pueden aprovisionar en el clúster. Por ejemplo, si implementa una instancia de Azure Load Balancer interna, sus direcciones IP de front-end se asignan desde la subred del clúster, no las direcciones IP públicas. El tamaño de la subred también debe tener en cuenta las operaciones de actualización o las necesidades futuras de escalabilidad. Use la siguiente ecuación para calcular el tamaño mínimo de subred, incluido un nodo adicional para las operaciones de actualización: ejemplo para un clúster de 50 nodos: Ejemplo para un clúster de 50 nodos que también incluye la preparación para escalar verticalmente 10 nodos adicionales: Si no especifica un número máximo de pods por nodo al crear el clúster, el número máximo de pods por nodo se establece en 30. El número mínimo de direcciones IP requeridas se basa en ese valor. Si calcula sus requisitos mínimos de direcciones IP sobre un valor máximo diferente, consulte Máximo de pods por nodo para establecer este valor cuando implemente su clúster. |
| Intervalo de direcciones del servicio de Kubernetes | Ningún elemento de red de esta red virtual o que esté conectado a ella debe usarse en este rango. El CIDR de la dirección del servicio debe ser menor que /12. Puede reutilizar este intervalo en diferentes clústeres de AKS. |
| Dirección IP del servicio DNS de Kubernetes | Dirección IP del intervalo de direcciones del servicio de Kubernetes que se usa en la detección de servicios de clúster. 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. |
Pods máximos por nodo
El número máximo de pods por nodo en un clúster de AKS es 250. El número máximo predeterminado de pods por nodo varía entre las redes de kubenety de Azure CNI, y el método de implementación del clúster.
| Método de implementación | Kubenet predeterminado | Azure CNI predeterminado | Configurable en la implementación |
|---|---|---|---|
| Azure CLI | 110 | 30 | Sí (hasta 250) |
| Plantilla de Resource Manager | 110 | 30 | Sí (hasta 250) |
| Portal | 110 | 110 (configurable en la pestaña Grupos de nodos) | Sí (hasta 250) |
Configuración de pods máximos por nodo para nuevos clústeres
Puede configurar el número máximo de nodos por nodo en el momento de la implementación del clúster o a medida que agrega nuevos grupos de nodos. Puede establecer los pods máximos por valor de nodo hasta 250.
Si no especifica maxPods al crear grupos de nodos nuevos, recibirá un valor predeterminado de 30 para Azure CNI.
Se exige un valor mínimo para los pods máximos por nodo para garantizar el espacio de los pods del sistema críticos para el estado del clúster. El valor mínimo que se puede establecer para los pods máximos por nodo es diez si y solo si la configuración de cada grupo de nodos tiene espacio para un mínimo de treinta pods. Por ejemplo, si se establece el número máximo de pods por nodo en el mínimo de diez, cada grupo de nodos individual debe tener un mínimo de tres nodos. Este requisito se aplica también a cada nuevo grupo de nodos que se crea, por lo que si se define diez como el número máximo de pods por nodo, cada grupo de nodos que se agregue después debe tener al menos tres nodos.
| Redes | Mínima | Máxima |
|---|---|---|
| CNI de Azure | 10 | 250 |
| Kubenet | 10 | 250 |
Nota:
El valor mínimo de la tabla anterior lo aplica estrictamente el servicio AKS. No se puede establecer un valor para maxPods que sea inferior al mínimo que se muestra, ya que hacerlo puede impedir que se inicie el clúster.
- CLI de Azure: especifique el argumento
--max-podscuando implemente un clúster con el comando az aks create. El valor máximo es 250. - Plantilla de Resource Manager: especifique la propiedad
maxPodsdel objeto ManagedClusterAgentPoolProfile cuando implemente un clúster con una plantilla de Resource Manager. El valor máximo es 250. - Azure Portal: cambie el campo
Max pods per nodeen la configuración del grupo de nodos al crear un clúster o agregar un nuevo grupo de nodos.
Configuración de pods máximos por nodo para clústeres existentes
La configuración de maxPods por nodo se puede definir cuando se crea un nuevo grupo de nodos. Si necesita aumentar la configuración de maxPods en un clúster existente, agregue un nuevo grupo de nodos con el nuevo número de maxPods deseado. Después de migrar los pods al nuevo grupo, elimine el grupo anterior. Para eliminar cualquier grupo anterior en un clúster, asegúrese de que está configurando los modos de grupo de nodos tal como se define en el documento de grupos de nodos del sistema.
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. Si desea crear una red virtual nueva para el clúster, seleccione Crear nueva y siga los pasos descritos en la sección Creación de red virtual. Si quiere seleccionar una red virtual existente, asegúrese de que se encuentra en la misma ubicación y suscripción de Azure que el clúster de 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. Si desea crear una nueva subred en la red virtual para el clúster, seleccione Crear nueva y siga los pasos descritos en la sección Creación de subred. 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 intervalo de direcciones IP de la red virtual del clúster.
- No deben superponerse con ninguna otra red virtual del mismo nivel que la red virtual del clúster.
- No debe superponerse con ninguna dirección IP local.
- No debe estar dentro de los intervalos
169.254.0.0/16,172.30.0.0/16,172.31.0.0/16ni192.0.2.0/24
Aunque es técnicamente posible especificar un intervalo de direcciones de servicio en la misma red virtual que el clúster, no se recomienda. Puede producirse un comportamiento impredecible si se usan intervalos IP superpuestos. Para más información, consulte la sección P+F de este artículo. 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.
Preguntas más frecuentes
¿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 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 ?
Sí, al implementar un clúster con la CLI de Azure o una plantilla de Resource Manager. Consulte Pods máximos por nodo.
No se puede cambiar el número máximo de pods por nodo en un clúster existente.
¿Cómo se pueden configurar propiedades adicionales para la subred que he creado durante la creación del clúster de AKS? Por ejemplo, los puntos de conexión de servicio.
La lista completa de propiedades de la red virtual y las subredes que se crean durante la creación del clúster de AKS puede configurarse en la página de configuración de red virtual estándar en Azure Portal.
¿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.
Paso siguiente
Más información acerca de las redes en AKS en los siguientes artículos: