Provisionamento automático de nós (versão prévia)
Ao implantar cargas de trabalho no AKS, você precisa tomar uma decisão sobre a configuração do pool de nós em relação ao tamanho da VM necessário. À medida que suas cargas de trabalho se tornam mais complexas e exigem diferentes recursos, memória e CPU para serem executadas, a sobrecarga de ter que projetar sua configuração de VM para várias solicitações de recursos se torna difícil.
O NAP (Provisionamento Automático de Nós) decide com base nos requisitos de recursos de pod pendentes a configuração ideal da VM para executar essas cargas de trabalho da maneira mais eficiente e econômica.
O NAP se baseia no projeto de Karpenter de Software Livre e o provedor do AKS também é de Software Livre. O NAP implanta e configura e gerencia automaticamente o Karpenter em seus clusters do AKS.
Importante
O NAP (provisionamento automático de nós) para AKS está atualmente em VERSÃO PRÉVIA. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.
Antes de começar
- É necessária uma assinatura do Azure. Caso não tenha uma assinatura do Azure, é possível criar uma conta gratuita.
- Você precisa da CLI do Azure instalada.
- Instale a extensão
aks-preview
da CLI do Azure. Versão mínima 0.5.170. - Registre o sinalizador NodeAutoProvisioningPreviewfeature.
Instalar a extensão da CLI aks-preview
Instale a extensão da CLI
aks-preview
usando o comandoaz extension add
.az extension add --name aks-preview
Atualize a extensão para garantir que você tenha a versão mais recente usando o comando
az extension update
.az extension update --name aks-preview
Registrar o sinalizador de recurso NodeAutoProvisioningPreview
Registre o sinalizador de recurso
NodeAutoProvisioningPreview
usando o comandoaz feature register
.az feature register --namespace "Microsoft.ContainerService" --name "NodeAutoProvisioningPreview"
Demora alguns minutos para o status exibir Registrado.
Verifique o status do registro usando o comando
az feature show
.az feature show --namespace "Microsoft.ContainerService" --name "NodeAutoProvisioningPreview"
Quando o status reflete Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o comando
az provider register
.az provider register --namespace Microsoft.ContainerService
Limitações
- A única configuração de rede permitida é a Sobreposição de CNI do Azure com Alimentado pelo Cilium.
- Não é possível habilitar em um cluster onde os pools de nós têm o dimensionador automático de cluster habilitado
Recursos sem suporte
- Pools de nós do Windows
- Aplicar a configuração personalizada ao nó Kubelet
- Clusters do IPv6
- Entidades de serviço
Observação
Você pode usar uma identidade gerenciada atribuída pelo sistema ou pelo usuário.
- Conjuntos de criptografia de disco
- CustomCATrustCertificates
- Modo Iniciar Parada
- Proxy HTTP
- Mutação OutboundType. Todos os OutboundTypes têm suporte, no entanto, Não é possível alterá-los após a criação.
Habilitar o provisionamento automático de nós
Habilitar o provisionamento automático de nós em um novo cluster
Habilite o provisionamento automático de nós em um novo cluster usando o comando e
az aks create
defina--node-provisioning-mode
comoAuto
. Você também precisa definir--network-plugin
paraazure
,--network-plugin-mode
paraoverlay
e--network-dataplane
paracilium
.az aks create \ --name $CLUSTER_NAME \ --resource-group $RESOURCE_GROUP_NAME \ --node-provisioning-mode Auto \ --network-plugin azure \ --network-plugin-mode overlay \ --network-dataplane cilium \ --generate-ssh-keys
Habilitar o provisionamento automático de nós em um cluster existente
Habilite o provisionamento automático de nós em um cluster existente usando o comando
az aks update
e defina--node-provisioning-mode
comoAuto
. Você também precisa definir--network-plugin
paraazure
,--network-plugin-mode
paraoverlay
e--network-dataplane
paracilium
.az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP_NAME --node-provisioning-mode Auto --network-plugin azure --network-plugin-mode overlay --network-dataplane cilium
Pools de nós
O provisionamento automático de nós usa uma lista de SKUs de VM como ponto de partida para decidir qual é a mais adequada para as cargas de trabalho que estão em um estado pendente. Ter controle sobre qual SKU você deseja no pool inicial permite especificar famílias de SKU específicas ou tipos de VM e a quantidade máxima de recursos que um provisionador usa.
Se você tiver SKUs de VM específicas que são instâncias reservadas, por exemplo, talvez você queira usar apenas essas VMs como o pool inicial.
Você pode ter várias definições de pool de nós em um cluster, mas o AKS implanta uma definição de pool de nós padrão que você pode modificar:
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
disruption:
consolidationPolicy: WhenUnderutilized
expireAfter: Never
template:
spec:
nodeClassRef:
name: default
# 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
Requisitos de provisionador de nó com suporte
Seletores da SKU com rótulos conhecidos
Seletor | Descrição | Exemplo |
---|---|---|
karpenter.azure.com/sku-family | Família da SKU da VM | D, F, L etc. |
karpenter.azure.com/sku-name | Nome da SKU explícita | Standard_A1_v2 |
karpenter.azure.com/sku-version | Versão da SKU (sem "v", pode usar 1) | 1, 2 |
karpenter.sh/capacity-type | Tipo de alocação de VM (spot/sob demanda) | spot ou sob demanda |
karpenter.azure.com/sku-cpu | Número de CPUs na VM | 16 |
karpenter.azure.com/sku-memory | Memória na VM em MiB | 131072 |
karpenter.azure.com/sku-gpu-name | Nome de GPU | A100 |
karpenter.azure.com/sku-gpu-manufacturer | Fabricante da GPU | nvidia |
karpenter.azure.com/sku-gpu-count | Quantidade de GPU por VM | 2 |
karpenter.azure.com/sku-networking-accelerated | Se a VM tem rede acelerada. | [true, false] |
karpenter.azure.com/sku-storage-premium-capable | Se a VM dá suporte ao armazenamento de E/S Premium | [true, false] |
karpenter.azure.com/sku-storage-ephemeralos-maxsize | Limite de tamanho do disco do sistema operacional efêmero em Gb | 92 |
topology.kubernetes.io/zone | As zonas de disponibilidade | [uksouth-1,uksouth-2,uksouth-3] |
kubernetes.io/os | Sistema operacional (Linux somente durante a versão prévia) | linux |
kubernetes.io/arch | Arquitetura da CPU (AMD64 ou ARM64) | [amd64, arm64] |
Para listar os recursos da SKU da VM e os valores permitidos, use o comando vm list-skus
da CLI do Azure.
az vm list-skus --resource-type virtualMachines --location <location> --query '[].name' --output table
Limites do pool de nós
Por padrão, o NAP tenta agendar suas cargas de trabalho dentro da cota do Azure que você tem disponível. Você também pode especificar o limite superior de recursos usados por um pool de nós, especificando limites dentro da especificação do pool de nós.
# Resource limits constrain the total size of the cluster.
# Limits prevent Karpenter from creating new instances once the limit is exceeded.
limits:
cpu: "1000"
memory: 1000Gi
Pesos do pool de nós
Quando você tem vários pools de nós definidos, é possível definir uma preferência de onde uma carga de trabalho deve ser agendada. Defina o peso relativo nas definições do pool de nós.
# 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
Atualizações de imagem do nó e do Kubernetes
O AKS com NAP gerencia as atualizações de versão do Kubernetes e as atualizações de disco do SO da VM para você por padrão.
Atualizações do Kubernetes
As atualizações do Kubernetes para pools de nós do NAP seguem a versão do Kubernetes do Painel de Controle. Se você executar uma atualização de cluster, os nós do NAP serão atualizados automaticamente para seguir o mesmo controle de versão.
Atualizações de imagem do nó
Por padrão, as máquinas virtuais do pool de nós do NAP são atualizadas automaticamente quando uma nova imagem está disponível. Se você quiser fixar um pool de nós em uma determinada versão de imagem de nó, poderá definir a imageVersion na classe de nó:
kubectl edit aksnodeclass default
Dentro da definição de classe do nó, defina a imageVersion como uma das versões publicadas listadas nas notas sobre a versão do AKS. Você também pode ver a disponibilidade de imagens em regiões referindo-se ao rastreador de versão do AKS
A imageVersion é a parte da data na Imagem do Nó, pois somente o Ubuntu 22.04 tem suporte, por exemplo, "AKSUbuntu-2204-202311.07.0" seria "202311.07.0"
apiVersion: karpenter.azure.com/v1alpha2
kind: AKSNodeClass
metadata:
annotations:
kubernetes.io/description: General purpose AKSNodeClass for running Ubuntu2204
nodes
meta.helm.sh/release-name: aks-managed-karpenter-overlay
meta.helm.sh/release-namespace: kube-system
creationTimestamp: "2023-11-16T23:59:06Z"
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
helm.toolkit.fluxcd.io/name: karpenter-overlay-main-adapter-helmrelease
helm.toolkit.fluxcd.io/namespace: 6556abcb92c4ce0001202e78
name: default
resourceVersion: "1792"
uid: 929a5b07-558f-4649-b78b-eb25e9b97076
spec:
imageFamily: Ubuntu2204
imageVersion: 202311.07.0
osDiskSizeGB: 128
Remover a especificação de imageVersion reverteria o pool de nós a ser atualizado para a versão mais recente da imagem do nó.
Interrupção de nó
Quando as cargas de trabalho em seus nós reduzem verticalmente, o NAP usa regras de interrupção na especificação do pool de nós para decidir quando e como remover esses nós e potencialmente reagendar suas cargas de trabalho para serem mais eficientes.
Você pode remover um nó manualmente usando kubectl delete node
, mas o NAP também pode controlar quando deve otimizar seus nós.
disruption:
# Describes which types of Nodes NAP should consider for consolidation
consolidationPolicy: WhenUnderutilized | WhenEmpty
# 'WhenUnderutilized', NAP will consider all nodes for consolidation and attempt to remove or replace Nodes when it discovers that the Node is underutilized and could be changed to reduce cost
# `WhenEmpty`, NAP will only consider nodes for consolidation that contain no workload pods
# The amount of time NAP should wait after discovering a consolidation decision
# This value can currently only be set when the consolidationPolicy is 'WhenEmpty'
# You can choose to disable consolidation entirely by setting the string value 'Never'
consolidateAfter: 30s
Monitorar eventos de seleção
O provisionamento automático de nós produz eventos de cluster que podem ser usados para monitorar as decisões de implantação e agendamento que estão sendo tomadas. Você pode exibir eventos por meio do fluxo de eventos do Kubernetes.
kubectl get events -A --field-selector source=karpenter -w
Azure Kubernetes Service