Información general sobre las configuraciones de red para el aprovisionamiento automático de nodos (NAP) en Azure Kubernetes Service (AKS)

En este artículo se proporciona información general sobre los requisitos y recomendaciones de configuración de red para los clústeres de Azure Kubernetes Service (AKS) mediante el aprovisionamiento automático de nodos (NAP). Trata las configuraciones admitidas, el comportamiento predeterminado de la subred, la configuración del control de acceso basado en rol (RBAC) y las consideraciones de enrutamiento entre dominios (CIDR) sin clases.

Para obtener información general sobre el aprovisionamiento automático de nodos en AKS, consulte Introducción al aprovisionamiento automático de nodos (NAP) en Azure Kubernetes Service (AKS).

Configuraciones de red admitidas para NAP

Al evaluar la compatibilidad de redes con NAP, considere el modo de administración de direcciones IP (IPAM), el complemento de red, el plano de datos de red y la directiva de red. En la tabla siguiente se describen las opciones admitidas por NAP:

Capa de configuración Option Soporte para NAP
IPAM Superposición de Azure CNI Soportado
IPAM Azure subred del nodo CNI Soportado
IPAM Subred de pod de CNI de Azure con asignación de IP dinámica No soportado
Complemento de red Kubenet No soportado
Plano de datos Azure CNI con tecnología de Cilium Compatible con un modo IPAM de CNI compatible con Azure
Directiva de red Calico No soportado

Use Azure CNI Overlay con el plano de datos Azure CNI Powered by Cilium. Cilium proporciona funcionalidades de red avanzadas y está optimizada para el rendimiento con NAP.

Configuraciones de subred para NAP

Establezca el campo opcional vnetSubnetID en un AKSNodeClass recurso para configurar la subred personalizada que Karpenter usa para aprovisionar nodos NAP. Si no especifica vnetSubnetID, Karpenter usa la subred predeterminada configurada durante la instalación, que suele ser la subred especificada por el --vnet-subnet-id parámetro al crear el clúster de AKS.

NAP implementa, configura y administra automáticamente Karpenter en el clúster de AKS y se basa en los proyectos de proveedor Karpenter y AKS Karpenter de código abierto.

AKSNodeClass los recursos de tu clúster de AKS pueden especificar cada uno un vnetSubnetID diferente, lo que permite configuraciones de subred mixtas entre grupos de nodos. Las clases de nodo que no especifican vnetSubnetID usan la configuración de subred predeterminada del clúster.

Comportamiento del desfase de subred

Karpenter supervisa los cambios de configuración de subred y detecta el desfase cuando se modifica el vnetSubnetID en un AKSNodeClass. Comprender este comportamiento es fundamental al administrar configuraciones de red personalizadas.

En los clústeres que usan una red virtual personalizada, cambiar vnetSubnetID de una subred válida a otra hace que los nodos existentes asociados a AKSNodeClass se desincronicen. Karpenter crea nodos de reemplazo en la nueva subred e interrumpe correctamente los nodos desfasados según los NodePool presupuestos de interrupciones.

Antes de cambiar vnetSubnetID, asegúrese de que la identidad del clúster tenga los permisos necesarios en la nueva subred y de que la subred tenga suficientes direcciones IP disponibles para los nodos de reemplazo. Los presupuestos de interrupción de pods y las anotaciones karpenter.sh/do-not-disrupt pueden retrasar el reemplazo voluntario por deriva.

Importante

Las redes virtuales administradas por AKS no admiten subredes personalizadas. Utilice vnetSubnetID únicamente con una red virtual personalizada que gestione usted.

Rangos CIDR del clúster de AKS para NAP

Al configurar redes personalizadas con vnetSubnetID, debe comprender y administrar los intervalos CIDR del clúster para evitar conflictos de red. A diferencia de los grupos de nodos de AKS tradicionales que se crean a través de plantillas de Azure Resource Manager (ARM), Karpenter aplica definiciones de recursos personalizadas (CRD) que aprovisionan nodos de forma instantánea sin la validación extendida que proporciona ARM.

Consideraciones de CIDR para las configuraciones de subred personalizadas de NAP

Al configurar vnetSubnetID, debe:

  • Comprobar la compatibilidad de CIDR: asegúrese de que las subredes personalizadas no entren en conflicto con los intervalos CIDR existentes.
  • Planear la capacidad de IP: calcule las direcciones IP necesarias para el escalado esperado.
  • Validar la conectividad: pruebe las rutas de red y las reglas del grupo de seguridad.
  • Supervisión del uso: realice un seguimiento del uso de la subred y planee el crecimiento.
  • Configuración del documento: mantenga registros de decisiones de diseño de red.

Conflictos de CIDR comunes

Tenga en cuenta los siguientes escenarios comunes de conflicto CIDR al usar subredes personalizadas con NAP:

En los ejemplos siguientes se muestran los rangos CIDR de subred que entran en conflicto con los CIDR de pods y de servicios del clúster, junto con una configuración que evita esos conflictos. Use estos patrones para validar los intervalos de subred antes de configurar vnetSubnetID.

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

Configuración de RBAC para configuraciones de subred personalizadas

Al usar configuraciones de subred personalizadas con NAP, debe asegurarse de que Karpenter tiene los permisos necesarios para leer la información de subred y unir nodos a las subredes especificadas. Esto requiere configurar los permisos RBAC adecuados para la identidad administrada del clúster.

La persona que ejecuta los siguientes comandos debe tener permiso para crear la definición de rol necesaria y las asignaciones de roles, como el rol de Administrador del control de acceso basado en roles. No conceda permisos de escritura de asignación de roles a la identidad del clúster a menos que necesite crear asignaciones de roles para otro escenario.

Obtenga el identificador principal de la identidad administrada del clúster. Use el comando correspondiente al tipo de identidad del clúster:

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

Hay dos enfoques principales para configurar estos permisos: asignar permisos de red virtual (VNet) amplios o Asignar permisos de subred con ámbito.

Este enfoque es el más permisivo y concede los permisos de identidad del clúster para leer y unir cualquier subred dentro de la red virtual principal y proporciona acceso de colaborador de red.

Importante

El rol de Colaborador de red concede Microsoft.Network/*, lo que permite a la identidad del clúster crear, modificar y eliminar recursos de red dentro del ámbito de la red virtual asignada. Revise este acceso antes de usar el rol en producción, porque NAP solo requiere permisos de lectura y de unión de subred para este escenario.

Ventajas y consideraciones

En la tabla siguiente se describen los inconvenientes de asignar el rol Colaborador de red en el ámbito de la red virtual.

Ventajas de permisos amplios de red virtual Consideraciones para permisos amplios de red virtual
• Simplifica la administración de permisos.
• Elimina la necesidad de actualizar los permisos al agregar nuevas subredes.
• Funciona bien para entornos de un solo inquilino.
• Funciones cuando una suscripción alcanza el número máximo de roles personalizados.		 • Proporciona permisos más amplios de los estrictamente necesarios.
• Podría no cumplir los estrictos requisitos de seguridad.

Permisos necesarios

Para asignar permisos amplios de red virtual, conceda a la identidad administrada del clúster los permisos siguientes en la red virtual:

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Network Contributor" \
  --scope $VNET_ID

Para ver un ejemplo completo de cómo configurar una VNet personalizada y asignar permisos amplios a la VNet, consulte el script de ejemplo Configuración de VNet personalizada - RBAC con los permisos más amplios.

Configuraciones de subred personalizadas de ejemplo

En el ejemplo siguiente se muestra cómo configurar una subred personalizada para los nodos NAP mediante el vnetSubnetID campo de un AKSNodeClass recurso:

Establezca el spec.vnetSubnetID campo en el identificador de recurso completo Azure de la subred de destino mediante el formato /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

En el ejemplo siguiente se muestra cómo usar varias clases de nodo con distintas configuraciones de subred:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Política de soporte de Bring Your Own CNI (BYO CNI)

Karpenter para Azure permite tener sus propias configuraciones de interfaz de red de contenedor (BYO CNI) y sigue la misma directiva de soporte técnico que AKS. BYO CNI no hace que una configuración que NAP enumera como no admitida, como kubenet o Calico, pase a ser compatible. Cuando se usa un CNI personalizado, la solución de problemas de soporte técnico relacionado con las redes está fuera del ámbito de los contratos o garantías de nivel de servicio.

Detalles del ámbito de soporte técnico

A continuación se describe lo que se admite y no se admite al usar BYO CNI con Karpenter:

  • Admitido: problemas de integración y funcionalidad específicos de Karpenter al utilizar configuraciones de CNI propias (BYO).
  • No compatible: problemas de red específicos de CNI, problemas de configuración o solución de problemas al usar complementos de CNI de terceros.

Pasos siguientes

Para obtener más información sobre el aprovisionamiento automático de nodos en AKS, consulte los siguientes artículos:

  • Se actualizó por última vez el