Partilhar via

Autoprovisionamento de nó (visualização)

  • Artigo

Ao implantar cargas de trabalho no AKS, você precisa tomar uma decisão sobre a configuração do pool de nós em relação ao tamanho da VM necessário. À medida que suas cargas de trabalho se tornam mais complexas e exigem CPU, memória e recursos diferentes para serem executadas, a sobrecarga de ter que projetar sua configuração de VM para várias solicitações de recursos torna-se difícil.

O provisionamento automático de nós (NAP) (visualização) decide, com base nos requisitos de recursos de pod pendentes, a configuração ideal da VM para executar essas cargas de trabalho da maneira mais eficiente e econômica.

O NAP é baseado no projeto Open Source Karpenter , e o provedor AKS também é Open Source. A NAP implanta, configura e gerencia automaticamente o Karpenter em seus clusters AKS.

Importante

O provisionamento automático de nós (NAP) para AKS está atualmente em visualização. Veja Termos de Utilização Complementares da Pré-visualizações do Microsoft Azure para obter os termos legais que se aplicam às funcionalidades do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançadas para disponibilidade geral.

Antes de começar

Instalar a aks-preview extensão CLI

  1. Instale a aks-preview extensão CLI usando o az extension add comando.

    az extension add --name aks-preview

  2. Atualize a extensão para garantir que você tenha a versão mais recente instalada usando o az extension update comando.

    az extension update --name aks-preview

Registrar o sinalizador de NodeAutoProvisioningPreview recurso

  1. Registre o NodeAutoProvisioningPreview sinalizador de recurso usando o az feature register comando.

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

    Leva alguns minutos para que o status mostre Registrado.

  2. Verifique o status do registro usando o az feature show comando.

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

  3. Quando o status refletir Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o az provider register comando.

    az provider register --namespace Microsoft.ContainerService

Limitações

  • A única configuração de rede permitida é o Azure CNI Overlay with Powered by Cilium.
  • Não é possível habilitar em um cluster em que os pools de nós tenham o autoscaler de cluster habilitado

Funcionalidades não suportadas

  • Pools de nós do Windows
  • Aplicando configuração personalizada ao kubelet do nó
  • Clusters IPv6
  • Entidades de serviço

    Nota

    Você pode usar uma identidade gerenciada atribuída pelo sistema ou pelo usuário.

  • Conjuntos de criptografia de disco
  • CustomCATrustCertificates
  • Iniciar o modo Stop
  • Proxy HTTP
  • Mutação OutboundType . Todos os OutboundTypes são suportados, no entanto, você não pode alterá-los após a criação.
  • Cluster privado (e DNS privado BYO)

Habilitar o provisionamento automático de nó

Habilitar o provisionamento automático de nó em um novo cluster

  • Habilite o provisionamento automático de nó em um novo cluster usando o az aks create comando e defina --node-provisioning-mode como Auto. Você também precisa definir o --network-plugin para azure, --network-plugin-mode para overlay, e --network-dataplane para 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

Habilitar o provisionamento automático de nó em um cluster existente

  • Habilite o provisionamento automático de nó em um cluster existente usando o az aks update comando e defina --node-provisioning-mode como Auto. Você também precisa definir o --network-plugin para azure, --network-plugin-mode para overlay, e --network-dataplane para 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

Conjuntos de nós

O provisionamento automático de nó usa uma lista de SKUs de VM como ponto de partida para decidir qual é mais adequado para as cargas de trabalho que estão em um estado pendente. Ter controle sobre qual SKU você deseja no pool inicial permite especificar famílias de SKU específicas ou tipos de VM e a quantidade máxima de recursos que um provisionador usa.

Se você tiver SKUs de VM específicas que são instâncias reservadas, por exemplo, talvez queira usar apenas essas VMs como o pool inicial.

Você pode ter várias definições de pool de nós em um cluster, mas o AKS implanta uma definição de pool de nós padrão que pode ser modificada:

apiVersion: karpenter.sh/v1beta1
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 do provisionador de nó suportado

Seletores de SKU com rótulos bem conhecidos

Seletor Description Exemplo
karpenter.azure.com/sku-family Família VM SKU D, F, L etc.
karpenter.azure.com/sku-name Nome SKU explícito Standard_A1_v2
karpenter.azure.com/sku-version Versão SKU (sem "v", pode usar 1) 1 , 2
karpenter.sh/capacity-type Tipo de alocação de VM (Spot / On Demand) spot ou sob demanda
karpenter.azure.com/sku-cpu Número de CPUs na VM 16
karpenter.azure.com/sku-memory Memória em VM em MiB 131072
karpenter.azure.com/sku-gpu-name Nome da GPU A100
karpenter.azure.com/sku-gpu-manufacturer Fabricante de GPU nvidia
karpenter.azure.com/sku-gpu-count Contagem de GPU por VM 2
karpenter.azure.com/sku-networking-accelerated Se a VM acelerou a rede [verdadeiro, falso]
karpenter.azure.com/sku-storage-premium-capable Se a VM suporta armazenamento de E/S Premium [verdadeiro, falso]
karpenter.azure.com/sku-storage-ephemeralos-maxsize Limite de tamanho para o disco do SO efêmero em Gb 92
topology.kubernetes.io/zone A(s) zona(s) de disponibilidade [uksouth-1,uksouth-2,uksouth-3]
kubernetes.io/os Sistema operacional (Linux somente durante a visualização) linux
kubernetes.io/arch Arquitetura de CPU (AMD64 ou ARM64) [AMD64, ARM64]

Para listar os recursos de SKU da VM e os valores permitidos, use o comando da CLI vm list-skus do Azure.

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

Limites do pool de nós

Por padrão, a NAP tenta agendar suas cargas de trabalho dentro da cota do Azure que você tem disponível. Você também pode especificar o limite superior de recursos que é usado por um pool de nós, especificando limites dentro da especificação do pool de nós.

  # 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 da piscina de nós

Quando você tem vários pools de nós definidos, é possível definir uma preferência de onde uma carga de trabalho deve ser agendada. Defina o peso relativo nas definições do pool de nós.

  # 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 e atualizações de imagem de nó

O AKS com NAP gerencia as atualizações de versão do Kubernetes e as atualizações de disco do VM OS para você por padrão.

Atualizações do Kubernetes

As atualizações do Kubernetes para pools de nós NAP seguem a versão do Kubernetes do Plano de Controle. Se você executar uma atualização de cluster, os nós NAP serão atualizados automaticamente para seguir o mesmo controle de versão.

Atualizações de imagem de nó

Por padrão, as máquinas virtuais do pool de nós NAP são atualizadas automaticamente quando uma nova imagem está disponível. Se desejar fixar um pool de nós em uma determinada versão de imagem de nó, você pode definir imageVersion na classe de nó:

kubectl edit aksnodeclass default

Dentro da definição de classe de nó, defina imageVersion como uma das versões publicadas listadas nas notas de versão do AKS. Você também pode ver a disponibilidade de imagens em regiões consultando o rastreador de lançamento do AKS

A imageVersion é a parte de data na imagem do nó, pois apenas o Ubuntu 22.04 é suportado, por exemplo, "AKSUbuntu-2204-202311.07.0" seria "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

Remover a especificação imageVersion reverteria o pool de nós a ser atualizado para a versão mais recente da imagem do nó.

Interrupção do nó

Quando as cargas de trabalho em seus nós diminuem, a NAP usa regras de interrupção na especificação do pool de nós para decidir quando e como remover esses nós e, potencialmente, reagendar suas cargas de trabalho para serem mais eficientes.

Você pode remover um nó manualmente usando kubectl delete nodeo , mas a NAP também pode controlar quando ele deve otimizar seus nós.

  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

Acompanhamento de eventos de seleção

O provisionamento automático de nós produz eventos de cluster que podem ser usados para monitorar a implantação e as decisões de agendamento que estão sendo tomadas. Você pode visualizar eventos através do fluxo de eventos do Kubernetes.

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