Configure os recursos AKSNodeClass para provisionamento automático de nós (NAP) no Azure Kubernetes Service (AKS)

Este artigo explica como configurar recursos AKSNodeClass para definir definições específicas de Azure para o auto-provisionamento de nós (NAP) em Azure Kubernetes Service (AKS) usando Karpenter. AKSNodeClass permite-lhe personalizar vários aspetos dos nós que o Karpenter provisiona, como a imagem da máquina virtual (VM), tamanho do disco do sistema operativo (SO), número máximo de pods por nó e configurações do kubelet.

Visão geral dos recursos do AKSNodeClass

Os recursos AKSNodeClass permitem configurar definições específicas do Azure para NAP. Cada NodePool recurso deve fazer referência a um AKSNodeClass utilizando spec.template.spec.nodeClassRef. Podes ter múltiplos NodePools que apontam para o mesmo AKSNodeClass, permitindo partilhar configurações comuns do Azure entre diferentes pools de nós.

Configuração da família de imagens

O campo imageFamily define a imagem predefinida da VM e a lógica de inicialização para os nós aprovisionados através de AKSNodeClass. Se não especificares uma família de imagens, é usada a versão padrão do sistema operativo de acordo com a versão do Kubernetes. As GPUs são suportadas com ambas as famílias de imagens em tamanhos de VM compatíveis. Para mais informações sobre a versão padrão do sistema operativo conforme a versão do Kubernetes, consulte a documentação da versão do AKS OS.

Famílias de imagens suportadas

• Ubuntu: Ubuntu é a distribuição Linux padrão para nós AKS.
  • As versões predefinidas do sistema operativo mudam consoante a tua versão do Kubernetes. Ubuntu 22.04 é o padrão para as versões Kubernetes 1.25 a 1.33. O Ubuntu 24.04 é o padrão para as versões Kubernetes 1.34 e posteriores.
• AzureLinux: Azure Linux é a distribuição alternativa Linux da Microsoft para cargas de trabalho AKS. Para mais informações, consulte a documentação do Azure Linux.

Exemplo de configuração da família de imagens

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

spec:
  imageFamily: AzureLinux

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

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

O fipsMode campo está definido por defeito como Desativado, podendo ser definido com as seguintes opções:

• FIPS - selecionar imagens de nós compatíveis com FIPS
• Desativado - não usar imagens de nós compatíveis com FIPS

O exemplo seguinte configura a 'AKSNodeClass' para selecionar imagens de nós compatíveis com FIPS, definindo fipsMode para FIPS:

spec:
  fipsMode: FIPS

Streaming de artefactos

O Artifact Streaming permite transmitir imagens de contentores do Azure Container Registry (ACR) para Azure Kubernetes Service (AKS). O AKS transfere apenas as camadas necessárias para o arranque inicial do pod, reduzindo o tempo necessário para implementar as cargas de trabalho.

Pré-requisitos

• O Artefact Streaming exige que tenhas um ACR de nível Premium integrado no teu cluster AKS.
• O Artifact Streaming tem de ser ativado no ACR.

Consulte a documentação do Artefact Streaming para instruções sobre como ativar o Artefact Streaming no ACR.

Ativar o streaming de artefactos em clusters NAP

Os clusters com Node Auto Provisioning (NAP) ativado podem ativar o streaming de artefactos utilizando o campo spec.artifactStreaming.enabled do AKSNodeClass CRD. Defina este campo como true para ativar a transmissão de artefactos para quaisquer nós, novos ou existentes, geridos pelo NAP associados a este 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

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

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

Exemplo de configuração de sub-rede

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

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

Configuração do tamanho do disco do SO

O osDiskSizeGB campo especifica o tamanho do disco do SO 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.
• Requer espaço extra para imagens de contêiner.
• Ter altos requisitos de E/S de disco.

Exemplo de configuração do tamanho do disco do SO

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Configuração efêmera do disco do sistema operacional

A NAP usa automaticamente discos Ephemeral OS quando disponíveis e adequados para o tamanho de disco solicitado. Os discos de SO efêmeros oferecem melhor desempenho e menor custo em comparação com os 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 suporta discos de SO efémero.
• A capacidade do disco efêmero é maior ou igual ao solicitado osDiskSizeGB.
• A VM tem capacidade de armazenamento efêmera suficiente.

Se essas condições não forem atendidas, o sistema voltará a usar discos gerenciados.

Tipos de disco efêmeros e priorização

As VMs do Azure podem ter diferentes tipos de armazenamento efémero. O sistema utiliza a seguinte ordem de prioridade:

• Discos NVMe (melhor desempenho)
• Discos de cache (desempenho equilibrado)
• Discos de recursos (desempenho básico)

Exemplo de configuração de disco efêmero

Você pode usar os requisitos da dotação de nós para garantir que os nós tenham capacidade de disco efémero suficiente, 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 apenas os tipos de instância de VM com discos efêmeros maiores que 128 GB sejam selecionados, garantindo o uso de disco efêmero para o tamanho de disco do sistema operacional especificado.

Configuração máxima de pods

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

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

Comportamento padrão para maxPods

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

Exemplo de configuração de pods máximos

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

Configuração LocalDNS

O LocalDNS implementa um proxy DNS ao nível do nó que resolve consultas DNS mais próximas das cargas de trabalho, reduzindo a latência das consultas e melhorando a resiliência durante perturbações transitórias do DNS. Para mais informações, consulte a documentação do LocalDNS. Por defeito, o LocalDNS está definido como Desabilitado e pode ser configurado com as seguintes opções:

• Disabled (por defeito) - Desativa a funcionalidade LocalDNS. As consultas DNS não são resolvidas localmente no nó.
• Preferred - O AKS gere a ativação do LocalDNS 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 é habilitado, a menos que a versão correta do Kubernetes seja usada.
• Required - O LocalDNS é imposto ao pool de nós se todos os pré-requisitos forem satisfeitos. Se os requisitos não forem atendidos, a implantação falhará.

Exemplo de configuração LocalDNS

Pode personalizar configurações do LocalDNS como vnetDNSOverrides e kubeDNSOverrides. Para mais detalhes sobre os plugins suportados, 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"

Atualize a configuração do LocalDNS numa AKSNodeClass existente

A localDNS definição participa na deteção de deriva, tal como outras AKSNodeClass definições. Quando mudas spec.localDNS num nó AKSNodeClass que os nós existentes já referenciam, o NAP aplica a alteração através do mecanismo padrão de Drift. O NAP não recria a imagem de nós existentes.

O seguinte comportamento aplica-se quando altera o modo LocalDNS ou substituições, como mudar mode de Disabled para Required:

• Novos nós: Cada nó que o NAP disponibiliza após atualizar o AKSNodeClass utiliza a nova configuração do LocalDNS.
• nós existentes: O NAP marca os objetos existentes NodeClaim como desviados porque a sua configuração registada já não corresponde à AKSNodeClass configuração. O NAP lança um nó de substituição que usa a nova configuração LocalDNS, depois isola, drena e remove o nó com drift.
• Sem reimagem: Ativar o LocalDNS num pool de nós gerido por AKS reimageia todos os nós do pool. O NAP substitui o nó em vez disso. De qualquer forma, os pods nos nós afetados são expulsos e reprogramados, por isso planeia para o mesmo impacto na carga de trabalho.

Quando a substituição começa

A avaliação e substituição do drift começa assim que aplica a versão atualizada AKSNodeClass. A substituição segue o ciclo de vida padrão da interrupção NAP, por isso a taxa e o momento dependem dos controlos de interrupção que configura nos NodePool recursos que referenciam o AKSNodeClass.

Como a NAP coordena a substituição

A deriva causada por uma alteração do LocalDNS respeita os controlos padrão de interrupção NAP descritos na tabela seguinte:

A substituição não é totalmente serial nem totalmente paralela. O NAP prevê capacidade de substituição antes de remover um nó com drift, mas pode substituir múltiplos nós que referenciam o mesmo AKSNodeClass em simultâneo, até ao limite que os seus orçamentos de interrupção definirem.

Reduza o risco de indisponibilidade ao ativar o LocalDNS

1. Confirme que os seus servidores DNS personalizados respondem às consultas por UDP e TCP, na porta 53, a partir da sub-rede do nó. Para mais informações, consulte Validar DNS personalizado antes de ativar o LocalDNS.

2. Defina orçamentos de interrupção de pods para cada carga de trabalho crítica.

3. Defina um orçamento de interrupção conservador nos recursos afetados NodePool antes de alterar o AKSNodeClass, como mostrado no seguinte exemplo:

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

4. Aplique a localDNS alteração primeiro a um ambiente de não produção AKSNodeClass. Alternativamente, cria um AKSNodeClass que tenha o LocalDNS ativado e migra cargas de trabalho para um NodePool que o referencia.

5. Acompanhe o progresso da substituição listando as declarações de nó. A substituição está concluída quando nenhuma claim de nó reporta a condição de estado 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>
   

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

Configuração do Kubelet

A seção kubelet permite configurar vários parâmetros kubelet que afetam o comportamento do nó. Estes parâmetros são argumentos típicos do kubelet, por isso o fornecedor da Azure simplesmente os transmite para o kubelet no nó.

Gerenciamento de CPU

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

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

• cpuManagerPolicy: Controla como o kubelet aloca recursos da CPU. Definido como "static" para fixação de CPU em cargas de trabalho sensíveis à latência.
• cpuCFSQuota: Permite a imposição de cota CFS (CPU Completely Fair Scheduler) para contêineres que especificam limites de CPU.
• cpuCFSQuotaPeriod: Define o período de cota CFS da CPU.

Coleta de lixo de imagens

As configurações a seguir controlam o comportamento de recolha de lixo de imagem para o kubelet:

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

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

• imageGCHighThresholdPercent: Porcentagem de uso do disco que aciona a recolha de lixo de imagens.
• imageGCLowThresholdPercent: Porcentagem 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 dispositivo (como GPU).

Configuração do sistema

As seguintes configurações permitem que você configure parâmetros extras 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 permitidos e não seguros que os pods podem usar.
• containerLogMaxSize: Tamanho máximo dos arquivos de log do contêiner antes da rotação.
• containerLogMaxFiles: Número máximo de arquivos de log de contêiner a serem mantidos.
• podPidsLimit: Número máximo de processos permitidos em qualquer pod.

Definições de configuração do sistema operacional personalizado do Linux

A seção LinuxOSConfig permite configurar vários parâmetros kubelet que afetam o comportamento do nó. Estes parâmetros são argumentos típicos do sistema operativo personalizado, por isso o NAP simplesmente os transmite para o kubelet no nó.

Para mais informações sobre definições de configuração personalizadas do sistema operativo Linux, valores predefinidos e considerações, consulte a referência de parâmetros de configuração personalizados do nó.

Definições de limites de controlo de ficheiros Linux

Use as seguintes definições para definir as definições do sistema de ficheiros.

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 socket Linux e sintonia de rede

Use as seguintes definições para definir o TCP e a definiçã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 

Definições de limite de trabalhador Linux

Use as seguintes definições para definir a definição do kernel.

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

Definições de memória virtual no Linux

Use as seguintes opções para ajustar o funcionamento do subsistema de memória virtual Linux do kernel Linux e a escrita de dados sujos no 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 da GPU

Use o campo seguinte para permitir a instalação personalizada de drivers de GPU, como no NVIDIA GPU Operator.

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

Encriptação no anfitrião

O campo seguinte especifica se a encriptação ao nível do host está ativada para nós provisionados. Quando defines este campo para true, o NAP inclui apenas opções de instância que suportam encriptação no host.

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

Para mais informações sobre encriptação baseada em host, consulte Documentação de Encriptação no Host.

Chaves geridas à medida e conjuntos de encriptação de disco

O NAP suporta clusters que utilizam chaves geridas pelo cliente e conjuntos de encriptação de disco. Ative estas opções ao nível do cluster. Eles não têm AKSNodeClass campos que precises de configurar. Certifique-se de que a identidade do seu cluster tem o controlo de acesso baseado em funções (RBAC) adequado:

• A identidade do cluster tem acesso ao Reader Conjunto de Encriptação de Discos.
• O recurso do conjunto de encriptação de disco tem Key Vault Crypto Service Encryption User acesso ao Azure Key Vault.

Para obter informações sobre chaves geridas pelo cliente e conjuntos de encriptação de disco ativados durante a criação do cluster, consulte a documentação sobre Chaves Geridas pelo Cliente.

Ativar o lançamento confiável em clusters NAP

Clusters com o Node Auto Provisioning (NAP) ativado podem permitir o arranque fidedigno utilizando o campo spec.security.trustedLaunch do CRD AKSNodeClass. Defina os campos secureBoot e vTPM para true para ativar o trusted launch para quaisquer nós novos ou existentes geridos pela NAP associados a este 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 etiquetas de recursos do Azure

Pode especificar Azure etiquetas de recurso que se aplicam a todas as instâncias de VM criadas usando um determinado recurso AKSNodeClass. As tags são úteis para controle de custos, organização de recursos e requisitos de conformidade.

Limitações das etiquetas

• As etiquetas de recurso do Azure têm um limite de 50 etiquetas por recurso.
• Os nomes das tags são insensíveis a maiúsculas e minúsculas, mas os valores das tags são sensíveis a maiúsculas e minúsculas.
• O Azure reserva alguns nomes de etiquetas que não podem ser usados. Para obter mais informações, consulte Orientação e limites de etiquetas.

Exemplo de configuração de tags

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óximos passos

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

• Utilizar o provisionamento automático de nós numa rede virtual personalizada
• Configuração de pools de nós para provisionamento automático de nós no AKS
• Configurar políticas de interrupção para provisionamento automático de nós no AKS