Configuración de redes de superposición de Azure CNI en Azure Kubernetes Service (AKS)

  • Artículo

El tradicional Azure Container Networking Interface (CNI) asigna una dirección IP de red virtual a cada pod. Asigna esta dirección IP desde un conjunto de IP reservado previamente en cada nodo o una subred separada reservada para los pods. Este enfoque requiere el planeamiento de direcciones IP y podría dar lugar al agotamiento de direcciones, lo que supondría una dificultad para escalar los clústeres a medida que aumente la demanda de la aplicación.

Con Azure CNI Overlay, los nodos del clúster se implementan en una subred de Azure Virtual Network (VNet). Los pods son direcciones IP asignadas desde un CIDR privado que es diferente lógicamente a la red virtual que hospeda los nodos. El tráfico de nodos y pods dentro del clúster usa una red superpuesta. La traducción de direcciones de red (NAT) usa la dirección IP del nodo para llegar a los recursos fuera del clúster. Esta solución ahorra una cantidad significativa de direcciones IP de red virtual y le permite escalar el clúster a tamaños grandes. Una ventaja añadida es que puede reutilizar el CIDR privado en diferentes clústeres AKS, lo que amplía el espacio IP disponible para aplicaciones contenedorizadas en Azure Kubernetes Service (AKS).

Introducción a las redes de superposición

En las redes superpuestas, solo los nodos del clúster de Kubernetes se asignan direcciones IP desde subredes. Los pods reciben direcciones IP de un CIDR privado que se proporciona en el momento de la creación del clúster. A cada nodo se le asigna un espacio de direcciones /24 extraído del mismo CIDR. Los nodos adicionales que se crean al escalar horizontalmente un clúster reciben automáticamente espacios de direcciones /24 del mismo CIDR. Azure CNI asigna direcciones IP a los pods desde este espacio /24.

Se crea un dominio de enrutamiento independiente en la pila de redes de Azure para el espacio del CIDR privado del pod, que crea una red de superposición para la comunicación directa entre pods. No es necesario aprovisionar rutas personalizadas en la subred del clúster ni usar un método de encapsulación para tunelizar el tráfico entre pods, lo que proporciona rendimiento de conectividad entre pods a par con máquinas virtuales en una red virtual. Las cargas de trabajo que se ejecutan en los pods ni siquiera son conscientes de que se está produciendo la manipulación de direcciones de red.

Diagrama que muestra dos nodos con tres pods cada uno que ejecutan una red de superposición. El tráfico de los pods a los puntos de conexión fuera del clúster se enruta mediante NAT.

La comunicación con puntos de conexión fuera del clúster, como redes virtuales locales y emparejadas, se produce con la dirección IP del nodo mediante NAT. Azure CNI traduce la dirección IP de origen (dirección IP de superposición del pod) del tráfico a la dirección IP principal de la máquina virtual, lo que permite que la pila de redes de Azure enrute el tráfico al destino. Los puntos de conexión fuera del clúster no se pueden conectar directamente a un pod. Tiene que publicar la aplicación del pod como un servicio de equilibrador de carga de Kubernetes para que sea accesible en la red virtual.

Puede proporcionar conectividad de salida a Internet para los pods de superposición mediante una SKU Estándar de Load Balancer o una instancia administrada de NAT Gateway. También puede controlar el tráfico de salida si lo dirige a un firewall mediante rutas definidas por el usuario en la subred del clúster.

Puede configurar la conectividad de entrada al clúster mediante un controlador de entrada como Nginx o el enrutamiento de aplicaciones HTTP. No se puede configurar la conectividad de entrada mediante Azure Application Gateway. Para obtener más información, consulte Limitaciones de la superposición de Azure CNI.

Diferencias entre Kubenet y la superposición de Azure CNI

Al igual que la superposición de Azure CNI, Kubenet asigna direcciones IP a pods desde un espacio de direcciones lógicamente diferente de la red virtual, pero tiene limitaciones de escalado y otras limitaciones. En la tabla siguiente, se proporciona una comparación detallada entre Kubenet y la superposición de Azure CNI. Si no desea asignar direcciones IP de red virtual a pods debido a la escasez de direcciones IP, se recomienda usar la superposición de Azure CNI.

Área Superposición de Azure CNI Kubenet
Escalado de clústeres 5000 nodos y 250 pods/nodo 400 nodos y 250 pods/nodo
Network configuration (Configuración de red) Simple: no se requiere ninguna configuración adicional para las redes de los pods Compleja: requiere tablas de rutas y UDR en la subred del clúster para las redes de los pods.
Rendimiento de la conectividad de los pods Rendimiento a la par de las máquinas virtuales de una red virtual El salto adicional agrega latencia
Directivas de red de Kubernetes Directivas de red de Azure, Calico, Cilium Calico
Plataformas de sistema operativo compatibles Linux y Windows Server 2022, 2019 solo Linux.

Planeación de direcciones IP

  • Nodos de clúster: al configurar el clúster de AKS, asegúrese de que las subredes de red virtual tengan suficiente espacio para crecer para el escalado futuro. Puede asignar cada grupo de nodos a una subred dedicada. En una /24subred caben hasta 251 nodos, ya que las tres primeras direcciones IP se reservan para tareas de administración.
  • Pods: la solución de superposición asigna un espacio de direcciones /24 para los pods en cada nodo desde el CIDR privado que especifique durante la creación del clúster. El tamaño /24 es fijo y no se puede aumentar ni disminuir. Puede ejecutar hasta 250 pods en un nodo. Al planear el espacio de direcciones de los pods, asegúrese de que el CIDR privado sea lo suficientemente grande como para proporcionar espacios de direcciones /24 para los nodos nuevos con el fin de admitir la expansión futura del clúster.
    • Al planear el espacio de direcciones IP para pods, tenga en cuenta los siguientes factores:
      • Se puede usar el mismo espacio del CIDR de los pods en varios clústeres de AKS independientes de la misma red virtual.
      • El espacio del CIDR de los pods no se debe superponer con el intervalo de la subred del clúster.
      • El espacio CIDR del pod no debe superponerse con redes conectadas directamente (como el emparejamiento de VNet, ExpressRoute o VPN). Si el tráfico externo tiene direcciones IP de origen en el intervalo podCIDR, debe traducirse a una dirección IP no superpuesta a través de SNAT para comunicarse con el clúster.
  • Intervalo de direcciones de servicio de Kubernetes: el tamaño del CIDR de direcciones de servicio depende del número de servicios de clúster que planea crear. Debe ser menor que /12. Este intervalo no se debe superponer con el intervalo del CIDR de los pods, el intervalo de la subred del clúster y el intervalo IP que se usa en las redes virtuales emparejadas y las redes locales.
  • Dirección IP del servicio DNS de Kubernetes: esta dirección IP está dentro del intervalo de direcciones de servicio de Kubernetes que se usa para la detección de servicios del clúster. No use la primera dirección IP del intervalo de direcciones, ya que esta dirección se usa para la dirección kubernetes.default.svc.cluster.local.

Grupos de seguridad de red

El tráfico de pod a pod con la superposición de Azure CNI no está encapsulado y se aplican reglas del grupo de seguridad de red de subred. Si el grupo de seguridad de red de subred contiene reglas de denegación que afectarían al tráfico CIDR del pod, asegúrese de que se han implementado las siguientes reglas para garantizar la correcta funcionalidad del clúster (además de todos los requisitos de salida de AKS):

  • Tráfico del CIDR del nodo al CIDR del nodo en todos los puertos y protocolos
  • Tráfico del CIDR del nodo al CIDR del pod en todos los puertos y protocolos (necesario para el enrutamiento del tráfico del servicio)
  • Tráfico del CIDR del pod al CIDR del pod en todos los puertos y protocolos (necesario para pod a pod y pod al tráfico de servicio, incluido el DNS)

El tráfico de un pod a cualquier destino fuera del bloque CIDR del pod usa SNAT para establecer la dirección IP de origen en la dirección IP del nodo donde se ejecuta el pod.

Si desea restringir el tráfico entre cargas de trabajo en el clúster, se recomienda usar directivas de red.

Pods máximos por nodo

Puede configurar el número máximo de pods por nodo en el momento de la creación del clúster o al agregar un nuevo grupo de nodos. El valor predeterminado para la superposición de Azure CNI es 250. El valor máximo que puede especificar en la superposición de Azure CNI es 250 y el valor mínimo es 10. El valor del número máximo de pods por nodo configurado durante la creación de un grupo de nodos solo se aplica a los nodos de ese grupo de nodos.

Selección del modelo de red que se va utilizar

Azure CNI ofrece dos opciones de direccionamiento IP para pods: la configuración tradicional, que asigna direcciones IP de red virtual a los pods, y las redes de superposición. Elegir qué opción utilizar para el clúster de AKS es una cuestión de equilibrar las necesidades de flexibilidad y configuración avanzada. Las consideraciones siguientes ayudan a indicar cuándo puede resultar más conveniente cada modelo de red.

Use redes de superposición cuando:

  • Quiere escalar a un gran número de pods, pero tiene un espacio de direcciones IP limitado en la red virtual.
  • La mayor parte de la comunicación de los pods se realice dentro del clúster.
  • No necesite características avanzadas de AKS, como los nodos virtuales.

Use la opción de red virtual tradicional cuando:

  • Tenga espacio de direcciones IP disponible.
  • La mayor parte de la comunicación de los pods se realice con recursos fuera del clúster.
  • Los recursos fuera del clúster deben acceder directamente a los pods.
  • Necesite características avanzadas de AKS, como los nodos virtuales.

Limitaciones de la superposición de Azure CNI

La superposición de Azure CNI tiene las siguientes limitaciones:

  • No se puede usar Application Gateway como controlador de entrada (AGIC) para un clúster de superposición.
  • No se admiten conjuntos de disponibilidad de máquinas virtuales (VMAS) para la superposición.
  • No puede usar máquinas virtuales de la serie DCsv2 en grupos de nodos. Para cumplir los requisitos de computación confidencial, considere la posibilidad de usar máquinas virtuales confidenciales de la serie DCasv5 o DCadsv5 en su lugar.
  • En caso de que use su propia subred para implementar el clúster, los nombres de la subred, la red virtual y el grupo de recursos que contiene la red virtual deben tener 63 caracteres o menos. Esto se debe a que estos nombres se usarán como etiquetas en los nodos de trabajo de AKS y, por tanto, están sujetos a reglas de sintaxis de etiquetas de Kubernetes.

Configuración de clústeres de superposición

Nota

Debe tener la versión 2.48.0 de la CLI o posterior para usar el --network-plugin-mode argumento. Para Windows, debe tener instalada la extensión de la CLI de Azure aks-preview más reciente y puede seguir las instrucciones siguientes.

Cree un clúster con superposición de Azure CNI mediante el comando az aks create. Use el argumento --network-plugin-mode para especificar que se trata de un clúster de superposición. Si no se especifica el CIDR de los pods, AKS asigna un espacio predeterminado: viz. 10.244.0.0/16.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

Adición de un nuevo grupo de nodos a una subred dedicada

Después de crear un clúster con la superposición de Azure CNI, puede crear otro grupo de nodos y asignar los nodos a una nueva subred de la misma red virtual. Este enfoque puede ser útil si desea controlar las direcciones IP de entrada o salida del host desde o hacia los destinos de la misma red virtual o redes virtuales emparejadas.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Actualización de un clúster existente a la superposición de CNI

Nota

Es posible actualizar un clúster de Azure CNI existente para la superposición si el clúster cumple los siguientes criterios:

  • El clúster está en la versión 1.22 y posteriores de Kubernetes.
  • No utiliza la característica de asignación de IP de pod dinámica.
  • No tiene habilitadas directivas de red. El motor de directivas de red se puede desinstalar antes de la actualización; consulte Desinstalar Azure Network Policy Manager o Calico
  • No usa ningún grupo de nodos de Windows con Docker como runtime del contenedor.

Nota:

Debido a que el dominio de enrutamiento aún no es compatible con ARM, CNI Overlay aún no es compatible con nodos de procesador basados en ARM (ARM64).

Nota:

La actualización de un clúster existente a la superposición de CNI es un proceso no reversible.

Advertencia

Antes de la compilación 20348.1668 del SO Windows, existía una limitación en torno a los pods de superposición de Windows que incorrectamente llevaban a cabo el SNAT de paquetes de pods de red de host. Esto tenía un efecto más perjudicial para los clústeres que se actualicen a la superposición. Para evitar este problema, use la compilación del sistema operativo Windows mayor o igual que 20348.1668.

Advertencia

Si usa una configuración personalizada de azure-ip-masq-agent para incluir intervalos IP adicionales que no deben usar paquetes de SNAT de los pods, la actualización a la superposición de Azure CNI puede interrumpir la conectividad con estos intervalos. Las direcciones IP de pod del espacio de superposición no serán accesibles por nada fuera de los nodos del clúster. Además, en el caso de los clústeres suficientemente antiguos, puede que se haya dejado un elemento ConfigMap de una versión anterior de azure-ip-masq-agent. Si este objeto ConfigMap, denominado azure-ip-masq-agent-config, existe y no está intencionalmente en contexto, debe eliminarse antes de ejecutar el comando update. Si no usa una configuración personalizada de ip-masq-agent, solo debe existir configMap azure-ip-masq-agent-config-reconciled con respecto a Azure ip-masq-agent ConfigMaps y se actualizará automáticamente durante el proceso de actualización.

El proceso de actualización desencadena que se vuelva a crear la imagen inicial de cada grupo de nodos simultáneamente. No se admite la actualización de cada grupo de nodos por separado a la superposición. Las interrupciones en las redes de clúster son similares a una actualización de imagen de nodo o a una actualización de la versión de Kubernetes en la que se volverá a crear la imagen de cada nodo de un grupo de nodos.

Actualización del clúster de Azure CNI

Actualice un clúster de Azure CNI existente para usar la superposición mediante el comando az aks update.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

El parámetro --pod-cidr es necesario cuando se actualiza desde CNI heredado porque los pods necesitan obtener IP de un nuevo espacio de superposición que no se superponga con la subred de nodos existente. El CIDR de pods tampoco se puede superponer con ninguna dirección de red virtual de los grupos de nodos. Por ejemplo, si la dirección de la red virtual es 10.0.0.0/8 y los nodos están en la subred 10.240.0.0/16, no se puede superponer el --pod-cidr con 10.0.0.0/8 o el CIDR del servicio existente en el clúster.

Actualización del clúster de Kubenet

Actualice un clúster de Kubenet existente para usar la superposición de Azure CNI mediante el comando az aks update.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay

Dado que el clúster ya usa un CIDR privado para pods que no se superponen con el espacio IP de la red virtual, no es necesario especificar el parámetro --pod-cidr y el CIDR de Pod seguirá siendo el mismo.

Nota:

Al actualizar de Kubenet a la superposición de CNI, la tabla de rutas ya no será necesaria para el enrutamiento de pods. Si el clúster usa una tabla de rutas proporcionada por el cliente, las rutas que se usaron para dirigir el tráfico del pod al nodo correcto se eliminarán automáticamente durante la operación de migración. Si el clúster usa una tabla de rutas administrada (AKS creó la tabla de rutas y reside en el grupo de recursos del nodo), esa tabla de rutas se eliminará como parte de la migración.

Redes de pila doble

Puede implementar sus clústeres de AKS en modo de pila doble cuando se usan redes de superposición y una red virtual de Azure de pila doble. En esta configuración, los nodos reciben una dirección IPv4 y una IPv6 de la subred de la red virtual de Azure. Los pods reciben una dirección IPv4 y una IPv6 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 traduce las direcciones de red a la dirección IP principal del nodo de la misma familia (IPv4 a IPv4 e IPv6 a IPv6).

Requisitos previos

  • Debe tener la CLI de Azure 2.48.0 o una versión posterior.
  • Kubernetes, versión 1.26.3 o posterior.

Limitaciones

Las siguientes características no se admiten con las redes de pila doble:

  • Grupos de nodos de Windows
  • Directivas de red de Azure
  • Directivas de red de Calico
  • NAT Gateway
  • Complemento de nodos virtuales

Implementar un clúster de AKS de pila doble

Se proporcionan los siguientes atributos para admitir los clústeres de pila doble:

  • --ip-families: toma una lista de familias de direcciones IP separadas por comas para habilitarlas en el clúster.
    • Solo se admiten ipv4 o ipv4,ipv6.
  • --pod-cidrs: toma una lista de intervalos IP de notación CIDR separados por comas desde donde asignar direcciones IP de los pods.
    • La cantidad y el orden de los intervalos de esta lista debe coincidir con el valor que se proporciona a --ip-families.
    • Si no se proporciona ningún valor, se usará el valor predeterminado de 10.244.0.0/16,fd12:3456:789a::/64.
  • --service-cidrs: toma una lista de intervalos IP de notación CIDR separados por comas desde donde asignar direcciones IP de los servicios.
    • La cantidad y el orden de los intervalos de esta lista debe coincidir con el valor que se proporciona a --ip-families.
    • Si no se proporciona ningún valor, se usará el valor predeterminado de 10.0.0.0/16,fd12:3456:789a:1::/108.
    • La subred IPv6 asignada a --service-cidrs no puede ser mayor que /108.

Creación de un clúster de AKS de pila doble

  1. Cree un grupo de recursos de Azure para el clúster con el comando [az group create][az-group-create].

    az group create -l <region> -n <resourceGroupName>

  2. Cree un clúster de AKS de pila doble mediante el comando az aks create con el parámetro --ip-families establecido en ipv4,ipv6.

    az aks create -l <region> -g <resourceGroupName> -n <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

Creación de una carga de trabajo de ejemplo

Una vez creado el clúster, puede implementar las cargas de trabajo. Este artículo le guía a través de una implementación de carga de trabajo de ejemplo de un servidor web NGINX.

Instalación de un servidor web NGINX

El complemento de enrutamiento de aplicaciones es la manera recomendada para la entrada en un clúster de AKS. Para obtener más información sobre el complemento de enrutamiento de aplicaciones y un ejemplo de cómo implementar una aplicación con el complemento, consulte Entrada NGINX administrada con el complemento de enrutamiento de aplicaciones.

Exposición de la carga de trabajo a través de un servicio de tipo LoadBalancer

Importante

Actualmente, hay dos limitaciones relacionadas con los servicios IPv6 en AKS.

  • Azure Load Balancer envía sondeos de estado a los destinos IPv6 desde una dirección local de vínculo. En los grupos de nodos Azure Linux este tráfico no se puede enrutar a un pod, por lo que se produce un error en el tráfico que fluye a los servicios IPv6 implementados con externalTrafficPolicy: Cluster. Los servicios IPv6 se deben implementar con externalTrafficPolicy: Local, lo que hace que kube-proxy responda al sondeo en el nodo.
  • Antes de Kubernetes versión 1.27, solo se aprovisionaba la primera dirección IP de un servicio en el equilibrador de carga, por lo que un servicio de pila doble solo recibía una IP pública para la primera familia de direcciones IP enumeradas. A fin de proporcionar un servicio de pila doble para una implementación única, cree dos servicios destinados al mismo selector: uno para IPv4 y el otro para IPv6. Esto ya no es una limitación en Kubernetes 1.27 o posterior.

  1. Exponga la implementación de NGINX mediante el comando kubectl expose deployment nginx.

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    Recibe una salida que muestra que los servicios se han expuesto.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. Una vez que la implementación se expone y los servicios LoadBalancer están completamente aprovisionados, obtenga las direcciones IP de los servicios mediante el comando kubectl get services.

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. Compruebe la funcionalidad a través de una solicitud web de línea de comandos desde un host compatible con IPv6. Azure Cloud Shell no es compatible con IPv6.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

Pasos siguientes

Para obtener información sobre cómo usar AKS con su propio complemento Container Network Interface (CNI), consulte Utilice su propio complemento Container Network Interface (CNI) con Azure Kubernetes Service (AKS).