Compartir a través de

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

NAP admite las siguientes configuraciones de red:

Se recomienda usar Azure CNI con Cilium. Cilium proporciona funcionalidades de red avanzadas y está optimizada para el rendimiento con NAP.

Configuraciones de red no admitidas para NAP

NAP no admite las siguientes configuraciones de red:

  • Directiva de red de Calico
  • Asignación dinámica de IP

Configuraciones de subred para NAP

NAP implementa, configura y administra automáticamente Karpenter en los clústeres de AKS y se basa en los proyectos de proveedor Karpenter y AKS Karpenter de código abierto. Puede usar recursos de AKSNodeClass para especificar configuraciones de subred personalizadas para los nodos NAP en sus grupos de nodos, estableciendo el campo opcional vnetSubnetID, y Karpenter usa la subred que especifique para el aprovisionamiento de nodos. Si no especifica una subred, Karpenter usa la subred predeterminada configurada durante la instalación de Karpenter. Esta subred predeterminada suele ser la misma subred especificada durante la creación del clúster de AKS con el --vnet-subnet-id parámetro en el az aks create comando .

Este enfoque permite tener una combinación de clases de nodo, con algunas que usan subredes personalizadas para cargas de trabajo específicas y otras mediante 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.

La modificación vnetSubnetID de una subred válida a otra subred válida no es una operación admitida. Si cambia vnetSubnetID para que apunte a una subred válida diferente, Karpenter lo detecta como una desviación de subred y evita el aprovisionamiento de nodos hasta que el problema se resuelva revirtiendo vnetSubnetID a la subred original. Este comportamiento garantiza que los nodos solo se aprovisionan en las subredes previstas, manteniendo la integridad y la seguridad de la red. Sin embargo, hay excepciones a esta regla. Solo puede modificar el vnetSubnetID en los siguientes escenarios:

  • Corregir un identificador de subred con formato incorrecto que impide el aprovisionamiento de nodos.
  • Corrección de una referencia de subred no válida que provoca errores de configuración.
  • Actualizando un identificador de subred que apunta a una subred inexistente o inaccesible.

Descripción de los intervalos de Enrutamiento de interdominios sin clases (CIDR) de clúster de AKS

Al configurar redes personalizadas con vnetSubnetID, usted es responsable de comprender y administrar los intervalos CIDR del clúster para evitar conflictos de red. A diferencia de los grupos de nodos de AKS tradicionales creados a través de plantillas de 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 configuraciones de subred personalizadas

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:

# 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.

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

Investigue el rol "Colaborador de red" antes de aplicar este enfoque al clúster de producción.

Ventajas y consideraciones

En la tabla siguiente se describen las ventajas y consideraciones de asignación de permisos amplios de red virtual:

Ventajas Consideraciones
• 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 cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# 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 $CLUSTER_IDENTITY \
  --role "Network Contributor" \
  --scope $VNET_ID

Para obtener un ejemplo completo de cómo configurar redes personalizadas y asignar permisos amplios de VNet, vea Configuración de VNet personalizada: script de ejemplo de RBAC más permisivo.

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:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$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/$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/$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), siguiendo la misma directiva de soporte técnico que AKS. Esto significa que cuando se usa un CNI personalizado, la solución de problemas de soporte técnico relacionado con las redes está fuera del ámbito de cualquier contrato o garantía 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:

  • Last updated on