Uso de redes kubenet con intervalos de direcciones IP propios en Azure Kubernetes Service (AKS)

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.

Con Azure Container Networking Interface (CNI), cada pod obtiene una dirección IP de la subred, y se puede acceder a él directamente. Estas direcciones IP deben planearse de antemano y deben ser únicas en el espacio de red. 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. 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.

En este artículo se muestra cómo usar las redes kubenet para crear y usar la subred de una red virtual con un clúster de AKS. Para más información sobre las opciones y consideraciones de red, consulte el artículo sobre los conceptos de red para Kubernetes y AKS.

Requisitos previos

• La red virtual del clúster AKS debe permitir la conectividad saliente de Internet.
• No cree más de un clúster AKS en la misma subred.
• 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. Este intervalo no se puede actualizar después de crear el clúster.
• La identidad de clúster que usa el clúster de AKS al menos debe tener el rol de Colaborador de la red en la subred de la red virtual. La CLI ayuda a configurar la asignación de roles automáticamente. Si usa una plantilla de ARM u otros clientes, debe configurar manualmente la asignación de roles. También debe tener los permisos adecuados, como propietario de la suscripción, para crear una identidad del clúster y asignarle permisos. Si quiere definir un rol personalizado en lugar de usar el rol integrado Colaborador de la red, necesita los permisos siguientes:
  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

Advertencia

Para usar grupos de nodos de Windows Server, es preciso utilizar Azure CNI. El modelo de red kubenet no está disponible para contenedores de Windows Server.

Antes de empezar

Es preciso que esté instalada y configurada la versión 2.0.65 de la CLI de Azure, o cualquier otra posterior. Ejecute az --version para encontrar la versión. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

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.

Con Azure CNI, 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. Los escenarios y las características avanzadas de red como los nodos virtuales o las directivas de red (de Azure o Calico) son compatibles con Azure CNI.

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 puede admitir un máximo de ocho 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

Para proporcionar conectividad en el entorno local, los dos enfoques de red kubenet y Azure-CNI pueden usar el emparejamiento de redes virtuales de Azure o las conexiones ExpressRoute. Planee los intervalos de direcciones IP detenidamente para evitar la superposición y un enrutamiento de tráfico incorrecto. 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 crear los clústeres de AKS en las subredes de la red virtual de Azure fuera de este rango de direcciones, como 172.16.0.0/16.

Selección de un modelo de red para usarlo

Las consideraciones siguientes ayudan a indicar cuándo puede resultar más conveniente cada modelo de red:

Use kubenet cuando:

• Tenga un espacio de direcciones IP limitado.
• 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 o la directiva de red de Azure.

Use Azure CNI 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.
• No desea administrar rutas definidas por el usuario para la conectividad pod.
• Necesite características avanzadas de AKS como los nodos virtuales o la directiva de red de Azure.

Para más información que le ayude a decidir qué modelo de red usar, consulte la Comparación de modelos de red y su ámbito de soporte.

Creación de una red virtual y una subred

1. Cree un grupo de recursos con el comando az group create.

   az group create --name myResourceGroup --location eastus
   

2. Si no tiene una subred y red virtual existentes para usarlas, cree estos recursos de red con el comando az network vnet create. El siguiente comando de ejemplo crea una red virtual denominada myAKSVnet con el prefijo de dirección 192.168.0.0/16 y una subred denominada myAKSSubnet con el prefijo de dirección 192.168.1.0/24:

   az network vnet create \
       --resource-group myResourceGroup \
       --name myAKSVnet \
       --address-prefixes 192.168.0.0/16 \
       --subnet-name myAKSSubnet \
       --subnet-prefix 192.168.1.0/24 \
       --location eastus
   

3. Obtenga el identificador de recurso de subred mediante el az network vnet subnet show comando y almacénelo como una variable denominada SUBNET_ID para su uso posterior.

   SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)
   

Creación de un clúster de AKS en la red virtual

Creación de un clúster de AKS con identidades administradas asignadas por el sistema

Nota

Al usar la identidad asignada por el sistema, la CLI de Azure concede el rol Colaborador de red a la identidad asignada por el sistema después de crear el clúster. Si utiliza una plantilla de ARM o de otros clientes, debe usar la identidad administrada asignada por el usuario en su lugar.

• Creación de un clúster de AKS con identidades administradas asignadas por el sistema usando el comando az aks create.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID \
      --generate-ssh-keys 
  

  Parámetros de implementación:

  • --service-cidr es opcional. Esta dirección se usa para asignar una dirección IP a los servicios internos del clúster de AKS. Este intervalo de direcciones IP debe ser un espacio de direcciones que no se esté usando en ningún otro lugar del entorno de red, incluidos los intervalos de red locales, si conecta o tiene previsto conectar las redes virtuales de Azure mediante ExpressRoute o una conexión VPN de sitio a sitio. El valor predeterminado es 10.0.0.0/16.
  • --dns-service-ip es opcional. La dirección debe ser la dirección .10 del intervalo de direcciones IP del servicio. El valor predeterminado es 10.0.0.10.
  • --pod-cidr es opcional. Esta dirección debe ser un espacio de direcciones grande que no se use en ninguna otra parte del entorno de red. Este rango incluye todos los rangos de red local si conecta, o planea conectar, las redes virtuales de Azure mediante ExpressRoute o una conexión VPN de sitio a sitio. El valor predeterminado es 10.244.0.0/16.
    • Este intervalo de direcciones debe ser lo suficientemente grande como para alojar el número de nodos hasta el que pretende escalar verticalmente. No se puede cambiar este intervalo de direcciones una vez implementado el clúster.
    • El intervalo de direcciones IP para pods se usa para asignar un espacio de direcciones de /24 a cada nodo del clúster. En el ejemplo siguiente, --pod-cidr de 10.244.0.0/16 asigna el primer nodo 10.244.0.0/24, el segundo nodo 10.244.1.0/24 y el tercer nodo 10.244.2.0/24.
    • A medida que el clúster se escala o actualiza, la plataforma de Azure continúa asignando un intervalo de direcciones IP para pods a cada nuevo nodo.

Creación de un clúster de AKS con una identidad administrada asignada por el usuario

Creación de una entidad administrada

• Crear una identidad administrada usando el comando az identity. Si tiene una identidad administrada existente, encuentre el identificador de entidad de seguridad usando el comando az identity show --ids <identity-resource-id>, alternativamente.

  az identity create --name myIdentity --resource-group myResourceGroup
  

  La salida debería ser similar a la salida de ejemplo siguiente:

  {                                  
    "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
    "location": "westus2",
    "name": "myIdentity",
    "principalId": "<principal-id>",
    "resourceGroup": "myResourceGroup",                       
    "tags": {},
    "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
  }
  

Incorporación de la asignación de roles para la identidad administrada

Si usa la CLI de Azure, el rol se agrega automáticamente, y puede omitir este paso. Si usa una plantilla de ARM o de otros clientes, deberá usar el identificador principal de la identidad administrada del clúster para realizar una asignación de roles.

• Obtenga el identificador de recurso de redes virtuales mediante el az network vnet show comando y almacénelo como una variable denominada VNET_ID.

  VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)
  

• Asigne la identidad administrada para los permisos de Colaborador de red del clúster de AKS en la red virtual mediante el comando az role assignment create y proporcione el <principalId>.

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

Nota

Cuando se conceda el permiso a la identidad administrada del clúster que usa Azure, este podría tardar hasta 60 minutos en propagarse completamente.

Creación de un clúster de AKS

• Cree un clúster de AKS mediante el comando az aks create y proporcione el identificador de recurso de identidad administrada del plano de control para el argumento assign-identity para asignar la identidad administrada asignada por el usuario.

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --node-count 3 \
      --network-plugin kubenet \
      --vnet-subnet-id $SUBNET_ID \
      --assign-identity <identity-resource-id> \
      --generate-ssh-keys
  

Al crear un clúster de AKS, también se crean automáticamente un grupo de seguridad de red y una tabla de rutas. Estos recursos de red los administra el plano de control de AKS. El grupo de seguridad de red se asocia automáticamente con la tarjetas de interfaz de red virtuales de los nodos. La tabla de ruta se asocia automáticamente con la subred de la red virtual. Las tablas de ruta y las reglas del grupo de seguridad de red se actualizan automáticamente cuando se crean y se exponen los servicios.

Uso de su propia subred y tabla de rutas con Kubenet

Con Kubenet, debe existir una tabla de rutas en las subredes del clúster. AKS admite la incorporación de su subred y tabla de rutas existentes. Si la subred personalizada no contiene ninguna tabla de rutas, AKS crea una automáticamente y le agrega reglas a lo largo del ciclo de vida del clúster. Si la subred personalizada contiene una tabla de rutas al crear el clúster, AKS confirma la tabla de rutas existente durante las operaciones del clúster y agrega o actualiza reglas según corresponde para las operaciones del proveedor de nube.

Advertencia

Puede agregar o actualizar reglas personalizadas en la tabla de rutas personalizada. Sin embargo, el proveedor en la nube de Kubernetes agrega reglas que no se puede actualizar ni quitar. Las reglas como 0.0.0.0/0 deben existir siempre en una tabla de rutas dada y asignarse al destino de la puerta de enlace de Internet, como una NVA u otra puerta de enlace de salida. Tenga cuidado al actualizar las reglas.

Más información sobre la configuración de una tabla de rutas personalizada.

Las redes de Kubenet requieren reglas de tabla de rutas organizadas para redirigir las solicitudes correctamente. Debido a este diseño, las tablas de rutas deben mantenerse cuidadosamente para cada clúster que dependa de estas. Varios clústeres no pueden compartir una tabla de rutas porque los CIDR de pod de distintos clústeres pueden superponerse, lo que provoca un enrutamiento de escenarios inesperado y discontinuo. Al configurar varios clústeres en la misma red virtual o dedicar una red virtual a cada clúster, tenga en cuenta las siguientes limitaciones.

• Una tabla de rutas personalizada debe estar asociada a la subred antes de que cree el clúster de AKS.
• El recurso de la tabla de rutas asociado no se puede actualizar después de crear el clúster. No obstante, las reglas personalizadas pueden modificarse en la tabla de rutas.
• Cada clúster de AKS debe usar una única tabla de rutas para todas las subredes asociadas con el clúster. No se puede reutilizar una tabla de rutas con varios clústeres debido a la posibilidad de que se superpongan los CIDR de pod y las reglas de enrutamiento en conflicto.
• En el caso de la identidad administrada asignada por el sistema, solo se admite proporcionar su propia subred y tabla de rutas a través de la CLI de Azure, ya que la CLI de Azure agrega automáticamente la asignación de roles. Si utiliza una plantilla de ARM o de otros clientes, debe utilizar una identidad administrada asignada por el usuario, asignar permisos antes de la creación del clúster y asegurarse de que la identidad asignada por el usuario tenga permisos de escritura para la subred y la tabla de rutas personalizadas.
• No se admite el uso de la misma tabla de rutas con varios clústeres de AKS.

Nota:

Al crear y usar su propia red virtual y tabla de rutas con el complemento de red de kubenet, debe configurar una identidad administrada asignada por el usuario para el clúster. Con una identidad administrada asignada por el sistema, no puede recuperar el identificador de identidad antes de crear un clúster, lo cual provoca un retraso durante la asignación de roles.

Tanto las identidades administradas asignadas por el sistema como las asignadas por el usuario se admiten cuando crea y utiliza su propia red virtual y tabla de rutas con el complemento de red Azure. Le recomendamos encarecidamente usar una identidad administrada asignada por el usuario para escenarios BYO.

Añadir una tabla de rutas con una identidad administrada asignada por el usuario al clúster de AKS

Después de crear una tabla de rutas personalizada y asociarla a una subred de la red virtual, puede crear un nuevo clúster de AKS que especifique la tabla de rutas con una identidad administrada asignada por el usuario. Debe usar el identificador de subred desde el que tiene previsto implementar el clúster de AKS. Esta subred también debe estar asociada a la tabla de rutas personalizada.

1. Obtenga el identificador de subred mediante el comando az network vnet subnet list.

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. Cree un clúster de AKS con una subred personalizada preconfigurada con una tabla de rutas mediante el comando az aks create y proporcione los valores para los parámetros --vnet-subnet-id y --assign-identity.

   az aks create \
       --resource-group myResourceGroup \
       --name myManagedCluster \
       --vnet-subnet-id mySubnetIDResourceID \
       --assign-identity controlPlaneIdentityResourceID \
       --generate-ssh-keys
   

Pasos siguientes

En este artículo se ha mostrado cómo implementar el clúster de AKS en la subred de red virtual existente. Ahora, puede empezar a crear nuevas aplicaciones mediante Helm o implementar aplicaciones existentes mediante Helm.