Configurar pools de nós para provisionamento automático de nós (NAP) no Azure Kubernetes Service (AKS)

Este artigo explica como configurar pools de nós para NAP (provisionamento automático de nós) no AKS (Serviço de Kubernetes do Azure), incluindo seletores de SKU, limites de recursos e pesos de prioridade. Ele também fornece exemplos para ajudá-lo a começar.

Visão geral dos pools de nós no NAP

O NAP usa os requisitos de SKU da VM (máquina virtual) para decidir as melhores VMs para cargas de trabalho pendentes. Você pode configurar:

• Famílias de SKU e tipos de instância específicos.
• Limites e prioridades de recursos.
• Instâncias spot ou sob demanda.
• Requisitos de arquitetura e funcionalidades.

O recurso NodePool define restrições nos nós que o NAP cria e nos pods que rodam nesses nós. Quando você instala o NAP pela primeira vez, ele cria um padrão NodePool. Você pode modificar esse pool de nós ou criar pools de nós extras para atender aos seus requisitos de carga de trabalho.

Principais comportamentos de NodePools em NAP

Ao configurar NodePools para o NAP, tenha em mente os seguintes comportamentos:

• O NAP requer pelo menos um NodePool para funcionar.
• O NAP avalia cada NodePool configurado.
• O NAP ignora NodePools com taints não tolerados por um pod.
• O NAP aplica os taints de inicialização a nós provisionados, mas não requer tolerância de pod.
• Ele funciona melhor com mutuamente exclusivos NodePools. Quando várias NodePools correspondem, usa-se aquela com o maior peso.

Examinar a configuração do pool de nós padrão

A configuração do Karpenter NodePool padrão denominado default criado pelo NAP é a seguinte:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    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

Ele também cria um system-surge pool de nós, que ajuda a dimensionar automaticamente os nós do pool do sistema.

Controlar a configuração do pool de nós padrão durante a criação do cluster

Ao criar um novo cluster do AKS com NAP habilitado usando a CLI do Azure, você pode incluir a --node-provisioning-default-pools flag para controlar a configuração do NAP NodePool padrão.

O --node-provisioning-default-pools sinalizador controla a configuração de NAP NodePool padrão e aceita os seguintes valores:

• Auto (padrão): cria dois padrões NodePools para uso imediato.
• None: não cria nenhum NodePools. Você deve definir o seu próprio.

Opções de configuração do pool de nós

As seções a seguir descrevem várias opções de configuração no NodePools no NAP, incluindo rótulos conhecidos e seletores de SKU, limites de pool de nós e pesos do pool de nós.

Rótulos conhecidos e seletores de SKU

O Kubernetes define rótulos conhecidos que o Azure implementa. Você pode definir esses rótulos na spec.requirements seção da NodePool API. O NAP também dá suporte a rótulos específicos do Azure para agendamento mais avançado.

karpenter.azure.com Seletores de SKU

A tabela a seguir lista os karpenter.azure.com seletores de SKU que você pode usar na spec.requirements seção da sua NodePool API para definir as características da VM para seus nós.

kubernetes.io rótulos conhecidos

A tabela a seguir lista os kubernetes.io rótulos bem conhecidos que você pode usar na spec.requirements seção da sua NodePool API para definir características dos seus nós:

Exemplos da família de SKUs

O karpenter.azure.com/sku-family seletor permite que você direcione famílias de VM específicas.

Configuração de exemplo usando a família SKU:

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

Exemplos de nome de SKU

O karpenter.azure.com/sku-name seletor permite que você especifique o tipo exato de instância de VM.

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

Exemplos de versão do SKU

O karpenter.azure.com/sku-version seletor tem como destino gerações específicas de SKUs de VM.

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

Exemplo de zona de disponibilidade

O topology.kubernetes.io/zone seletor permite que você especifique as zonas de disponibilidade para seus nós.

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

Exemplo de arquitetura

O kubernetes.io/arch seletor permite que você especifique a arquitetura da CPU para seus nós. O NAP suporta tanto os nós amd64 quanto os nós arm64.

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

Exemplo do sistema operacional

O kubernetes.io/os seletor permite que você especifique o sistema operacional para seus nós.

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

Exemplo de tipo de capacidade

O karpenter.sh/capacity-type seletor permite especificar se as instâncias spot ou sob demanda devem ser usadas.

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

Limites do pool de nós

Por padrão, o NAP tenta agendar suas cargas de trabalho dentro da cota do Azure que você tem disponível. Você também pode especificar o limite máximo de recursos que um conjunto de nós usa ao definir limites dentro da especificação do conjunto de nós. Por exemplo:

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

Pesos do pool de nós

Quando você tiver vários pools de nós definidos, poderá definir uma preferência de onde uma carga de trabalho deve ser agendada definindo o peso relativo nas definições do pool de nós. Por exemplo:

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

Próximas etapas

Para obter mais informações sobre o provisionamento automático de nós no AKS, consulte os seguintes artigos:

• Configurar o sistema de rede para o provisionamento automático de nós no AKS
• Configurar políticas de interrupção para provisionamento automático de nós no AKS
• Criar um cluster de autoaprovisionamento de nós em uma rede virtual personalizada no AKS