Compartir por


Subred Pod de Azure Container Networking Interface (CNI)

Azure CNI Pod Subnet asigna direcciones IP a los pods desde una subred separada de los nodos de su clúster. Esta característica está disponible en dos modos: asignación dinámica de IP y asignación estática de bloques (versión preliminar).

Requisitos previos

Nota:

Al usar la asignación estática de bloques de CIDR, no se admite la exposición de una aplicación como un servicio Private Link mediante un servicio de equilibrador de carga de Kubernetes.

  • Revise los requisitos previos para configurar redes básicas de Azure CNI en AKS, ya que los mismos requisitos previos se aplican a este artículo.

  • Revise los parámetros de implementación para configurar redes básicas de Azure CNI en AKS, ya que se aplican los mismos parámetros.

  • No se admiten los clústeres de AKS Engine y de implementación personal.

  • Versión 2.37.0 o posterior de Azure CLI y la aks-previewversión 2.0.0b2 de la extensión o posterior.

  • Registre el indicador de característica de nivel de suscripción para su suscripción: "Microsoft.ContainerService/AzureVnetScalePreview".

  • Si tiene un clúster existente, debe activar el complemento Container Insights para supervisar el uso de subredes IP. Puede habilitar Container Insights con el comando az aks enable-addons, tal como se muestra en el ejemplo siguiente:

    az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>
    

Modo de asignación dinámica de IP

La asignación dinámica de IP ayuda a mitigar los problemas de agotamiento de direcciones IP de pods mediante la asignación de IPs de pods desde una subred independiente de la subred que aloja el clúster AKS.

El modo de asignación dinámica de IP ofrece las siguientes ventajas:

  • Mejor uso de IP: las direcciones IP se asignan dinámicamente a los pods de clúster desde la subred de pod. Esto conduce a un mejor uso de las direcciones IP en el clúster en comparación con la solución CNI tradicional, que realiza una asignación estática de direcciones IP para cada nodo.
  • Escalable y flexible: las subredes de nodo y pod se pueden escalar de manera independiente. Una sola subred de pod puede compartirse en varios grupos de nodos de un clúster o en varios clústeres de AKS implementados en la misma red virtual. También puede configurar una subred de pod independiente para un grupo de nodos.
  • Alto rendimiento: dado que a los pods se les asignan las IPs de VNet, tienen conectividad directa con otros pods de cluster y recursos en la VNet. La solución admite clústeres muy grandes sin ninguna reducción del rendimiento.
  • Directivas de red virtual independientes para pods: dado que los pods tienen una subred independiente, puede configurar directivas de red virtual independientes para ellas distintas de las directivas de nodo. Esto permite muchas situaciones útiles, como permitir la conectividad a Internet solo para los pods y no para los nodos, fijar la IP de origen para el pod en un grupo de nodos utilizando Azure NAT Gateway y utilizar grupos de seguridad de red (NSG) para filtrar el tráfico entre grupos de nodos.
  • Directivas de red de Kubernetes: tanto las directivas de red de Azure como Calico funcionan con este modo.

Planeamiento de las direcciones IP

Con la asignación dinámica de IP, los nodos y pods escalan de forma independiente, por lo que puede planificar sus espacios de direcciones por separado. Dado que las subredes de pod se pueden configurar en la granularidad de un grupo de nodos, siempre podrá agregar una nueva subred cuando agregue un grupo de nodos. Los pods de sistema de un grupo de clústeres/nodos también reciben direcciones IP de la subred de pod, por lo que es necesario tener en cuenta este comportamiento.

Las direcciones IP se asignan a los nodos en lotes de 16. La asignación de las IP a la subred Pod debe planificarse con un mínimo de 16 IPs por nodo en el clúster, ya que los nodos solicitan 16 IPs al arrancar y solicitan otro lote de 16 cada vez que quedan <8 IP sin asignar en su asignación.

La planificación de direcciones IP para los servicios Kubernetes y Docker Bridge se mantiene sin cambios.

Modo de asignación de bloques estáticos (versión preliminar)

La asignación estática de bloques ayuda a mitigar las posibles limitaciones de tamaño de las subredes pod y de asignación de direcciones Azure mediante la asignación de bloques CIDR a los nodos en lugar de IPs individuales.

El modo de asignación estática de bloques ofrece las siguientes ventajas:

  • Mejor escalabilidad de IP: los bloques CIDR se asignan estáticamente a los nodos del clúster y están presentes durante toda la vida útil del nodo, a diferencia de la asignación dinámica tradicional de IPs individuales con CNI tradicional. Esto permite el enrutamiento basado en bloques CIDR y ayuda a escalar el límite de clústeres a hasta 1 millón de pods desde los 65 000 pods tradicionales por clúster. La instancia de Azure Virtual Network debe ser lo suficientemente grande como para adaptarse a la escala del clúster.
  • Flexibilidad: las subredes de nodos y pods se pueden escalar de forma independiente. Una sola subred de pod puede compartirse en varios grupos de nodos de un clúster o en varios clústeres de AKS implementados en la misma red virtual. También puede configurar una subred de pod independiente para un grupo de nodos.
  • Alto rendimiento: Ya que a los pods se les asignan direcciones IP de red virtual, tienen conectividad directa con los recursos y los pods de otros clústeres de la red virtual.
  • Directivas de red virtual independientes para pods: dado que los pods tienen una subred independiente, puede configurar directivas de red virtual independientes para ellas distintas de las directivas de nodo. Esto permite muchos escenarios útiles, como la habilitación de la conectividad a Internet solo para los pods y no para los nodos, la corrección de la IP de origen para los pods en un grupo de nodos mediante Azure NAT Gateway y el uso de NSG para filtrar el tráfico entre grupos de nodos.
  • Directivas de red de Kubernetes: Cilium, Azure NPM y Calico trabajan con esta solución.

Limitaciones

A continuación se muestran algunas de las limitaciones del uso de la asignación estática de bloques de Azure CNI:

  • La versión mínima de Kubernetes necesaria es la 1.28
  • El tamaño máximo de subred admitido es x.x.x.x/12 ~ 1 millón de direcciones IP
  • No es compatible con los grupos de nodos de Windows
  • No compatible con el plano de datos Cilium
  • Solo se puede usar un modo de operación por subred. Si una subred usa el modo de asignación estática de bloques, no se puede usar el modo de asignación dinámica de IP en un clúster o grupo de nodos diferente con la misma subred y viceversa.
  • Solo se admite en clústeres nuevos o al agregar grupos de nodos con una subred diferente a los clústeres existentes. No se admite la migración o actualización de clústeres o grupos de nodos existentes.
  • En todos los bloques CIDR asignados a un nodo del grupo de nodos, se seleccionará una dirección IP como dirección IP principal del nodo. Por lo tanto, para los administradores de red que seleccionen el valor --max-pods, intente usar el cálculo siguiente para satisfacer mejor sus necesidades y tener un uso óptimo de direcciones IP en la subred:

max_pods = (N * 16) - 1 donde N es cualquier número entero positivo y N> 0

Disponibilidad regional

Esta característica no está disponible en las siguientes regiones:

  • Sur de EE. UU.
  • Este de EE. UU. 2
  • Oeste de EE. UU.
  • Oeste de EE. UU. 2

Planeamiento de las direcciones IP

Con la asignación estática de bloques, los nodos y los pods se escalan de forma independiente, por lo que puede planificar sus espacios de direcciones por separado. Dado que las subredes de pod se pueden configurar en la granularidad de un grupo de nodos, siempre podrá agregar una nueva subred cuando agregue un grupo de nodos. Los pods de sistema de un grupo de clústeres/nodos también reciben direcciones IP de la subred de pod, por lo que es necesario tener en cuenta este comportamiento.

Los bloques CIDR de /28 (16 IPs) se asignan a los nodos en función de la configuración --max-pods de su grupo de nodos, que define el número máximo de pods por nodo. Hay 1 dirección IP reservada en cada nodo de todas las direcciones IP disponibles en ese nodo con fines internos.

Al planificar sus IPs, es importante definir su configuración --max-pods utilizando el siguiente cálculo: max_pods_per_node = (16 * N) - 1, donde N es cualquier número entero positivo mayor que 0.

Los valores ideales sin desperdicio de direcciones IP requerirían que el valor máximo de pods se ajuste a la expresión anterior.

Consulte los siguientes casos de ejemplo:

Caso de ejemplo max_pods CIDR Bloques asignados por nodo IP total disponible para pods Desperdicio de IP por nodo
Poco desperdicio (aceptable) 30 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 30 = 1
Caso ideal 31 2 (16 * 2) - 1 = 32 - 1 = 31 31 - 31 = 0
Alto desperdicio (no recomendado) 32 3 (16 * 3) - 1 = 48 - 1 = 47 47 - 32 = 15

La planificación de direcciones IP para los servicios Kubernetes no cambia.

Nota:

Asegúrese de que la red virtual tenga un espacio de direcciones lo suficientemente grande y contiguo para admitir la escala del clúster.