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.
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:
Azure Kubernetes Service