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

De forma predeterminada, los clústeres de AKS usan kubenet, y una red virtual de Azure y una subred se crean automáticamente. 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 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. 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.

Prerrequisitos

  • 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.
  • La identidad de clúster que usa el clúster de AKS debe tener al menos el rol de Colaborador de la red en la subred de la red virtual. La CLI ayuda a realizar la asignación de roles automáticamente. Si usa la plantilla de ARM u otros clientes, la asignación de roles debe realizarse manualmente. 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 de colaborador de red, se requieren 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 uso de kubenet como modelo de red 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 subredes y redes virtuales con intervalos de direcciones IP asignados. Estos recursos de red virtual se usan 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. De forma predeterminada, el servicio AKS crea y mantiene la configuración de reenvío de UDR e IP, pero existe la opción de traer su propia tabla de rutas para la administración personalizada de rutas. También podría 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:

Modelo de red kubenet con un clúster de AKS

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. Puede usar las directivas de red de Calico, ya que son compatibles con kubenet.

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, el intervalo de direcciones IP debe planearse 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.
  • 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:

Disponibilidad y agotamiento de las direcciones IP

Con Azure CNI, un problema común es que el intervalo de direcciones IP asignado es demasiado pequeño para agregar nodos adicionales cuando se escala o actualiza un clúster. Puede que el equipo de red no sea 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 admitiría 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 puede configurar con kubenet en AKS es 110.

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

  • kubenet: un intervalo sencillo de direcciones IP de /24 puede admitir hasta 251 en el clúster (cada subred de red virtual de Azure reserva las tres primeras direcciones IP para operaciones de administración).
    • Este número de nodos podría admitir hasta 27610 pods (con una capacidad máxima predeterminada de 110 pods por nodo con kubenet).
  • 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 podría admitir solo hasta 240 pods (con una capacidad máxima predeterminada de 30 pods por nodo con Azure CNI).

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 usarlas durante el escalado o las operaciones de 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. Es aconsejable 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

Elegir qué complemento de red utilizar para el clúster de AKS suele ser 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 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 directivas de red de Calico.

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. Use directivas de red de Calico.

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

Para empezar a usar kubenet y su propia subred de red virtual, primero cree un grupo de recursos mediante el comando az group create. En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la ubicación eastus:

az group create --name myResourceGroup --location eastus

Si no tiene una subred y red virtual existentes para usarlas, cree estos recursos de red con el comando az network vnet create. En el ejemplo siguiente, la red virtual se denomina myAKSVnet y tiene el prefijo de dirección de 192.168.0.0/16. Se crea una subred llamada 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

Obtenga el identificador de recurso de subred y almacénelo como una variable:

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

Ahora cree un clúster de AKS en la red virtual y la subred con el comando az aks create.

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

Puede crear un clúster de AKS mediante una identidad administrada asignada por el sistema mediante la ejecución del siguiente comando de la CLI.

Nota:

Al usar la identidad asignada por el sistema, azure-cli concederá 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.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID 

Nota

Si quiere permitir que un clúster de AKS incluya una directiva de red de Calico, puede usar el siguiente comando.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet --network-policy calico \
    --vnet-subnet-id $SUBNET_ID 

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

Creación u obtención de una identidad administrada

Si aún no tiene una identidad administrada, debería crear una mediante la ejecución del comando az identity.

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

La salida debe ser similar a la 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"
}

Si tiene una identidad administrada existente, puede encontrar el identificador de entidad de seguridad ejecutando el siguiente comando:

az identity show --ids <identity-resource-id>

La salida debe ser similar a la siguiente:

{
  "clientId": "<client-id>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",
  "location": "eastus",
  "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 agregará 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.

Para asignar las delegaciones correctas en los pasos restantes, use los comandos az network vnet show y az network vnet subnet show para obtener los identificadores de recursos necesarios. Estos identificadores de recursos se almacenan como variables y se hace referencia a ellos en los pasos restantes:

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

Ahora, 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. Proporcione el valor <principalId> como se muestra en la salida del comando anterior para crear la identidad:

az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

Ejemplo:

az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/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

Ahora puede crear un clúster de AKS con la identidad administrada asignada por el usuario mediante la ejecución del siguiente comando de la CLI. Proporcione el identificador de recurso de la identidad del plano de control mediante assign-identity.

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

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 desde el 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

Se pueden agregar y actualizar reglas personalizadas en la tabla de rutas personalizadas. Sin embargo, el proveedor en la nube de Kubernetes agrega reglas que no se deben 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 reglas de hacerlo solo con sus reglas personalizadas.

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 inesperado y discontinuo. Al configurar varios clústeres en la misma red virtual o dedicar una red virtual a cada clúster, asegúrese de que se tienen en cuenta las siguientes limitaciones.

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. Aunque no se puede actualizar el recurso de la tabla de rutas, se pueden modificar las reglas personalizadas 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 una identidad administrada asignada por el sistema, solo se admite para proporcionar su propia subred y tabla de rutas mediante la CLI de Azure. Esto se debe a que la CLI agregará 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:

Para crear y usar su propia red virtual y tabla de rutas con el complemento de red kubenet, debe usar la identidad del plano de control asignado por el usuario. En el caso de la identidad del plano de control asignado por el sistema, el identificador de identidad no se puede recuperar antes de crear un clúster, lo que provoca un retraso durante la asignación de roles.

Para crear y usar su propia red virtual y tabla de rutas con el complemento de red azure, se admiten identidades administradas asignadas por el sistema y asignadas por el usuario. Pero se recomienda más la identidad administrada asignada por el usuario para escenarios BYO.

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.

# Find your subnet ID
az network vnet subnet list --resource-group
                            --vnet-name
                            [--subscription]
# Create a kubernetes cluster with with a custom subnet preconfigured with a route table
az aks create -g myResourceGroup -n myManagedCluster --vnet-subnet-id mySubnetIDResourceID --enable-managed-identity --assign-identity controlPlaneIdentityResourceID

Pasos siguientes

Con un clúster de AKS implementado en la subred de red virtual existente, ahora puede usar el clúster de forma habitual. Empiece a crear aplicaciones con Helm o a implementar aplicaciones existentes con Helm.