Interfaces de red de contenedores (CNI) heredadas de 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

Los siguientes requisitos previos son necesarios para Azure CNI Node Subnet y kubenet:

• 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.

Nota:

Kubenet no está disponible para contenedores Windows Server. Para utilizar grupos de nodos de Windows Server, debe utilizar Azure CNI.

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.

Kubenet

Los clústeres de AKS usan kubenet y crean una red virtual de Azure y una subred por defecto. Con kubenet, los nodos obtienen una dirección IP de una subred de la red virtual de Azure. Los pods reciben una dirección IP de un espacio de direcciones lógicamente distinto a la subred de red virtual de Azure de los nodos. A continuación, se configura la traducción de direcciones de red (NAT) para que los pods puedan acceder a los recursos en la red virtual de Azure. La dirección IP de origen del tráfico se somete a un proceso NAT hacia la dirección IP principal del nodo. Este enfoque reduce enormemente el número de direcciones IP que se deben reservar en el espacio de red para que los pods las usen.

Puede configurar el número máximo de pods que se puede implementar en un nodo en el momento de la creación del clúster o al crear nuevos grupos de nodos. Si no especifica maxPods al crear grupos de nodos nuevos, recibirá un valor predeterminado de 110 para kubenet.

Información general sobre redes kubenet con una subred propia

En muchos entornos, ha definido redes virtuales y subredes con intervalos de direcciones IP asignados y usa estos recursos para admitir varios servicios y aplicaciones. Para proporcionar conectividad de red, los clústeres de AKS pueden usar kubenet (redes básicas) o Azure CNI (redes avanzadas).

Con kubenet, solo los nodos reciben una dirección IP en la subred de red virtual. Los pods no pueden comunicarse directamente entre sí. En su lugar, se usan el enrutamiento definido por el usuario (UDR) y el reenvío de IP para la conectividad entre pods a través de los nodos. El servicio AKS crea y mantiene la configuración de reenvío de UDR e IP por defecto, pero puede traer su propia tabla de rutas para la administración personalizada de rutas si así lo desea. También puede implementar pods detrás de un servicio que recibe una dirección IP asignada y equilibra la carga del tráfico de la aplicación. En el diagrama siguiente se muestra cómo los nodos de AKS reciben una dirección IP en la subred de red virtual, pero no los pods:

Azure admite un máximo de 400 rutas en un UDR, por lo que no puede tener un clúster de AKS que tenga más de 400 nodos. Los nodos virtuales de AKS y las directivas de red de Azure no son compatibles con kubenet. Se admiten directivas de red de Calico.

Limitaciones y consideraciones de kubenet

• El diseño de kubenet requiere un salto adicional, lo que agrega una latencia menor a la comunicación del pod.
• Para utilizar kubenet, se necesitan tablas de rutas y rutas definidas por el usuario, lo que agrega complejidad a las operaciones.
  • Para más información, consulte los artículos Personalización de la salida del clúster con una tabla de enrutamiento definida por el usuario en Azure Kubernetes Service (AKS) y Personalización de la salida del clúster con tipos de salida en Azure Kubernetes Service (AKS).
• Por su diseño, kubenet no permite el direccionamiento directo de pods.
• A diferencia de los clústeres de Azure CNI, no se permite que varios clústeres de kubenet compartan una subred.
• 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 el CIDR de nodo y de pod. Para obtener más información, consulte Grupos de seguridad de red.
• Las características no admitidas en kubenet son:
  • Directivas de red de Azure
  • Grupos de nodos de Windows
  • Complemento de nodos virtuales

Nota:

Algunos de los pods del sistema, como konnectivity dentro del clúster, usan la dirección IP del nodo de host en lugar de una IP del espacio de direcciones de superposición. Los pods del sistema solo usarán la IP del nodo y no una dirección IP de la red virtual.

Disponibilidad y agotamiento de las direcciones IP

Un problema común con Azure CNI es que el intervalo de direcciones IP asignado es demasiado pequeño para agregar más nodos cuando se escala o actualiza un clúster. El equipo de red podría no ser capaz de emitir un intervalo de direcciones IP lo suficientemente grande como para satisfacer las demandas esperadas de la aplicación. Como compromiso, puede crear un clúster de AKS que use kubenet y conectarse a una subred de red virtual existente. Este enfoque permite que los nodos reciban direcciones IP definidas, sin necesidad de reservar un gran número de direcciones IP por adelantado para todos los pods posibles que se podrían ejecutar en el clúster.

Con kubenet, puede usar un intervalo de direcciones IP mucho más pequeño y tener la capacidad de satisfacer una elevada demanda de los clústeres y la aplicación. Por ejemplo, incluso con un intervalo de direcciones IP de /27 en la subred, podría ejecutar un clúster de 20-25 nodos con espacio suficiente para escalar o actualizar. Este tamaño de clúster puede admitir hasta 2200-2750 pods (con una capacidad máxima predeterminada de 110 pods por nodo). El número máximo de pods por nodo que se pueden configurar con kubenet en AKS es 250.

Los cálculos básicos siguientes comparan la diferencia entre los modelos de red:

• kubenet: un intervalo de direcciones IP /24 simple puede admitir hasta 251 nodos en el clúster. Cada subred de red virtual de Azure reserva las tres primeras direcciones IP para las operaciones de administración. Esta cantidad de nodos podría admitir hasta 27.610 pods con una capacidad máxima predeterminada de 110 pods por nodo.
• 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 utilizar el Emparejamiento de redes virtuales de Azure o Conexiones ExpressRoute con Azure CNI y kubenet 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 ?

  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.

• ¿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.