Compartir a través de

Configuración de redes de Azure CNI para la asignación estática de bloques CIDR y compatibilidad mejorada con subredes en Azure Kubernetes Service (AKS) (versión preliminar)

  • Artículo

Una limitación de la asignación dinámica de IP de Azure CNI es la escalabilidad del tamaño de las subredes de pods más allá de una subred /16. Incluso con una subred grande, los clústeres grandes pueden estar limitados a 65 000 pods debido a un límite de asignación de direcciones de Azure. La nueva funcionalidad de asignación de bloques estáticos en Azure CNI resuelve este problema mediante la asignación de bloques CIDR a nodos en lugar de hacerlo con direcciones IP individuales.

Esto reporta 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 la vigencia del nodo, en contraposición a la asignación dinámica tradicional de direcciones IP 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 funcionan con esta nueva solución.

En este artículo se muestra cómo usar las redes de Azure CNI para la asignación estática de CIDR y la compatibilidad mejorada con subredes en AKS.

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 la CLI de Azure con la extensión aks-preview de la versión "2.0.0b2" o posterior

  • Si tiene un clúster existente, debe habilitar 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:

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

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

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 se admite para los grupos de nodos de Windows (la compatibilidad con Windows estará disponible próximamente)
  • No se admite para el plano de datos de Cilium (próximamente se admitirá la compatibilidad)
  • 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 entero positivo y N > 0

Disponibilidad en regiones

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

El planeamiento del direccionamiento IP es más flexible y granular. Dado que los nodos y pods se escalan de manera independiente, los espacios de direcciones también se pueden planear 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.

En este escenario, los bloques CIDR de /28 (16 direcciones IP) se asignan a los nodos según la configuración "--max-pod" del 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.

Por lo tanto, al determinar y planear las direcciones IP, es esencial definir la configuración "--max-pods", y se puede calcular mejor como se indica a continuación: max_pods_per_node = (16 * N) - 1, donde N es cualquier 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.

  • Ejemplo 1: max_pods = 30, bloques CIDR asignados por nodo = 2, Direcciones IP totales disponibles para pods = (16 * 2) - 1 = 32 - 1 = 31, IP desperdicio por nodo = 31 - 30 = 1 [Desperdicio bajo - Caso aceptable]
  • Ejemplo 2: max_pods = 31, bloques CIDR asignados por nodo = 2, Direcciones IP totales disponibles para pods = (16 * 2): 1 = 32 - 1 = 31, IP desperdicio por nodo = 31 - 31 = 0 [Caso ideal]
  • Ejemplo 3: max_pods = 32 bloques CIDR asignados por nodo = 3, Direcciones IP totales disponibles para pods = (16 * 3): 1 = 48 - 1 = 47, IP desperdicio por nodo = 47 - 32 = 15 [Desperdicio elevado - Caso no recomendado]

El planeamiento de direcciones IP para los servicios de Kubernetes permanece sin cambios.

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.

Parámetros de implementación

Los parámetros de implementación para configurar redes básicas de Azure CNI en AKS son válidos, con dos excepciones:

  • El parámetro vnet subnet id ahora hace referencia a la subred relacionada con los nodos del clúster.
  • El parámetro pod subnet id sirve para especificar la subred cuyas direcciones IP se asignarán estática o dinámicamente a los pods del grupo de nodos.
  • El parámetro pod ip allocation mode especifica si se debe usar la asignación dinámica de bloques individuales o estáticos.

Antes de empezar

Instalación de la extensión de la CLI de Azure aks-preview

  1. Instale la extensión aks-preview mediante el comando az extension add.

    az extension add --name aks-preview

  2. Actualiza a la última versión de la extensión mediante el comando az extension update. La extensión debe tener la versión "2.0..0b2" o posterior.

    az extension update --name aks-preview

Registro de la marca de característica AzureVnetScalePreview

  1. Registre la marca de características de AzureVnetScalePreview mediante el comando az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

    Tarda unos minutos en que el estado muestre Registrado.

  2. Comprobar el estado del registro mediante el comando az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"

  3. Cuando aparezca el estado Registrado, actualice el registro del proveedor de recursos Microsoft.ContainerService mediante el comando az provider register.

    az provider register --namespace Microsoft.ContainerService

Configuración de redes con asignación estática de bloques CIDR y compatibilidad mejorada con subredes: CLI de Azure

El uso de la asignación estática de bloques CIDR en el clúster es similar al método predeterminado para configurar un clúster de Azure CNI para la asignación dinámica de IP. En el ejemplo siguiente se explica cómo crear una red virtual con una subred para nodos y una subred para pods y crear un clúster que use Azure CNI con asignación estática de bloques CIDR. Asegúrese de reemplazar variables como $subscription por sus valores.

Cree la red virtual con dos subredes.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="myRegion"

# Create the resource group
az group create --name $resourceGroup --location $location

# Create our two subnet network 
az network vnet create --resource-group $resourceGroup --location $location --name $vnet --address-prefixes 10.0.0.0/8 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o none 
az network vnet subnet create --resource-group $resourceGroup --vnet-name $vnet --name podsubnet --address-prefixes 10.40.0.0/13 -o none

Cree el clúster, haciendo referencia a la subred del nodo mediante --vnet-subnet-id, la subred de pods mediante --pod-subnet-id, --pod-ip-allocation-mode para definir el modo de asignación de direcciones IP, y habilite el complemento de supervisión.

clusterName="myAKSCluster"
subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --max-pods 250 \
    --node-count 2 \
    --network-plugin azure \
    --pod-ip-allocation-mode StaticBlock \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/nodesubnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/podsubnet \
    --enable-addons monitoring \
    --generate-ssh-keys

Adición de grupo de nodos

Al agregar un grupo de nodos, haga referencia a la subred del nodo mediante --vnet-subnet-id, a la subred de pods mediante --pod-subnet-id y al modo de asignación mediante "--pod-ip-allocation-mode". En el ejemplo siguiente se crean dos nuevas subredes a las que se hace referencia durante la creación de un nuevo grupo de nodos:

az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes 10.242.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes 10.243.0.0/16 -o none 

az aks nodepool add --cluster-name $clusterName -g $resourceGroup  -n newnodepool \
    --max-pods 250 \
    --node-count 2 \
    --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/node2subnet \
    --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/pod2subnet \
    --pod-ip-allocation-mode StaticBlock \
    --no-wait

Preguntas más frecuentes sobre la asignación estática de bloques CIDR y la compatibilidad con subredes mejoradas

  • ¿Puedo asignar varias subredes de pods a un clúster?

    Se pueden asignar varias subredes a un clúster, pero solo se puede asignar una subred a cada grupo de nodos. Los distintos grupos de nodos en el mismo clúster o diferente pueden compartir la misma subred.

  • ¿Puedo asignar subredes de pod de una red virtual diferente?

    No, la subred de pod debe ser de la misma red virtual que el clúster.

  • ¿Pueden algunos grupos de nodos de un clúster usar la asignación dinámica de IP, mientras que otras usen la nueva asignación estática de bloques?

    Sí, los distintos grupos de nodos pueden usar diferentes modos de asignación. Sin embargo, una vez que se usa una subred en un modo de asignación, solo se puede usar en el mismo modo de asignación en todos los grupos de nodos asociados.

Pasos siguientes

Más información acerca de las redes en AKS en los siguientes artículos: