Ativar ou desativar o autoaprovisionamento de nós (NAP) no serviço Azure Kubernetes (AKS)

Este artigo explica como ativar ou desativar o auto-provisionamento de nós (NAP) no Azure Kubernetes Service (AKS) usando os modelos CLI do Azure ou Azure Resource Manager (ARM).

Se quiser criar um cluster AKS habilitado para NAP com uma rede virtual personalizada (VNet) e subredes, consulte Criar um cluster NAP (provisionamento automático) de nó em uma rede virtual personalizada.

Antes de começar

Antes de começar, revise o artigo Visão geral do provisionamento automático de nó (NAP) no AKS , que detalha como a NAP funciona, pré-requisitos e limitações.

Habilitar o provisionamento automático de nós (NAP) num cluster AKS

As seções a seguir explicam como habilitar a NAP em um cluster AKS novo ou existente:

Observação

Pode ativar as métricas do control plane para ver os registos e operações do auto-provisionamento de nós com o serviço gerido Azure Monitor com o add-on para Prometheus.

Habilitar NAP em um novo cluster

  • Ative o provisionamento automático de nó num novo cluster usando o az aks create comando, com o --node-provisioning-mode flag definido como Auto. O comando a seguir também define --network-plugin como azure, --network-plugin-mode como overlay, e --network-dataplane como cilium.

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

  1. Crie um arquivo chamado nap.json e adicione a seguinte configuração de modelo ARM com o campo properties.nodeProvisioningProfile.mode definido como Auto, que habilita o NAP. (A configuração padrão é Manual.)

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {},
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2025-05-01",
      "sku": {
        "name": "Base",
        "tier": "Standard"
      },
      "name": "napcluster",
      "location": "uksouth",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "networkProfile": {
            "networkPlugin": "azure",
            "networkPluginMode": "overlay",
            "networkPolicy": "cilium",
            "networkDataplane":"cilium",
            "loadBalancerSku": "Standard"
        },
        "dnsPrefix": "napcluster",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "count": 3,
            "vmSize": "standard_d2s_v3",
            "osType": "Linux",
            "mode": "System"
          }
        ],
        "nodeProvisioningProfile": {
          "mode": "Auto"
        }
      }
    }
  ]
}

  2. Habilite o provisionamento automático de nós em um cluster novo usando o az deployment group create comando com o --template-file flag definido para o caminho do ficheiro do modelo ARM.

    az deployment group create --resource-group $RESOURCE_GROUP --template-file ./nap.json

Habilitar NAP em um cluster existente

  • Ativa o provisionamento automático de nó num cluster existente, utilizando o az aks update comando com o indicador --node-provisioning-mode definido como Auto.

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --node-provisioning-mode Auto

Desativar o aprovisionamento automático de nós (NAP) num cluster AKS

Importante

Você só pode desabilitar a NAP em um cluster se as seguintes condições forem atendidas:

  • Não existem nós NAP existentes. Você pode usar o kubectl get nodes -l karpenter.sh/nodepool comando para verificar se há nós gerenciados por NAP existentes.
  • Todos os Karpenter NodePools existentes têm seu spec.limits.cpu campo definido como 0. Essa ação impede que novos nós sejam criados, mas não interrompe os nós em execução no momento.

  1. Defina o campo spec.limits.cpu para 0 para cada Karpenter existente NodePool. Por exemplo:

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  limits:
    cpu: 0

    Importante

    Se você não quiser garantir que todos os pods executados anteriormente em um nó NAP sejam migrados com segurança para um nó não-NAP antes de desabilitar o NAP, você pode ignorar as etapas 2 e 3 e, em vez disso, usar o kubectl delete node comando para cada nó gerenciado por NAP. No entanto, não recomendamos pular essas etapas, pois isso pode deixar alguns pods pendentes e não respeita os Orçamentos de Interrupção de Pods (PDBs).

    Ao usar o kubectl delete node comando, tenha cuidado para excluir apenas nós gerenciados por NAP. Você pode identificar nós gerenciados por NAP usando o kubectl get nodes -l karpenter.sh/nodepool comando.

  2. Adicione a karpenter.azure.com/disable:NoSchedule mancha a cada Karpenter NodePool. Por exemplo:

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

    Esta ação inicia o processo de migração das cargas de trabalho nos nós gerenciados pelo NAP para nós não-NAP, respeitando PDBs e limites de interrupção. Os pods migram para nós não-NAP, se puderem se encaixar. Se não houver capacidade de tamanho fixo suficiente, alguns nós geridos por NAP permanecerão.

  3. Ampliar o tamanho fixo existente ManagedClusterAgentPools ou criar um novo tamanho fixo AgentPools para absorver a carga dos nós geridos pela NAP. À medida que esses nós são adicionados ao cluster, os nós geridos pela NAP são liberados, e o trabalho é transferido para os nós de tamanho fixo.

  4. Exclua todos os nós gerenciados pela NAP usando o kubectl get nodes -l karpenter.sh/nodepool comando. Se os nós gerenciados pela NAP ainda existirem, o cluster provavelmente não terá capacidade de tamanho fixo. Nesse caso, você deve adicionar mais nós para que as cargas de trabalho restantes possam ser migradas.

  1. Atualize o modo NAP para Manual usando o comando az aks update CLI do Azure com a flag --node-provisioning-mode definida para Manual.

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

  1. Atualize o campo properties.nodeProvisioningProfile.mode para Manual no seu modelo ARM e volte a implementá-lo.

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {},
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2025-05-01",
      "sku": {
        "name": "Base",
        "tier": "Standard"
      },
      "name": "napcluster",
      "location": "uksouth",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "networkProfile": {
            "networkPlugin": "azure",
            "networkPluginMode": "overlay",
            "networkPolicy": "cilium",
            "networkDataplane":"cilium",
            "loadBalancerSku": "Standard"
        },
        "dnsPrefix": "napcluster",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "count": 3,
            "vmSize": "standard_d2s_v3",
            "osType": "Linux",
            "mode": "System"
          }
        ],
        "nodeProvisioningProfile": {
          "mode": "Manual"
        }
      }
    }
  ]
}

Migrar do Karpenter open-source auto-hospedado para o auto-provisionamento de nós geridos (NAP)

Se o Karpenter foi instalado a partir do gráfico de Helm open source, ainda podes ativar o NAP no teu cluster. Estes passos assumem que o gráfico de Helm de Karpenter está instalado.

Importante

Certifica-te de que estás a usar a versão mais recente do Karpenter antes de iniciares a migração. O NAP está sempre a correr a versão mais recente.

Importante

Tenha cuidado para não remover os CRDs de Karpenter ao realizar este processo de migração. Se os CRDs forem apagados, apagam as NodeClaims subjacentes, o que pode perturbar as suas cargas de trabalho.

  1. Para garantir que as CRDs do Karpenter não sejam desinstaladas no passo 2, remova os managed-by=Helm rótulos e anotações.

    kubectl get crds -l app.kubernetes.io/managed-by=Helm -o name | grep karpenter.azure.com | xargs -I{} kubectl patch {} --type=json -p '
[
  {"op":"remove","path":"/metadata/annotations/meta.helm.sh~1release-name"},
  {"op":"remove","path":"/metadata/annotations/meta.helm.sh~1release-namespace"},
  {"op":"remove","path":"/metadata/labels/app.kubernetes.io~1managed-by"}
]'

  2. Desinstale o chart do Helm para remover o Deployment, Service, Roles e outros recursos utilizados pelo Karpenter de código aberto. Neste ponto, Karpenter já não reage a eventos de escalabilidade, mas os nós existentes continuam a funcionar.

    helm uninstall karpenter -n kube-system  # If you installed Karpenter into a different namespace than kube-system, specify that here instead of kube-system

  3. Ative o NAP no seu cluster:

    az aks update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --node-provisioning-mode Auto --node-provisioning-default-pools None

    Este comando desativa os NodePools predefinidos porque já tem NodePools existentes e gostaria de continuar a usá-los. Se quiseres ativar os pools predefinidos de aprovisionamento automático de nós, podes omitir o --node-provisioning-default-pools None do comando az aks update.

  4. Verificar a migração concluída: Quando o az aks update passo 3 for concluído com sucesso, a migração está feita. Também pode confirmar que a migração é feita verificando as anotações nos CRDs de Karpenter. Você deve ver:

        meta.helm.sh/release-name: aks-managed-karpenter-overlay-base
    meta.helm.sh/release-namespace: kube-system

    Nesta fase, o NAP está ativado e o autoescalonamento deverá ser retomado.

Monitorização do auto-provisionamento de nós

Recuperar registos e estado de Karpenter

Pode recuperar registos e atualizações de estado do Karpenter para ajudar a diagnosticar e depurar eventos relacionados com NAP. AKS gere o aprovisionamento automático de nós por si e executa-o no plano de controlo gerido. Pode ativar os registos do plano de controlo para ver os registos de Karpenter e as operações através do aprovisionamento automático de nós. Para mais informações sobre registos do plano de controlo, consulte a documentação dos registos do plano de controlo do AKS

  1. Configure uma regra para que os registos de recursos empurrem os registos de auto-provisionamento dos nós para Log Analytics usando as instruções aqui. Certifique-se de marcar a caixa correspondente a node-auto-provisioning ao selecionar opções de Logs.

  2. Selecione a seção Log no cluster.

  3. Insira a seguinte consulta de exemplo no Log Analytics:

    AKSControlPlane
| where Category == "karpenter-events"

  4. Visualizar eventos de auto-provisionamento de nós na CLI:

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

Métricas de auto-provisionamento de nós

Pode ativar métricas plano de controlo (Preview) para ver métricas e operações específicas de Karpenter do auto-provisionamento node com o serviço gerido Azure Monitor para o complemento Prometheus.

Próximos passos

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

  • Last updated on