Compartir a través de

Aprovisionamiento automático de nodos (versión preliminar)

Al implementar cargas de trabajo en AKS, debe tomar una decisión sobre la configuración del grupo de nodos con respecto al tamaño de máquina virtual necesario. A medida que sus cargas de trabajo se vuelven más complejas y requieren diferentes CPU, memoria y capacidades para ejecutarse, la sobrecarga de tener que diseñar la configuración de su VM para numerosas solicitudes de recursos se vuelve difícil.

El aprovisionamiento automático de nodos (NAP) (versión preliminar) usa los requisitos de recursos de pod pendientes para decidir la configuración óptima de la máquina virtual para ejecutar esas cargas de trabajo de la manera más eficaz y rentable.

NAP se basa en el proyecto karpenter de código abierto y el proveedor de AKS también es de código abierto. NAP implementa, configura y administra automáticamente Karpenter en sus clústeres AKS.

Importante

El aprovisionamiento automático de nodos (NAP) para AKS está actualmente en versión preliminar. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Antes de empezar

Instalación de la extensión aks-preview de la CLI

  1. Instale la extensión aks-preview de la CLI mediante el comando az extension add.

    az extension add --name aks-preview

  2. Actualice la extensión para asegurarse de que tiene instalada la última versión mediante el comando az extension update.

    az extension update --name aks-preview

Registro de la marca de característica NodeAutoProvisioningPreview

  1. Registre la marca de características de NodeAutoProvisioningPreview mediante el comando az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "NodeAutoProvisioningPreview"

    Tarda unos minutos en que el estado muestre Registrado.

  2. Comprobar el estado del registro mediante el comando az feature show.

    az feature show --namespace "Microsoft.ContainerService" --name "NodeAutoProvisioningPreview"

  3. Cuando aparezca el estado Registrado, actualice el registro del proveedor de recursos Microsoft.ContainerService mediante el comando az provider register.

    az provider register --namespace Microsoft.ContainerService

Limitaciones

  • No se puede habilitar en un clúster en el que los grupos de nodos tengan habilitado el escalador automático de clústeres

Características no admitidas

  • Grupos de nodos de Windows
  • Aplicación de la configuración personalizada al nodo kubelet
  • Clústeres IPv6
  • Entidad de servicio

    Nota:

    Puede usar una identidad administrada asignada por el sistema o por el usuario.

  • Conjuntos de cifrado de disco
  • CustomCATrustCertificates
  • Modo de arranque o parada
  • Proxy HTTP
  • Mutación OutboundType. Se admiten todos los OutboundTypes, pero no se pueden cambiar después de la creación.
  • Clúster privado (y traiga su propio DNS privado)

Configuración de red

Las configuraciones de red recomendadas para clústeres habilitados con el aprovisionamiento automático de nodos son los siguientes:

Nuestro motor de directivas de red recomendado es Cilium.

Actualmente no se admiten las siguientes configuraciones de red:

  • Directiva de red de Calico
  • Asignación dinámica de IP
  • Asignación estática de bloques CIDR

Habilitar el aprovisionamiento automático de nodos

Habilitación del aprovisionamiento automático de nodos en un nuevo clúster

  • Habilite el aprovisionamiento automático de nodos en un nuevo clúster mediante el az aks create comando y establezca --node-provisioning-mode en Auto. También debe establecer --network-plugin en azure, --network-plugin-mode en overlay y --network-dataplane en cilium.

    az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --node-provisioning-mode Auto \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --generate-ssh-keys

Habilitación del aprovisionamiento automático de nodos en un clúster existente

  • Habilitación del aprovisionamiento automático de nodos en un clúster existente mediante el az aks update comando y establezca --node-provisioning-mode en Auto. También debe establecer --network-plugin en azure, --network-plugin-mode en overlay y --network-dataplane en cilium.

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP_NAME --node-provisioning-mode Auto --network-plugin azure --network-plugin-mode overlay --network-dataplane cilium

Grupos de nodos

El aprovisionamiento automático de nodos usa una lista de SKU de máquina virtual como punto de partida para decidir qué SKU es más adecuada para las cargas de trabajo que están en estado pendiente. Tener control sobre qué SKU desea incluir en el grupo inicial le permite especificar familias de SKU específicas o tipos de máquinas virtuales, así como el número máximo de recursos que un proveedor usa. También puede referenciar diferentes especificaciones en el archivo de grupo de nodos, como especificar instancias spot o a petición, varias arquitecturas, y más.

Si tiene tamaños de máquina virtual específicos que son instancias reservadas, por ejemplo, puede que solo desee usar esas máquinas virtuales como grupo de inicio.

Puede tener varias definiciones de grupo de nodos en un clúster, pero AKS implementa una definición de grupo de nodos predeterminada que puede modificar:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenUnderutilized
    expireAfter: Never
  template:
    spec:
      nodeClassRef:
        name: default

      # 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

Requisitos de los proveedores de nodos compatibles

Selectores de SKU con etiquetas conocidas

Seleccionador Descripción Ejemplo
karpenter.azure.com/sku-family Familia de SKU de máquina virtual D, F, L, etc.
karpenter.azure.com/sku-name Nombre de SKU explícito Standard_A1_v2
karpenter.azure.com/sku-version Versión SKU (sin "v", puede utilizar 1) 1 , 2
karpenter.sh/capacity-type Tipo de asignación de máquina virtual (de acceso puntual o a petición) de acceso puntual o a petición
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 la GPU A100
karpenter.azure.com/sku-gpu-manufacturer Fabricante de la 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 efímero del SO en Gb 92
topology.kubernetes.io/zone Las zonas de disponibilidad [uksouth-1,uksouth-2,uksouth-3]
kubernetes.io/os Sistema operativo (solo Linux durante la versión preliminar) Linux
kubernetes.io/arch Arquitectura de CPU (AMD64 o ARM64) [amd64, arm64]

Para enumerar las funcionalidades de SKU de máquina virtual y los valores permitidos, use el comando de la vm list-skus CLI de Azure.

az vm list-skus --resource-type virtualMachines --location <location> --query '[].name' --output table

Límites del grupo de nodos

De forma predeterminada, el aprovisionamiento automático de nodos intenta programar las cargas de trabajo dentro de la cuota de Azure que tiene disponible. También puede especificar el límite superior de recursos que usa un grupo de nodos, especificando límites dentro de la especificación del grupo de nodos.

  # Resource limits constrain the total size of the cluster.
  # Limits prevent Karpenter 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, es posible establecer una preferencia de dónde se debe programar una carga de trabajo. Defina el peso relativo en las definiciones del grupo de nodos.

  # 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

Kubernetes y actualizaciones de imágenes de nodos

AKS con aprovisionamiento automático de nodos administra las actualizaciones de la versión de Kubernetes y las actualizaciones de disco del sistema operativo de máquina virtual de forma predeterminada.

Actualizaciones de Kubernetes

Las actualizaciones de Kubernetes para los nodos de aprovisionamiento automático de nodos siguen la versión de Kubernetes del plano de control. Si realiza una actualización del clúster, los nodos de aprovisionamiento automático se actualizan automáticamente para seguir la misma versión.

Actualizaciones de imágenes de nodo

De forma predeterminada, las máquinas virtuales del grupo de nodos NAP se actualizan automáticamente cuando hay una nueva imagen disponible. Si desea fijar un grupo de nodos a una determinada versión de imagen de nodo, puede establecer la imageVersion en la clase de nodo:

kubectl edit aksnodeclass default

En la definición de la clase de nodo, establezca imageVersion en una de las versiones publicadas que figuran en las notas de la versión de AKS. También puede ver la disponibilidad de las imágenes en las regiones consultando el rastreador de versiones de AKS

El imageVersion es la parte de la fecha en la imagen del nodo como sólo Ubuntu 22.04 es compatible, por ejemplo, "AKSUbuntu-2204-202311.07.0" sería "202311.07.0"

apiVersion: karpenter.azure.com/v1alpha2
kind: AKSNodeClass
metadata:
  annotations:
    kubernetes.io/description: General purpose AKSNodeClass for running Ubuntu2204
      nodes
    meta.helm.sh/release-name: aks-managed-karpenter-overlay
    meta.helm.sh/release-namespace: kube-system
  creationTimestamp: "2023-11-16T23:59:06Z"
  generation: 1
  labels:
    app.kubernetes.io/managed-by: Helm
    helm.toolkit.fluxcd.io/name: karpenter-overlay-main-adapter-helmrelease
    helm.toolkit.fluxcd.io/namespace: 6556abcb92c4ce0001202e78
  name: default
  resourceVersion: "1792"
  uid: 929a5b07-558f-4649-b78b-eb25e9b97076
spec:
  imageFamily: Ubuntu2204
  imageVersion: 202311.07.0
  osDiskSizeGB: 128

Si se elimina la especificación imageVersion, el conjunto de nodos se actualizará con la última versión de imagen de nodo.

Importante

Después de actualizar la clave SSH, AKS no actualiza automáticamente los nodos. En cualquier momento, puede optar por realizar una [operación de actualización del grupo de nodos][node-image-upgrade]. La operación de actualización de claves SSH surte efecto después de que se complete una actualización de la imagen del nodo. Para los clústeres con el aprovisionamiento automático de nodos habilitado, se puede realizar una actualización de imagen de nodo aplicando una nueva etiqueta al recurso personalizado NodePool de Kubernetes.

Interrupción del nodo

Cuando las cargas de trabajo en tus nodos disminuyen, el aprovisionamiento automático de nodos utiliza reglas de disrupción en la especificación del grupo de recursos de nodos para decidir cuándo y cómo eliminar esos nodos y potencialmente reprogramar tus cargas de trabajo para ser más eficientes. Esto se realiza principalmente a través de consolidación, que elimina o reemplaza nodos para empaquetar los pods en una configuración óptima. La consideración basada en estado usa ConsolidationPolicy como WhenUnderUtilized, WhenEmpty, o WhenEmptyOrUnderUtilized para desencadenar la consolidación. consolidateAfter es una condición basada en el tiempo que se puede establecer para permitir tiempo de espera para las acciones.

Puede quitar un nodo manualmente mediante kubectl delete node, pero el aprovisionamiento automático del nodo también puede controlar cuándo debe optimizar los nodos en función de las especificaciones.

  disruption:
    # Describes which types of Nodes NAP should consider for consolidation
    consolidationPolicy: WhenUnderutilized | WhenEmpty
    # 'WhenUnderutilized', NAP will consider all nodes for consolidation and attempt to remove or replace Nodes when it discovers that the Node is underutilized and could be changed to reduce cost

    #  `WhenEmpty`, NAP will only consider nodes for consolidation that contain no workload pods
    
    # The amount of time NAP should wait after discovering a consolidation decision
    # This value can currently only be set when the consolidationPolicy is 'WhenEmpty'
    # You can choose to disable consolidation entirely by setting the string value 'Never'
    consolidateAfter: 30s

Supervisión de eventos de selección

El aprovisionamiento automático de nodos produce eventos de clúster que pueden utilizarse para supervisar las decisiones de implementación y programación que se están tomando. Puede ver los eventos a través del flujo de eventos de Kubernetes.

kubectl get events -A --field-selector source=karpenter -w

Deshabilitación del aprovisionamiento automático de nodos

El aprovisionamiento automático de nodos solo se puede deshabilitar cuando:

  • No hay nodos administrados por NAP existentes. Use kubectl get nodes -l karpenter.sh/nodepool para ver los nodos administrados por NAP.
  • Todos los karpenter.sh/NodePools existentes tienen su valor establecido a 0 en spec.limits.cpu.

Pasos para deshabilitar el aprovisionamiento automático de nodos

  1. Establezca todos los campos spec.limits.cpu de karpenter.sh/NodePools en 0. Esto evita que se creen nuevos nodos, pero no interrumpe los nodos que se están ejecutando actualmente.

Nota:

Si no le interesa asegurarse de que todos los pods que se ejecutaban en un nodo NAP se migran de forma segura a un nodo que no sea NAP, puede omitir los pasos 2 y 3 y, en su lugar, usar el kubectl delete node comando para cada nodo administrado por NAP.

No se recomienda omitir los pasos 2 y 3, ya que se podrían quedar algunos pods pendientes y sin respetar los PDB.

No se ejecute kubectl delete node en ningún nodo que no esté administrado por NAP.

  1. Agregue la intolerancia karpenter.azure.com/disable:NoSchedule a cada karpenter.sh/NodePool.

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      ...
      taints:
        - key: karpenter.azure.com/disable,
          effect: NoSchedule

    Esto iniciará el proceso de migración de las cargas de trabajo en los nodos administrados por NAP a nodos no gestionados por NAP, respetando los límites de PDB y de interrupciones. Los pods se migrarán a nodos que no sean NAP en caso de ajustarse. Si no hay suficiente capacidad de tamaño fijo, algunos nodos administrados por NAP permanecerán.

  2. Amplíe los AgentPools de tamaño fijo existentes en el ManagedCluster o cree nuevos AgentPools de tamaño fijo para asumir la carga de los nodos gestionados por NAP. A medida que estos nodos se agregan al clúster, los nodos administrados por NAP se vacían y el trabajo se migra a los nodos de escala fija.

  3. Confirme que se eliminan todos los nodos administrados por NAP mediante kubectl get nodes -l karpenter.sh/nodepool. Si todavía hay nodos administrados por NAP, es probable que el clúster esté fuera de la capacidad de escala fija y necesite más nodos para que se puedan migrar las cargas de trabajo restantes.

  4. Actualice el parámetro del modo de aprovisionamiento de nodos de ManagedCluster a Manual.

    az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP_NAME \
    --node-provisioning-mode Manual