Configuración de grupos de nodos para el aprovisionamiento automático de nodos (NAP) en Azure Kubernetes Service (AKS)

En este artículo se explica cómo configurar grupos de nodos para el aprovisionamiento automático de nodos (NAP) en Azure Kubernetes Service (AKS), incluidos selectores de SKU, límites de recursos y pesos de prioridad. También proporciona ejemplos para ayudarle a empezar.

AKS Automatic incluye NAP de forma predeterminada. En el caso de los clústeres estándar de AKS, debe habilitar NAP antes de configurar sus grupos de nodos.

Cómo NAP selecciona VMs para grupos de nodos

NAP usa los requisitos de SKU de máquina virtual (VM) para decidir las mejores máquinas virtuales para cargas de trabajo pendientes. Puede configurar:

  • Familias de SKU y tipos de instancia específicos.
  • Límites y prioridades de recursos.
  • Instancias a petición o de acceso puntual.
  • Arquitectura, GPU y otros requisitos de funcionalidades.

El NodePool recurso establece restricciones para los nodos creados por NAP y para los pods que se ejecutan en esos nodos. Al habilitar NAP con la configuración predeterminada del grupo de nodos establecida en Auto, crea recursos NodePool predeterminados. Puede modificar estos grupos de nodos o crear grupos de nodos adicionales para satisfacer los requisitos de carga de trabajo.

Cómo NAP evalúa y selecciona grupos de nodos

Al configurar NodePools para NAP, tenga en cuenta los siguientes comportamientos:

  • NAP requiere al menos una NodePool para funcionar.
  • NAP evalúa cada configuración NodePool.
  • NAP omite NodePools con intolerancias no admitidas por un pod.
  • NAP aplica intolerancias de inicio a los nodos aprovisionados, pero no requiere tolerancia de pods.
  • NAP funciona mejor con NodePools mutuamente excluyentes, cuyos requisitos no se superponen, de modo que cada pod se ajuste a un solo pool. Cuando hay varias NodePools coincidencias, NAP usa la que tiene el peso más alto.

Revisión de la configuración predeterminada del grupo de nodos

La configuración del Karpenter NodePool predeterminado denominado default creado por NAP es el siguiente:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    spec:
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: default
      expireAfter: Never
      # Requirements that constrain the parameters of provisioned nodes.
      # These requirements are combined with pod.spec.affinity.nodeAffinity rules.
      # Operators { In, NotIn, Exists, DoesNotExist, Gt, and Lt } are supported.
      # https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      - key: karpenter.azure.com/sku-family
        operator: In
        values:
        - D

NAP también crea un system-surge grupo de nodos que proporciona capacidad linux AMD64 a petición para complementos críticos del sistema. Cuando un pod pendiente tolera la marca CriticalAddonsOnly=true:NoSchedule y cumple los requisitos del grupo, NAP puede aprovisionar un nodo a partir de este grupo. Los nodos creados por el grupo tienen la etiqueta kubernetes.azure.com/mode: system.

Control de los grupos de nodos predeterminados

Al crear un nuevo clúster de AKS habilitado con NAP mediante el CLI de Azure, incluya la --node-provisioning-default-pools marca para controlar si AKS crea el NAP NodePoolspredeterminado. También puede usar esta marca con az aks update al habilitar NAP en un clúster existente.

La --node-provisioning-default-pools marca acepta los siguientes valores:

  • Auto (valor predeterminado): crea dos estándares NodePools para su uso inmediato.
  • None: No crea ningún NodePools. Debe definirlo usted mismo.

Advertencia

Cambiar de Auto a None: si cambia la configuración de Auto a None en un clúster existente, el valor predeterminado NodePools no se eliminará automáticamente. Antes de eliminarlos, defina la capacidad de reemplazo adecuada para los complementos críticos del sistema. Debe eliminar el valor predeterminado NodePools manualmente si ya no los necesita.

Opciones de configuración del grupo de nodos

En las secciones siguientes se describen varias opciones de configuración para NodePools en NAP, incluidas las etiquetas conocidas y los selectores de SKU, los límites del grupo de nodos y los pesos del grupo de nodos.

Etiquetas conocidas y selectores de SKU

Kubernetes define etiquetas conocidas que Azure implementa. Puede definir estas etiquetas en la spec.requirements sección de la NodePool API. NAP también admite etiquetas específicas de Azure para una programación más avanzada.

En la tabla siguiente se enumeran las etiquetas que puede usar en la sección de la spec.requirements API para definir características de NodePool máquina virtual para los nodos:

Selector Description Example
karpenter.sh/capacity-type Tipo de asignación de máquina virtual (spot/ a petición) Zona
karpenter.azure.com/sku-family Familia de SKU de máquina virtual D, F, L, etc.
karpenter.azure.com/sku-series Series de SKU de VM Dpls_v6
karpenter.azure.com/sku-name Nombre de SKU explícito Standard_A1_v2
karpenter.azure.com/sku-version Versión de SKU (sin "v", puede usar 1) 1, 2
karpenter.azure.com/sku-cpu Número de CPU en la máquina virtual 16
karpenter.azure.com/sku-memory Memoria en la máquina virtual en MiB 131 072
karpenter.azure.com/sku-gpu-name Nombre de GPU A100
karpenter.azure.com/sku-gpu-manufacturer Fabricante de GPU nvidia
karpenter.azure.com/sku-gpu-count Recuento de GPU por máquina virtual 2
karpenter.azure.com/sku-networking-accelerated Si la máquina virtual ha acelerado las redes [verdadero, falso]
karpenter.azure.com/sku-storage-premium-capable Si la máquina virtual admite almacenamiento de E/S Premium [verdadero, falso]
karpenter.azure.com/sku-storage-ephemeralos-maxsize Límite de tamaño para el disco del sistema operativo (SO) efímero en GB 92
kubernetes.azure.com/sku-cpu Número de CPU en la máquina virtual 16
kubernetes.azure.com/sku-memory Memoria en la máquina virtual en MiB 131 072
kubernetes.azure.com/cluster Nombre del clúster de AKS my-cluster
kubernetes.azure.com/mode Modo de grupo de nodos [sistema, usuario]
kubernetes.azure.com/priority Prioridad [al contado, normal]
kubernetes.azure.com/os-sku SKU del sistema operativo [Ubuntu, AzureLinux]
kubernetes.azure.com/fips_enabled Si FIPS está habilitado true
topology.kubernetes.io/zone Zonas de disponibilidad [uksouth-1,uksouth-2,uksouth-3]
kubernetes.io/os Sistema operativo Linux
kubernetes.io/arch Arquitectura de CPU (AMD64 o ARM64) [amd64, arm64]

Los valores del selector de memoria de esta tabla son los valores miB notificados en los nodos creados por NAP. Antes de agregar un selector, inspeccione las etiquetas de los nodos para confirmar el valor usado por el clúster.

Ejemplos de familia de SKU

El karpenter.azure.com/sku-family selector permite establecer como destino familias de máquinas virtuales específicas.

Familia Description
Serie D Máquinas virtuales de uso general con una relación equilibrada de CPU a memoria
Serie F Máquinas virtuales optimizadas para cómputo con una alta proporción de CPU a memoria
Serie E Máquinas virtuales optimizadas para memoria para aplicaciones con uso intensivo de memoria
Serie L Máquinas virtuales optimizadas para almacenamiento con alto rendimiento de disco
Serie N Máquinas virtuales habilitadas para GPU para cargas de trabajo de proceso intensivo

Configuración de ejemplo mediante la familia de SKU:

requirements:
- key: karpenter.azure.com/sku-family
  operator: In
  values:
  - D
  - F

Ejemplo de SKU de GPU

Para aprovisionar nodos de GPU de NVIDIA con NAP, cree un NodePool que seleccione tamaños de máquina virtual habilitados para GPU. En el ejemplo siguiente se permite que NAP seleccione SKU de GPU nvidia de la serie N:

requirements:
- key: karpenter.azure.com/sku-family
  operator: In
  values:
  - N
- key: karpenter.azure.com/sku-gpu-manufacturer
  operator: In
  values:
  - nvidia

Si desea que AKS instale y administre el controlador de GPU NVIDIA, el plugin de dispositivo, el exportador de métricas de Data Center GPU Manager (DCGM) y las señales de estado de la GPU en los nodos de GPU aprovisionados por NAP, configure la opción de GPU administrada en el AKSNodeClass mencionado. Para más información, consulte Creación de un grupo de nodos de GPU administrados por AKS.

Ejemplos de nombres de SKU

El karpenter.azure.com/sku-name selector permite especificar el tipo exacto de instancia de máquina virtual.

requirements:
- key: karpenter.azure.com/sku-name
  operator: In
  values:
  - Standard_D4s_v3
  - Standard_F8s_v2

Ejemplos de versión de SKU

El karpenter.azure.com/sku-version selector tiene como destino generaciones específicas de SKU de máquina virtual.

requirements:
- key: karpenter.azure.com/sku-version
  operator: In
  values:
  - "3"  # v3 generation
  - "5"  # v5 generation

Ejemplo de zona de disponibilidad

El topology.kubernetes.io/zone selector permite especificar las zonas de disponibilidad para los nodos.

requirements:
- key: topology.kubernetes.io/zone
  operator: In
  values:
  - eastus-1
  - eastus-2

Nota:

Para enumerar los tamaños de máquina virtual que admiten zonas de disponibilidad en una región, use el az vm list-skus comando con los --location <region> --zone --output table parámetros . Confirme que el tamaño de la VM seleccionado admite las zonas indicadas en el requisito NodePool.

Ejemplo de arquitectura

El kubernetes.io/arch selector permite especificar la arquitectura de CPU para los nodos. NAP admite nodos amd64 y arm64 .

requirements:
- key: kubernetes.io/arch
  operator: In
  values:
  - amd64
  - arm64

Ejemplo del sistema operativo

El kubernetes.io/os selector permite especificar el sistema operativo para los nodos.

requirements:
- key: kubernetes.io/os
  operator: In
  values:
  - linux

Ejemplo de tipo de capacidad

El karpenter.sh/capacity-type selector permite especificar si se deben usar instancias de Spot o a petición.

Nota:

NAP da prioridad a las instancias de acceso puntual cuando se especifican las de acceso puntual y bajo demanda.

requirements:
- key: karpenter.sh/capacity-type
  operator: In
  values:
  - spot
  - on-demand

Límites del grupo de nodos

De forma predeterminada, NAP intenta programar las cargas de trabajo dentro de la cuota de Azure que tiene disponible. Para un grupo de nodos dinámicos, puede especificar límites de recursos agregados en todos los nodos aprovisionados por ese grupo. En el ejemplo siguiente, cpu: "1000" limita el grupo a 1000 núcleos de vCPU y memory: 1000Gi lo limita a 1000 gibibytes de memoria:

spec:
  # Resource limits constrain the total size of the node pool.
  # Limits prevent Node Auto Provisioning from creating new instances once the limit is exceeded.
  limits:
    cpu: "1000"
    memory: 1000Gi

Pesos del grupo de nodos

Cuando haya definido varios grupos de nodos, puede establecer una preferencia para dónde se debe programar una carga de trabajo definiendo el peso relativo en las definiciones del grupo de nodos. El weight campo acepta un entero comprendido entre 1 y 100 y los valores superiores proporcionan una prioridad más alta a un grupo de nodos. Si omite weight, su valor es efectivamente 0. Por ejemplo:

spec:
  # Priority given to the node pool when the scheduler considers which to select. 
  # Higher weights indicate higher priority when comparing node pools.
  # Specifying no weight is equivalent to specifying a weight of 0.
  weight: 10

Grupos de nodos estáticos

Los grupos de nodos estáticos mantienen el número fijo de nodos aprovisionados por NAP especificados en el replicas campo, independientemente de la demanda del pod. Para cambiar el número de nodos, escale explícitamente NodePool, por ejemplo, usando kubectl scale con nodepool static-node-pool --replicas=7. El valor opcional limits.nodes restringe el escalado explícito y la capacidad temporal creada durante el reemplazo del nodo. En el caso de los grupos de nodos estáticos, nodes es el único campo admitido en limits; no se pueden establecer límites de CPU o memoria.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: static-node-pool
spec:
  replicas: 5
  template:
    spec:
      requirements:
      - key: karpenter.azure.com/sku-name
        operator: In
        values:
          - Standard_D4s_v3
          - Standard_F8s_v2
      - key: topology.kubernetes.io/zone
        operator: In
        values:
          - eastus-1
          - eastus-2
          - eastus-3
  limits:
    nodes: 10

Nota:

Para los grupos de nodos estáticos, solo se puede establecer nodes en el campo limits. No se pueden establecer límites de recursos ni weight, y no se aplica la consolidación de perturbaciones. Después de crear un NodePool, no se puede cambiar entre modos estáticos y dinámicos agregando o quitando el replicas campo.

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