Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo explica como configurar pools de nós para o autoprovisionamento de nós (NAP) no Azure Kubernetes Service (AKS), incluindo seletores de SKU, limites de recursos e pesos de prioridade. Ele também fornece exemplos para ajudá-lo a começar.
O AKS Automatic inclui NAP por defeito. Para os clusters AKS Standard, tem de ativar o NAP antes de configurar os respetivos conjuntos de nós.
Como a NAP seleciona as VMs para pools de nós
A NAP usa requisitos de SKU de máquina virtual (VM) para decidir as melhores VMs para cargas de trabalho pendentes. Você pode configurar:
- Famílias de SKU e tipos de instância específicos.
- Limites de recursos e prioridades.
- Instâncias spot ou sob demanda.
- Requisitos de arquitetura, GPU e outras capacidades.
O NodePool recurso define restrições nos nós que a NAP cria e nos pods que são executados nesses nós. Quando ativa o NAP com a configuração predefinida do grupo de nós definida como Auto, são criados recursos NodePool predefinidos. Pode modificar estes pools de nós ou criar pools de nós adicionais para se adequar aos requisitos da sua carga de trabalho.
Como o NAP avalia e seleciona conjuntos de nós
Ao configurar NodePools para o NAP, tenha em mente os seguintes comportamentos:
- O NAP requer pelo menos um
NodePoolpara funcionar. - O NAP avalia cada
NodePoolconfigurado. - NAP ignora
NodePoolscom taints não tolerados por um pod. - A NAP aplica manchas de inicialização a nós provisionados, mas não requer tolerância de pod.
- O NAP funciona melhor com os mutuamente exclusivos
NodePools, cujos requisitos não se sobrepõem, de modo que cada pod corresponde apenas a um pool. Quando há múltiplasNodePoolscorrespondências, o NAP usa o que tem o maior peso.
Revisar a configuração padrão do pool de nós
A configuração do Karpenter NodePool padrão nomeado default criado pela NAP é a seguinte:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: default
spec:
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
template:
spec:
nodeClassRef:
group: karpenter.azure.com
kind: AKSNodeClass
name: default
expireAfter: Never
# Requirements that constrain the parameters of provisioned nodes.
# These requirements are combined with pod.spec.affinity.nodeAffinity rules.
# Operators { In, NotIn, Exists, DoesNotExist, Gt, and Lt } are supported.
# https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators
requirements:
- key: kubernetes.io/arch
operator: In
values:
- amd64
- key: kubernetes.io/os
operator: In
values:
- linux
- key: karpenter.sh/capacity-type
operator: In
values:
- on-demand
- key: karpenter.azure.com/sku-family
operator: In
values:
- D
O NAP também cria um system-surge pool de nós que fornece capacidade Linux AMD64 sob demanda para complementos críticos do sistema. Quando um pod pendente tolera a CriticalAddonsOnly=true:NoSchedule contaminação e corresponde aos requisitos do pool, o NAP pode provisionar um nó a partir desse pool. Os nós criados pelo pool têm o kubernetes.azure.com/mode: system rótulo.
Controle os conjuntos de nós predefinidos
Quando criares um novo cluster do AKS com NAP ativado com a CLI do Azure, inclui o sinalizador --node-provisioning-default-pools para controlar se o AKS cria o NodePools NAP predefinido. Também podes usar esta opção com az aks update ao ativar o NAP num cluster existente.
A --node-provisioning-default-pools bandeira aceita os seguintes valores:
-
Auto(padrão): Cria dois padrõesNodePoolspara uso imediato. -
None: Não cria nenhumNodePools. Você deve definir o seu.
Advertência
Alterando de Auto para None: Se você alterar a configuração de Auto para None em um cluster existente, o padrão NodePools não será excluído automaticamente. Antes de os apagar, defina a capacidade de substituição adequada para complementos críticos do sistema. Tens de apagar manualmente o padrão NodePools se já não precisares deles.
Opções de configuração do pool de nós
As seções a seguir descrevem várias opções de configuração para o NAP, incluindo rótulos conhecidos e selecionadores de SKU, limites dos pools de nós e pesos dos pools de nós.
Etiquetas e seletores de SKU bem conhecidos
Kubernetes define etiquetas bem conhecidas que a Azure implementa. Você pode definir esses rótulos na spec.requirements seção da NodePool API. O NAP também suporta rótulos específicos do Azure para agendamento mais avançado.
A tabela seguinte lista os rótulos que pode usar na spec.requirements secção da sua NodePool API para definir características de VM para os seus nós:
| Selector | Description | Example |
|---|---|---|
karpenter.sh/capacity-type |
Tipo de alocação de VM (spot / sob demanda) | Ponto |
karpenter.azure.com/sku-family |
Família VM SKU | D, F, L, etc. |
karpenter.azure.com/sku-series |
Série VM SKU | Dpls_v6 |
karpenter.azure.com/sku-name |
Nome SKU explícito | Standard_A1_v2 |
karpenter.azure.com/sku-version |
Versão SKU (sem "v", pode usar 1) | 1, 2 |
karpenter.azure.com/sku-cpu |
Número de CPUs na VM | 16 |
karpenter.azure.com/sku-memory |
Memória em VM em MiB | 131072 |
karpenter.azure.com/sku-gpu-name |
Nome da GPU | A100 |
karpenter.azure.com/sku-gpu-manufacturer |
Fabricante de GPU | NVIDIA |
karpenter.azure.com/sku-gpu-count |
Contagem de GPU por VM | 2 |
karpenter.azure.com/sku-networking-accelerated |
Se a VM tem rede acelerada | [verdadeiro, falso] |
karpenter.azure.com/sku-storage-premium-capable |
Se a VM suporta armazenamento de E/S Premium | [verdadeiro, falso] |
karpenter.azure.com/sku-storage-ephemeralos-maxsize |
Limite de tamanho para o disco efémero do sistema operativo (SO) em GB | 92 |
kubernetes.azure.com/sku-cpu |
Número de CPUs na VM | 16 |
kubernetes.azure.com/sku-memory |
Memória em VM em MiB | 131072 |
kubernetes.azure.com/cluster |
Nome do cluster AKS | meu-cluster |
kubernetes.azure.com/mode |
Modo de conjunto de nós | [sistema, utilizador] |
kubernetes.azure.com/priority |
Prioridade | [spot, padrão] |
kubernetes.azure.com/os-sku |
SKU do sistema operativo | [Ubuntu, AzureLinux] |
kubernetes.azure.com/fips_enabled |
Se o FIPS está ativado | verdadeiro |
topology.kubernetes.io/zone |
Zona(s) de disponibilidade | [uksouth-1, uksouth-2, uksouth-3] |
kubernetes.io/os |
Sistema operativo | Linux |
kubernetes.io/arch |
Arquitetura de CPU (AMD64 ou ARM64) | [AMD64, ARM64] |
Os valores do seletor de memória nesta tabela são os valores MiB reportados nos nós criados pelo NAP. Antes de adicionar um seletor, inspecione as etiquetas nos seus nós para confirmar o valor usado pelo seu cluster.
Exemplos da família SKU
O karpenter.azure.com/sku-family seletor permite que você segmente famílias de VM específicas.
| Família | Description |
|---|---|
| Série D | VMs de uso geral com relação CPU/memória balanceada |
| Série F | VMs otimizadas para computação com alta relação CPU/memória |
| Série E | VMs com otimização de memória para aplicativos que consomem muita memória |
| Série L | VMs otimizadas para armazenamento com alta taxa de transferência de disco |
| Série N | Máquinas Virtuais com GPU para cargas de trabalho intensivas em computação |
Exemplo de configuração usando a família SKU:
requirements:
- key: karpenter.azure.com/sku-family
operator: In
values:
- D
- F
Exemplo de SKU para GPU
Para provisionar os nós da GPU NVIDIA com NAP, crie um NodePool que selecione tamanhos de VM com GPU. O exemplo seguinte permite à NAP selecionar SKUs NVIDIA da série N:
requirements:
- key: karpenter.azure.com/sku-family
operator: In
values:
- N
- key: karpenter.azure.com/sku-gpu-manufacturer
operator: In
values:
- nvidia
Se quiser que o AKS instale e faça a gestão do controlador de GPU NVIDIA, do plug-in de dispositivo, do exportador de métricas do Data Center GPU Manager (DCGM) e dos sinais de estado de funcionamento da GPU em nós GPU aprovisionados pelo NAP, configure a GPU gerida no AKSNodeClass referido. Para mais informações, consulte Criar um pool de nós de GPU gerido por AKS.
Exemplos de nomes de SKU
O karpenter.azure.com/sku-name seletor permite especificar o tipo exato de instância da VM.
requirements:
- key: karpenter.azure.com/sku-name
operator: In
values:
- Standard_D4s_v3
- Standard_F8s_v2
Exemplos de versões de SKU
O karpenter.azure.com/sku-version seletor tem como alvo gerações específicas de SKUs de VM.
requirements:
- key: karpenter.azure.com/sku-version
operator: In
values:
- "3" # v3 generation
- "5" # v5 generation
Exemplo de zona de disponibilidade
O topology.kubernetes.io/zone seletor permite especificar as zonas de disponibilidade para seus nós.
requirements:
- key: topology.kubernetes.io/zone
operator: In
values:
- eastus-1
- eastus-2
Observação
Para listar tamanhos de VMs que suportam zonas de disponibilidade numa região, use o az vm list-skus comando com os --location <region> --zone --output table parâmetros. Confirme se o tamanho da VM selecionado suporta as zonas do NodePool requisito.
Exemplo de arquitetura
O kubernetes.io/arch seletor permite que você especifique a arquitetura da CPU para seus nós. NAP suporta ambos os amd64 e arm64 nós.
requirements:
- key: kubernetes.io/arch
operator: In
values:
- amd64
- arm64
Exemplo de SO
O kubernetes.io/os seletor permite que você especifique o sistema operacional para seus nós.
requirements:
- key: kubernetes.io/os
operator: In
values:
- linux
Exemplo de tipo de capacidade
O seletor karpenter.sh/capacity-type permite especificar se deseja usar instâncias Spot ou On-demand.
Observação
NAP prioriza instâncias Spot quando Spot e On-demand são especificados.
requirements:
- key: karpenter.sh/capacity-type
operator: In
values:
- spot
- on-demand
Limites do pool de nós
Por padrão, o NAP tenta agendar as suas cargas de trabalho dentro da quota disponível do Azure. Para um pool dinâmico de nós, podes especificar limites agregados de recursos em todos os nós provisionados por esse pool. No exemplo seguinte, cpu: "1000" limita o pool a 1.000 núcleos vCPU e memory: 1000Gi limita-o a 1.000 gibibytes de memória:
spec:
# Resource limits constrain the total size of the node pool.
# Limits prevent Node Auto Provisioning from creating new instances once the limit is exceeded.
limits:
cpu: "1000"
memory: 1000Gi
Pesos da piscina de nós
Quando tiver vários grupos de nós definidos, pode definir uma preferência quanto ao local onde uma carga de trabalho deve ser executada, definindo o peso relativo nas definições dos grupos de nós. O campo weight aceita um número inteiro entre 1 e 100, e valores mais elevados atribuem uma prioridade mais elevada ao pool de nós. Se omitir weight, o seu valor é efetivamente 0. Por exemplo:
spec:
# Priority given to the node pool when the scheduler considers which to select.
# Higher weights indicate higher priority when comparing node pools.
# Specifying no weight is equivalent to specifying a weight of 0.
weight: 10
Pools de nós estáticos
Os grupos de nós estáticos mantêm o número fixo de nós provisionados pelo NAP especificado no campo replicas, independentemente da procura de pods. Para alterar a contagem de nós, escale explicitamente o NodePool, por exemplo usando kubectl scale com nodepool static-node-pool --replicas=7. O valor opcional limits.nodes limita o dimensionamento explícito e a capacidade temporária criada durante a substituição de nós. Para pools de nós estáticos, nodes é o único campo suportado em limits; não podes definir limites de CPU ou memória.
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-node-pool
spec:
replicas: 5
template:
spec:
requirements:
- key: karpenter.azure.com/sku-name
operator: In
values:
- Standard_D4s_v3
- Standard_F8s_v2
- key: topology.kubernetes.io/zone
operator: In
values:
- eastus-1
- eastus-2
- eastus-3
limits:
nodes: 10
Observação
Para pools de nós estáticos, só podes definir nodes no limits campo. Não é possível definir limites de recursos ou weight, e a consolidação de interrupções não se aplica. Depois de criares um NodePool, não podes alternar entre modos estático e dinâmico adicionando ou removendo o replicas campo.
Próximos passos
Para obter mais informações sobre o provisionamento automático de nós no AKS, consulte os seguintes artigos: