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

Este artigo explica como configurar recursos AKSNodeClass para definir as configurações específicas do Azure para o NAP (provisionamento automático de nó) no AKS (Serviço de Kubernetes do Azure) usando o Karpenter. AKSNodeClass permite personalizar vários aspectos dos nós que o Karpenter provisiona, como a imagem de máquina virtual (VM), o tamanho do disco do sistema operacional (OS), o número máximo de pods por nó e as configurações de kubelet.

Importante

A partir de 30 de novembro de 2025, AKS (Serviço de Kubernetes do Azure) não dá mais suporte ou fornece atualizações de segurança para Azure Linux 2.0. A imagem do nó Azure Linux 2.0 está congelada na 202512.06.0 versão. A partir de 31 de outubro de 2026, as imagens do nó serão removidas e você não poderá dimensionar os pools de nós. Migre para uma versão do Linux Azure com suporte atualizando seus pools de nós para uma versão do Kubernetes com suporte ou migrando para osSku AzureLinux3. Para obter mais informações, consulte Problema de desativação do GitHub e o comunicado de desativação das Atualizações do Azure. Para se manter informado sobre anúncios e atualizações, acompanhe as notas de versão do AKS.

Visão geral dos recursos do AKSNodeClass

AKSNodeClass recursos permitem que você defina configurações específicas de Azure para NAP. Cada NodePool recurso deve fazer referência a um AKSNodeClass usando spec.template.spec.nodeClassRef. Você pode ter vários NodePools que apontam para o mesmo AKSNodeClass, permitindo que você compartilhe configurações comuns de Azure em pools de nós diferentes.

Importante

Alterar uma configuração em um AKSNodeClass existente não reconfigura os nós em execução no local. O NAP marca os nós provisionados da configuração anterior como descompassados e os substitui, sujeito aos controles de interrupção nos recursos NodePool que fazem referência a eles. O campo tags é a única exceção, pois as alterações de tag se aplicam aos recursos existentes do Azure sem substituir o nó. Para saber mais, consulte Descompasso e Orçamentos de interrupção. Antes de modificar um(a) AKSNodeClass usado(a) por cargas de trabalho de produção, examine estas diretrizes.

Configuração da família de imagens

O imageFamily campo define a imagem de VM padrão e a lógica de inicialização para nós provisionados por meio da AKSNodeClass. Se você não especificar uma família de imagens, a versão padrão do sistema operacional de acordo com sua versão do Kubernetes será usada. Há suporte para GPUs com ambas as famílias de imagens em tamanhos de VM compatíveis. Para obter mais informações sobre a versão padrão do sistema operacional por versão do Kubernetes, consulte a documentação da versão do sistema operacional AKS.

Famílias de imagens com suporte

Ubuntu: Ubuntu é a distribuição Linux padrão para nós do AKS.
- Os padrões de versão do sistema operacional são alterados com base na versão do Kubernetes. O Ubuntu 22.04 é o padrão para as versões do Kubernetes 1.25 a 1.33. O Ubuntu 24.04 é o padrão para as versões do Kubernetes 1.34 e posteriores.
AzureLinux: Azure Linux é a distribuição alternativa do Linux da Microsoft para cargas de trabalho no AKS. Para obter mais informações, consulte a documentação do Azure Linux.

Configuração da família de imagens de exemplo

O exemplo a seguir configura o AKSNodeClass para usar a família de imagens AzureLinux.

spec:
  imageFamily: AzureLinux

Configuração de imagem de nó compatível com FIPS

Você também pode habilitar imagens de nó compatíveis com os Padrões Federais de Processamento de Informações (FIPS). Para obter mais informações sobre FIPS no AKS, consulte a documentação do FIPS.

O fipsMode campo é definido por padrão como Desabilitado e pode ser definido como as seguintes opções:

FIPS – selecionar imagens de nó compatíveis com o FIPS
Desativado – não use imagens de node em conformidade com FIPS

O exemplo seguinte configura o "AKSNodeClass" para selecionar imagens de nó que cumprem o FIPS ao definir fipsMode para FIPS:

spec:
  fipsMode: FIPS

Streaming de artefatos

Artifact Streaming permite transmitir imagens de contêiner do Registro de Contêiner do Azure (ACR) para o Serviço de Kubernetes do Azure (AKS). O AKS extrai apenas as camadas necessárias para a inicialização inicial do pod, reduzindo o tempo necessário para implantar suas cargas de trabalho.

Pré-requisitos

O Streaming de Artefatos requer que você tenha um ACR de camada Premium integrado ao cluster do AKS.
A transmissão de artefatos deve ser habilitada no ACR.

Consulte a documentação do Artifact Streaming para obter instruções sobre como habilitar o Streaming de Artefatos no ACR.

Habilitar o streaming de artefatos em clusters NAP

Clusters com Node Auto Provisioning (NAP) habilitado podem ativar o streaming de artefatos usando o campo spec.artifactStreaming.enabled do CRD AKSNodeClass. Defina este campo como true para habilitar o streaming de artefatos para quaisquer nós novos ou existentes gerenciados pelo NAP associados a esta CRD AKSNodeClass.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: my-node-class
spec:
  # Enables artifact streaming; To use this feature container images must also enable artifact streaming on ACR
  # Valid values: true, false; defaults to false if not specified
  artifactStreaming:
    enabled: 
      true

Observação

Para usar o streaming de artefatos em nós gerenciados de NAP do AKS, você também deve habilitar o streaming de artefatos no ACR (Registro de Contêiner do Azure). Se você não definir essa opção no ACR, o campo será padrão como false.

Configuração de sub-rede de rede virtual (VNet)

O campo vnetSubnetID especifica qual sub-rede VNet do Azure deve ser usada para provisionar interfaces de rede dos nós. Esse campo é opcional. Se você não especificar uma sub-rede, o NAP usará a sub-rede padrão configurada durante a instalação do Karpenter. Para obter mais informações, consulte as configurações de sub-rede para NAP.

Configuração de sub-rede de exemplo

O ID da sub-rede deve estar no formato completo do Azure Resource Manager (ARM), conforme mostrado no exemplo a seguir:

spec:
  vnetSubnetID: "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/virtualNetworks/{vnet-name}/subnets/{subnet-name}"

Configuração de tamanho do disco do sistema operacional

O campo osDiskSizeGB especifica o tamanho do disco do sistema operacional em gigabytes. O valor padrão é 128 GB e o valor mínimo é 30 GB.

Considere tamanhos maiores de disco do sistema operacional para cargas de trabalho que:

Armazene dados significativos localmente.
Exigir espaço extra para imagens de contêiner.
Tem requisitos elevados de entrada/saída (E/S) de disco.

Configuração de tamanho de disco do sistema operacional de exemplo

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Configuração de disco do sistema operacional efêmero

O NAP usa automaticamente discos do sistema operacional efêmero quando disponíveis e adequados para o tamanho do disco solicitado. Os discos de sistema operacional efêmero fornecem melhor desempenho e menor custo em comparação aos discos gerenciados.

Critérios de seleção de disco efêmero

O sistema escolhe automaticamente discos Efêmeros nos seguintes cenários:

O tipo de instância de VM dá suporte a discos de SO efêmeros.
A capacidade do disco efêmero é maior ou igual à solicitada osDiskSizeGB.
A VM tem capacidade de armazenamento efêmera suficiente.

Se essas condições não forem atendidas, o sistema retornará ao uso de discos gerenciados.

Tipos de disco efêmero e priorização

Azure VMs podem ter diferentes tipos de armazenamento efêmero. O sistema usa a seguinte ordem de prioridade:

Discos NVMe (maior desempenho)
Discos de cache (desempenho equilibrado)
Discos de recurso (desempenho básico)

Exemplo de configuração de disco efêmero

Você pode usar os requisitos do pool de nós para garantir que os nós tenham capacidade suficiente de disco efêmero, conforme mostrado no exemplo a seguir:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ephemeral-disk-pool
spec:
  template:
    spec:
      requirements:
        - key: karpenter.azure.com/sku-storage-ephemeralos-maxsize
          operator: Gt
          values: ["128"]  # Require ephemeral disk larger than 128 GB
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: my-node-class
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: my-node-class
spec:
  osDiskSizeGB: 128  # This will use ephemeral disk if available and large enough

Essa configuração garante que somente tipos de instância de VM com discos efêmeros maiores que 128 GB sejam selecionados, garantindo o uso de discos efêmeros para o tamanho do disco do sistema operacional especificado.

Configuração de número máximo de pods

O campo maxPods especifica o número máximo de pods que podem ser agendados em um nó. Essa configuração afeta a densidade do cluster e a configuração de rede.

O valor mínimo é maxPods 10 e o valor máximo é 250.

Comportamento padrão para `maxPods`

O comportamento maxPods padrão depende da configuração do plug-in de rede. A tabela a seguir resume os valores padrão:

Configuração do plug-in de rede	Padrão `maxPods` por nó
Azure CNI com rede padrão (v1 ou NodeSubnet)	30
Azure CNI com rede de sobreposição	250
Nenhum (nenhum plug-in de rede)	250
Outras configurações	110 (padrão do Kubernetes)

Configuração máxima de pods de exemplo

spec:
  maxPods: 50  # Allow up to 50 pods per node

Configuração de LocalDNS

O LocalDNS implanta um proxy DNS de nível de nó que resolve consultas DNS mais próximas de cargas de trabalho, reduzindo a latência da consulta e melhorando a resiliência durante interrupções de DNS transitórias. Para obter mais informações, consulte a documentação do LocalDNS. Por padrão, o LocalDNS é definido como Desabilitado e pode ser configurado para as seguintes opções:

Disabled (padrão) – desabilita o recurso LocalDNS. As consultas DNS não são resolvidas localmente no nó.
Preferred – O AKS gerencia a habilitação do Local DNS com base na versão do Kubernetes do pool de nós. A configuração sempre é validada e incluída, mas o LocalDNS não está habilitado, a menos que a versão correta do Kubernetes seja usada.
Required - O LocalDNS será aplicado no pool de nós se todos os pré-requisitos forem atendidos. Se os requisitos não forem atendidos, a implantação falhará.

Configuração de LocalDNS de exemplo

Você pode personalizar configurações de LocalDNS, como vnetDNSOverrides e kubeDNSOverrides. Para obter mais detalhes sobre os plug-ins com suporte, consulte Personalizar LocalDNS.

spec:
  localDNS:
    mode: Required
    vnetDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
    kubeDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"

Atualizar a configuração de LocalDNS em um AKSNodeClass existente

A localDNS configuração participa da detecção de descompasso como outras AKSNodeClass configurações. Quando você altera spec.localDNS em um AKSNodeClass ao qual os nós existentes já fazem referência, o NAP aplica a alteração por meio do mecanismo padrão Descompasso. O NAP não refaz a imagem dos nós existentes.

O comportamento a seguir se aplica quando você altera o modo LocalDNS ou substituições definidas, como alterar mode de Disabled para Required:

Novos nós: cada nó que o NAP provisiona depois que você atualiza o AKSNodeClass usa a nova configuração do LocalDNS.
Nós existentes: o NAP marca os objetos existentes NodeClaim como descompassados porque sua configuração registrada não corresponde mais à AKSNodeClass. O NAP inicia um nó de substituição que usa a nova configuração LocalDNS, depois isola, drena e remove o nó descompassado.
Sem refazer imagem: habilitar o LocalDNS em um pool de nós gerenciados do AKS recria a imagem de cada nó no pool. Em vez disso, o NAP substitui o nó. De qualquer forma, os pods nos nós afetados são despejados e reagendados, portanto, planeje o mesmo impacto na carga de trabalho.

Importante

Definir mode como Preferred ou Disabled também altera a configuração resolvida AKSNodeClass e descompassa os nós existentes. Qualquer alteração na seção localDNS, incluindo os valores kubeDNSOverrides e vnetDNSOverrides, causa a substituição do nó.

Quando a substituição é iniciada

A avaliação e a substituição de descompasso começam assim que você aplica o AKSNodeClass atualizado. A substituição segue o ciclo de vida padrão de interrupção do NAP, portanto, a taxa e o momento dependem dos controles de interrupção que você configura para os recursos NodePool que fazem referência à AKSNodeClass.

Como o NAP orquestra a substituição

O descompasso causado por uma alteração no LocalDNS respeita os controles padrão de interrupção de NAP descritos na tabela a seguir:

Controle	Efeito na substituição induzida por LocalDNS
Orçamentos de interrupção (`spec.disruption.budgets`)	Os limites determinam quantos nós o NAP substitui ao mesmo tempo. Se você não definir orçamentos, o NAP usará como padrão um orçamento de `nodes: 10%`, de modo que interrompe no máximo 10% dos nós do pool de nós simultaneamente.
Orçamento `schedule` e `duration`	Limita a substituição a uma janela de manutenção. Defina `nodes: "0"` fora da área da janela para bloquear a substituição.
Orçamentos de interrupção de pod (PDBs)	Aplicar durante a drenagem do nó. O NAP aguarda em vez de remover pods que violam um PDB.
`karpenter.sh/do-not-disrupt` anotação	Exclui pods e nós anotados da interrupção voluntária, incluindo o descompasso.
`terminationGracePeriod`	Limita o tempo de drenagem. Essa configuração ignora PDBs e a anotação `karpenter.sh/do-not-disrupt` quando o período expira.

A substituição não é totalmente serial nem totalmente paralela. O NAP provisiona a capacidade de substituição antes de remover um nó desatualizado, mas pode substituir vários nós que fazem referência ao mesmo AKSNodeClass simultaneamente, até o limite definido pelos orçamentos de interrupção.

Warning

Se você não definir orçamentos de interrupção em seus pools de nós e não definir orçamentos de interrupção de pod para suas cargas de trabalho, altere localDNS em um AKSNodeClass com alta utilização pode interromper até 10% de seus nós de cada vez sem proteção no nível do aplicativo, o que pode causar tempo de inatividade da carga de trabalho. Defina PDBs para cargas de trabalho críticas e defina um orçamento de interrupção conservador antes de alterar localDNS em um cluster de produção.

Reduzir o risco de indisponibilidade ao habilitar o LocalDNS

Confirme se os servidores DNS personalizados respondem a consultas pelos protocolos UDP e TCP na porta 53 a partir da sub-rede do nó. Para obter mais informações, consulte Validar o DNS personalizado antes de habilitar o LocalDNS.
Defina os orçamentos de interrupção de pods para cada carga de trabalho crítica.

Defina um orçamento de interrupção conservador nos recursos NodePool afetados antes de alterar o AKSNodeClass, conforme mostrado no exemplo a seguir:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
    - nodes: "1"   # Replace one node at a time

Aplique a localDNS alteração primeiro em um ambiente de não produção AKSNodeClass. Como alternativa, crie um AKSNodeClass com LocalDNS habilitado e migre cargas de trabalho para um NodePool que faça referência a ele.

Monitore o progresso da substituição listando os NodeClaims. A substituição é concluída quando nenhum NodeClaim relata a condição de status Drifted.

# List node claims and watch replacements appear as drifted nodes are removed
kubectl get nodeclaims

# Inspect the status conditions on a specific node claim
kubectl describe nodeclaim <nodeclaim-name>

Confirme se o LocalDNS está ativo nos nós de substituição. Para obter mais informações, consulte Verificar a operação LocalDNS.

Configuração do Kubelet

A seção kubelet permite que você configure vários parâmetros kubelet que afetam o comportamento dos nós. Esses parâmetros são argumentos kubelet típicos, portanto, o provedor do Azure simplesmente os passa para o kubelet no nó.

Importante

Defina as configurações de kubelet com cuidado e teste as alterações em ambientes de não produção primeiro.

Gerenciamento de CPU

As seguintes configurações controlam o comportamento de gerenciamento de CPU para o kubelet:

spec:
  kubelet:
    cpuManagerPolicy: "static"  # or "none"
    cpuCFSQuota: true
    cpuCFSQuotaPeriod: "100ms"

cpuManagerPolicy: controla como o kubelet aloca recursos de CPU. Defina para "static" a fixação de CPU em cargas de trabalho sensíveis à latência.
cpuCFSQuota: habilita a imposição de cotas do Agendador Completamente Justo (CFS) da CPU para contêineres que especificam limites de CPU.
cpuCFSQuotaPeriod: define o período de cota do CFS da CPU.

Coleta de lixo de imagens

As seguintes configurações controlam o comportamento de coleta de lixo de imagem para o kubelet:

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

Essas configurações controlam quando o kubelet executa a GC de imagens de contêiner:

imageGCHighThresholdPercent: percentual de uso de disco que aciona a coleta de lixo de imagens.
imageGCLowThresholdPercent: percentual de uso do disco de destino após a coleta de lixo.

Gerenciamento de topologia

A configuração a seguir controla a política do gerenciador de topologia para o kubelet:

spec:
  kubelet:
    topologyManagerPolicy: "best-effort"  # none, restricted, best-effort, single-numa-node

O gerenciador de topologia ajuda a coordenar a alocação de recursos para cargas de trabalho sensíveis à latência entre recursos de CPU e do dispositivo (como GPU).

Configuração do sistema

As seguintes configurações permitem que você configure parâmetros adicionais do sistema para o kubelet:

spec:
  kubelet:
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"
    containerLogMaxSize: "50Mi"
    containerLogMaxFiles: 5
    podPidsLimit: 4096

allowedUnsafeSysctls: lista de sysctls não seguros permitidos que os pods podem usar.
containerLogMaxSize: tamanho máximo dos arquivos de log de contêiner antes da rotação.
containerLogMaxFiles: número máximo de arquivos de log de contêiner a serem retidos.
podPidsLimit: número máximo de processos permitidos em qualquer pod.

Configurações de sistema operacional personalizadas do Linux

A seção LinuxOSConfig permite que você configure vários parâmetros kubelet que afetam o comportamento dos nós. Esses parâmetros são argumentos personalizados típicos do SO, portanto, o NAP simplesmente os encaminha para o kubelet no nó.

Para obter mais informações sobre configurações personalizadas do sistema operacional Linux, valores padrão e considerações, consulte a referência de parâmetros de configuração de nó personalizado.

Importante

Defina as configurações do sistema operacional Linux com cuidado e teste as alterações em ambientes de não produção primeiro.

Configurações de limites do identificador de arquivo do Linux

Use as configurações a seguir para definir as configurações do sistema de arquivos.

spec:
  linuxOSConfig: 
    # Sysctl Settings  
    sysctls:  
      # File System Settings  
      fsFileMax: 2000000               # Range: 8192-12000500  Default: Max of available range
      fsInotifyMaxUserWatches: 1000000 # Range: 781250-2097152 Default: 1048576
      fsAioMaxNr: 1000000              # Range: 65536-6553500  Default: 65536
      fsNrOpen: 1000000                # Range: 8192-20000500  Default: 1048576

Configurações de ajuste de rede e soquete do Linux

Use as configurações a seguir para definir o TCP e a configuração de rede.

spec:
  linuxOSConfig:
      # Network Settings  
      netCoreSomaxconn: 65535          # Range: 4096-3240000  Default: 16384
      netCoreNetdevMaxBacklog: 5000    # Range: 1000-3240000  Default: 1000
      netCoreRmemMax: 134217728        # Range: 212992-134217728  Default: 1048576
      netCoreOptmemMax: 102400         # Range: 20480-4194304     Default: 131072 
      netCoreWmemMax: 134217728        # Range: 212992-134217728  Default: 212992
      netCoreRmemDefault: 212992       # Range: 212992-134217728  
      netCoreWmemDefault: 212992       # Range: 212992-134217728  
      netIPv4IPLocalPortRange: "1024 65535" # Format: "first last", first: 1024-60999, last: 32768-65535  

      # Neighbor Table GC Thresholds  
      netIPv4NeighDefaultGcThresh1: 1024   # Range: 128-80000  Default: 4096
      netIPv4NeighDefaultGcThresh2: 2048   # Range: 512-80000  Default: 8192
      netIPv4NeighDefaultGcThresh3: 4096   # Range: 1024-80000  Default: 16384
      # Note: thresh1 <= thresh2 <= thresh3  

      # Connection Tracking  
      netNetfilterNfConntrackBuckets: 131072  # Range: 65536-524288   Default: dynamically calculated 
      netNetfilterNfConntrackMax: 262144       # Range: 131072-2097152 Default: dynamically calculated

Configurações de limite de trabalho do Linux

Use as configurações a seguir para definir a configuração do kernel.

spec:
  linuxOSConfig:
      # Kernel Settings  
      kernelThreadsMax: 100000         # Range: 20-513785  Default: Dynamically calculated

Configurações de memória virtual do Linux

Use as opções a seguir para ajustar a operação do subsistema de memória virtual do kernel do Linux e do a escrita de dados sujos em disco.

spec:
  linuxOSConfig:
      # Memory Management  
      vmMaxMapCount: 262144          # Range: 65530-262144 Default: Max of available range
      vmVfsCachePressure: 100        # Range: 0-100  Default: 100
      vmSwappiness: 60               # Range: 0-100  Default: 60

      # Swap File Configuration  
      swapFileSize: "2Gi"             # Default: (not set) | Pattern: quantity with units Note: Requires kubelet.failSwapOn: false  

      # Transparent Huge Pages  
      transparentHugePageEnabled: "madvise"    # Values: [always, madvise, never]  Default: always
      transparentHugePageDefrag: "defer+madvise" # Values: [always, defer, defer+madvise, madvise, never]  Default: madvise

Configurações de GPU

Use o campo a seguir para habilitar a instalação personalizada do driver de GPU, como com o Operador de GPU NVIDIA.

spec:
  gpu:
    mode: 
      # acceptable values: [driver, none] default(or if not specified): driver
      # none skips gpu driver installation, driver has NAP manage the GPU driver installation  
      none

Configurações de segurança

Criptografia no host

O campo a seguir especifica se a criptografia no nível do host está habilitada para nós provisionados. Quando você define esse campo como true, o NAP inclui apenas opções de instância compatíveis com a criptografia no host.

spec:
  security:
    encryptionatHost: 
      # acceptable values: [true, false] default(or if not specified): false  
      false

Para obter mais informações sobre criptografia baseada no host, consulte a documentação sobre Criptografia no Host.

Chaves gerenciadas personalizadas e conjuntos de criptografia de disco

O NAP dá suporte a clusters que usam chaves gerenciadas pelo cliente e conjuntos de criptografia de disco. Habilite essas opções no nível do cluster. Eles não têm AKSNodeClass campos que você precisa definir. Verifique se a identidade do cluster tem o RBAC (controle de acesso baseado em função) adequado:

A identidade do cluster tem acesso Reader ao Conjunto de Criptografia de Discos.
O recurso de conjunto de Criptografia de Disco tem acesso Key Vault Crypto Service Encryption User ao Azure Key Vault.

Para obter informações sobre chaves gerenciadas pelo cliente e conjuntos de criptografia de disco habilitados durante a criação do cluster, consulte a documentação sobre Chaves Gerenciadas pelo Cliente.

Habilitar a inicialização confiável em clusters NAP

Clusters com NAP (Provisionamento Automático de Nó) habilitado podem habilitar a Inicialização Confiável usando o campo spec.security.trustedLaunch do AKSNodeClass CRD. Defina os campos secureBoot e vTPM como true para habilitar a inicialização confiável para quaisquer nós gerenciados por NAP novos ou existentes associados a esse CRD AKSNodeClass.

spec:
  security:
  # Enables trusted lunch
  # Valid values: true, false; defaults to false if not specified
     trustedLaunch:
       secureBoot: true
       vTPM: true

Configuração de tags de recurso do Azure

Você pode especificar Azure marcas de recurso que se aplicam a todas as instâncias de VM criadas usando um recurso AKSNodeClass específico. As marcas são úteis para acompanhamento de custos, organização de recursos e requisitos de conformidade.

Limitações de marca

Azure tags de recurso têm um limite de 50 tags por recurso.
Os nomes de marca não diferenciam maiúsculas de minúsculas e os valores de marca diferenciam maiúsculas de minúsculas.
Azure reserva alguns nomes de marca que não podem ser usados. Para obter mais informações, consulte Diretrizes e limites de tag.

Configuração de etiquetas de exemplo

spec:
  tags:
    Environment: "production"
    Team: "platform"
    Application: "web-service"
    CostCenter: "engineering"

Exemplo de configuração abrangente `AKSNodeClass`

O exemplo a seguir demonstra uma configuração abrangente AKSNodeClass que inclui todas as configurações discutidas neste artigo:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: comprehensive-example
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: comprehensive-example
spec:
  # Image family configuration
  # Default: Ubuntu
  # Valid values: Ubuntu, AzureLinux, AzureContainerLinux
  imageFamily: Ubuntu

  # FIPS compliant mode - allows support for FIPS-compliant node images
  # Default: Disabled
  # Valid values: FIPS, Disabled
  fipsMode: Disabled

  # Artifact Streaming- allows use of artifact streaming feature; To use this feature container images must also enable artifact streaming on ACR
  # Valid values: true, false; defaults to false if not specified
  artifactStreaming:
    enabled: true

  # LocalDNS mode - allows use of LocalDNS feature
  # Default: Disabled
  # Valid values: Preferred, Required, Disabled
  # vnetDNSOverrides and kubeDNSOverrides are both required, even when mode is Disabled
  # Each list must include the "." and "cluster.local" zones, and each zone must set all nine fields
  localDNS:
    mode: Disabled
    # vnetDNSOverrides apply to DNS traffic from pods with dnsPolicy:default and from kubelet
    vnetDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: VnetDNS   # the "." zone can't forward to ClusterCoreDNS in vnetDNSOverrides
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS   # cluster.local can't forward to VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
    # kubeDNSOverrides apply to DNS traffic from pods with dnsPolicy:ClusterFirst
    kubeDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"

  # Virtual network subnet configuration (optional)
  # If not specified, uses the default --vnet-subnet-id from Karpenter installation
  vnetSubnetID: "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/my-rg/providers/Microsoft.Network/virtualNetworks/my-vnet/subnets/my-subnet"

  # OS disk size configuration
  # Default: 128 GB
  # Minimum: 30 GB
  osDiskSizeGB: 128

  # Maximum pods per node configuration
  # Default behavior depends on network plugin:
  # - Azure CNI with standard networking: 30 pods
  # - Azure CNI with overlay networking: 250 pods
  # - Other configurations: 110 pods
  # Range: 10-250
  maxPods: 30

  # GPU driver installation (optional)
  # Default: driver - NAP manages gpu driver installation
  # none skips gpu driver installation
  # Valid values: driver, none
  gpu:
    mode: 
      driver

  # Azure resource tags (optional)
  # Applied to all VM instances created with this AKSNodeClass
  tags:
    Environment: "production"
    Team: "platform-team"
    Application: "web-service"
    CostCenter: "engineering"

  # Kubelet configuration (optional)
  # All fields are optional with sensible defaults
  kubelet:
    # CPU management policy
    # Default: "none"
    # Valid values: none, static
    cpuManagerPolicy: "static"

    # CPU CFS quota enforcement
    # Default: true
    cpuCFSQuota: true

    # CPU CFS quota period
    # Default: "100ms"
    cpuCFSQuotaPeriod: "100ms"

    # Image garbage collection thresholds
    # imageGCHighThresholdPercent must be greater than imageGCLowThresholdPercent
    # Range: 0-100
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

    # Topology manager policy
    # Default: "none"
    # Valid values: none, restricted, best-effort, single-numa-node
    topologyManagerPolicy: "best-effort"

    # Allowed unsafe sysctls (optional)
    # Comma-separated list of unsafe sysctls or patterns
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"

    # Container log configuration
    # containerLogMaxSize default: "50Mi"
    containerLogMaxSize: "50Mi"
    
    # containerLogMaxFiles default: 5, minimum: 2
    containerLogMaxFiles: 5

    # Pod process limits
    # Default: -1 (unlimited)
    podPidsLimit: 4096

  security:
  # Enables trusted lunch
  # Valid values: true, false; default(or if not specified): false  
     trustedLaunch:
      secureBoot: true
      vTPM: true
  # Encryption at host
     encryptionatHost: 
      # acceptable values: [true, false] default(or if not specified): false  
      false

Próximas etapas

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

Comentários

Esta página foi útil?

Última atualização em 2026-10-08

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

Visão geral dos recursos do AKSNodeClass

Configuração da família de imagens

Famílias de imagens com suporte

Configuração da família de imagens de exemplo

Configuração de imagem de nó compatível com FIPS

Streaming de artefatos

Pré-requisitos

Habilitar o streaming de artefatos em clusters NAP

Configuração de sub-rede de rede virtual (VNet)

Configuração de sub-rede de exemplo

Configuração de tamanho do disco do sistema operacional

Configuração de tamanho de disco do sistema operacional de exemplo

Configuração de disco do sistema operacional efêmero

Critérios de seleção de disco efêmero

Tipos de disco efêmero e priorização

Exemplo de configuração de disco efêmero

Configuração de número máximo de pods

Comportamento padrão para maxPods

Configuração máxima de pods de exemplo

Configuração de LocalDNS

Configuração de LocalDNS de exemplo

Atualizar a configuração de LocalDNS em um AKSNodeClass existente

Quando a substituição é iniciada

Como o NAP orquestra a substituição

Reduzir o risco de indisponibilidade ao habilitar o LocalDNS

Configuração do Kubelet

Gerenciamento de CPU

Coleta de lixo de imagens

Gerenciamento de topologia

Configuração do sistema

Configurações de sistema operacional personalizadas do Linux

Configurações de limites do identificador de arquivo do Linux

Configurações de ajuste de rede e soquete do Linux

Configurações de limite de trabalho do Linux

Configurações de memória virtual do Linux

Configurações de GPU

Configurações de segurança

Criptografia no host

Chaves gerenciadas personalizadas e conjuntos de criptografia de disco

Habilitar a inicialização confiável em clusters NAP

Configuração de tags de recurso do Azure

Limitações de marca

Configuração de etiquetas de exemplo

Exemplo de configuração abrangente AKSNodeClass

Próximas etapas

Comentários

Recursos adicionais

Comportamento padrão para `maxPods`

Exemplo de configuração abrangente `AKSNodeClass`