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 determina a imagem de VM padrão e a lógica de arranque para nós provisionados através do AKSNodeClass. Se você não especificar uma família de imagens, o padrão será Ubuntu2204. As GPUs são suportadas com ambas as famílias de imagens em tamanhos de VM compatíveis.

Famílias de imagens suportadas

• Ubuntu: Ubuntu 22.04 Long Term Support (LTS) é a distribuição Linux padrão para nodos AKS.
• AzureLinux: Azure Linux é a distribuição alternativa Linux da Microsoft para cargas de trabalho AKS. Para mais informações, consulte a documentação 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

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:
        apiVersion: karpenter.azure.com/v1beta1
        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: "30s"
        forwardDestination: VnetDNS
        forwardPolicy: Random
        maxConcurrent: 80
        protocol: ForceTCP
        queryLogging: Log
        serveStale: Immediate
        serveStaleDuration: "100s"
      - zone: "cluster.local"
        cacheDuration: "40s"
        forwardDestination: VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 70
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Disable
        serveStaleDuration: "30s"
    kubeDNSOverrides:
      - zone: "."
        cacheDuration: "30s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: RoundRobin
        maxConcurrent: 100
        protocol: PreferUDP
        queryLogging: Log
        serveStale: Immediate
        serveStaleDuration: "60s"
      - zone: "cluster.local"
        cacheDuration: "10s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 50
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Disable
        serveStaleDuration: "30s"

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.

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:
        apiVersion: karpenter.azure.com/v1beta1
        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
  imageFamily: Ubuntu

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

  # LocalDNS mode - allows use of LocalDNS feature
  # Default: Disabled
  # Valid values: Preferred, Required, Disabled
  LocalDNS:
    mode: Disabled
    # additional details on vnetDNSOverrides and kubeDNSOverrides can be added here

  # 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

  # 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

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