Configurar pools de nós para provisionamento automático de nós (NAP) no Serviço Kubernetes do Azure (AKS)

Este artigo explica como configurar pools de nós para o provisionamento automático de nós (NAP) no Serviço Kubernetes do Azure (AKS), 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 conjuntos de nós na NAP

A NAP usa requisitos de SKU de máquina virtual (VM) 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 de recursos e prioridades.
• Instâncias spot ou sob demanda.
• Requisitos de arquitetura e capacidades.

O NodePool recurso define restrições nos nós que a NAP cria e nos pods que são executados nesses nós. Quando instala o NAP pela primeira vez, ele cria uma configuração predefinida 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 no 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.
• NAP ignora NodePools com taints não tolerados por um pod.
• A NAP aplica manchas de inicialização a nós provisionados, mas não requer tolerância de pod.
• NAP funciona melhor com elementos mutuamente exclusivos.NodePools Quando várias NodePools correspondem, usa-se aquele com maior peso.

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

A configuração do Karpenter NodePool padrão nomeado default criado pela 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 AKS habilitado com NAP usando a CLI do Azure, pode incluir o --node-provisioning-default-pools sinalizador para controlar a configuração padrão da NAP NodePool.

O --node-provisioning-default-pools sinalizador controla a configuração 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.

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

As seções a seguir descrevem várias opções de configuração para o NAP, incluindo rótulos conhecidos e selecionadores de SKU, limites dos pools de nós e pesos dos pools de nós.

Etiquetas e seletores de SKU bem conhecidos

O Kubernetes define rótulos conhecidos que o Azure implementa. Você pode definir esses rótulos na spec.requirements seção da NodePool API. A 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 API NodePool para definir as características da VM para seus nós:

kubernetes.io rótulos bem conhecidos

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

Exemplos da família SKU

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

Exemplo de configuração usando a família SKU:

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

Exemplos de nomes de SKU

O karpenter.azure.com/sku-name seletor permite especificar o tipo exato de instância da VM.

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

Exemplos de versões de SKU

O karpenter.azure.com/sku-version seletor tem como alvo 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 especificar 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. NAP suporta ambos os amd64 e arm64 nós.

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

Exemplo de SO

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 seletor karpenter.sh/capacity-type permite especificar se deseja usar instâncias Spot ou On-demand.

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

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 máximo de recursos que um pool de nós pode usar especificando limites na especificação do pool 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 da piscina de nós

Quando tiver vários grupos de nós definidos, pode definir uma preferência para onde uma carga de trabalho deve ser agendada, definindo o peso relativo nas definições do grupo 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óximos passos

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

• Configurar rede 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 auto-provisionamento de nós numa rede virtual customizada no AKS