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

Este artigo explica como configurar os recursos do AKSNodeClass para definir configurações específicas do Azure para o provisionamento automático de nós (NAP) no Serviço Kubernetes do Azure (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

AKSNodeClass recursos permitem que você defina configurações específicas do Azure para NAP. Cada NodePool recurso deve fazer referência a um AKSNodeClass utilizando spec.template.spec.nodeClassRef. Você pode ter vários NodePools que apontam para o mesmo AKSNodeClass, permitindo que você compartilhe configurações comuns do Azure em 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: O Azure Linux é a distribuição Linux alternativa da Microsoft para cargas de trabalho AKS. Para obter 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 sub-rede de rede virtual (VNet)

O vnetSubnetID campo especifica qual sub-rede VNet do Azure deve ser usada para provisionar 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

A 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 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 agendados 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 do Kubelet

A kubelet seção permite configurar vários parâmetros kubelet que afetam o comportamento do nó. Esses parâmetros são argumentos kubelet típicos, portanto, o provedor do Azure simplesmente os passa 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.

Recolha de lixo de imagem

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 tags de recursos do Azure

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

Limitações das etiquetas

• As tags de recurso do Azure têm um limite de 50 tags 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.
• Azure reserva alguns nomes de tags 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

  # 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