Gerenciar pools de nós para um cluster no Serviço Kubernetes do Azure (AKS)

No Serviço Kubernetes do Azure (AKS), nós da mesma configuração são agrupados em pools de nós. Esses pools de nós contêm as VMs subjacentes que executam seus aplicativos. Ao criar um cluster AKS, você define o número inicial de nós e seu tamanho (SKU). À medida que as demandas do aplicativo mudam, talvez seja necessário alterar as configurações nos pools de nós. Por exemplo, talvez seja necessário dimensionar o número de nós em um pool de nós ou atualizar a versão do Kubernetes de um pool de nós.

Este artigo mostra como gerenciar um ou mais pools de nós em um cluster AKS.

Antes de começar

• Consulte Criar pools de nós para um cluster no Serviço Kubernetes do Azure (AKS) para saber como criar pools de nós para seus clusters AKS.
• Você precisa da CLI do Azure versão 2.2.0 ou posterior instalada e configurada. Executar az --version para localizar a versão. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI).
• Analise as opções de armazenamento para aplicativos no Serviço Kubernetes do Azure para planejar sua configuração de armazenamento.

Limitações

As limitações a seguir se aplicam quando você cria e gerencia clusters AKS que suportam vários pools de nós:

• Consulte Cotas, restrições de tamanho de máquina virtual e disponibilidade de região no Serviço Kubernetes do Azure (AKS).
• Os pools de sistema devem conter pelo menos um nó e os pools de nós de usuário podem conter zero ou mais nós.
• Não é possível alterar o tamanho da VM de um pool de nós depois de criá-lo.
• Quando você cria vários pools de nós no momento da criação do cluster, todas as versões do Kubernetes usadas pelos pools de nós devem corresponder à versão definida para o plano de controle. Você pode fazer atualizações após o provisionamento do cluster usando operações de pool por nó.
• Não é possível executar simultaneamente operações de atualização e dimensionamento em um cluster ou pool de nós. Se você tentar executá-los ao mesmo tempo, você receberá um erro. Cada tipo de operação deve ser concluído no recurso de destino antes da próxima solicitação nesse mesmo recurso. Para obter mais informações, consulte o guia de solução de problemas.

Atualizar um pool de nós únicos

Nota

A versão da imagem do sistema operacional do pool de nós está vinculada à versão do Kubernetes do cluster. Você só recebe atualizações de imagem do sistema operacional, após uma atualização de cluster.

Neste exemplo, atualizamos o pool de nós mynodepool. Como há dois pools de nós, devemos usar o az aks nodepool upgrade comando para atualizar.

1. Verifique se há atualizações disponíveis usando o az aks get-upgrades comando.

   az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster
   

2. Atualize o pool de nós mynodepool usando o az aks nodepool upgradecomando.

   az aks nodepool upgrade \
       --resource-group myResourceGroup \
       --cluster-name myAKSCluster \
       --name mynodepool \
       --kubernetes-version KUBERNETES_VERSION \
       --no-wait
   

3. Liste o status dos pools de nós usando o az aks nodepool list comando.

   az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
   

   O exemplo de saída a seguir mostra que mynodepool está no estado de Atualização :

   [
     {
       ...
       "count": 3,
       ...
       "name": "mynodepool",
       "orchestratorVersion": "KUBERNETES_VERSION",
       ...
       "provisioningState": "Upgrading",
       ...
       "vmSize": "Standard_DS2_v2",
       ...
     },
     {
       ...
       "count": 2,
       ...
       "name": "nodepool1",
       "orchestratorVersion": "1.15.7",
       ...
       "provisioningState": "Succeeded",
       ...
       "vmSize": "Standard_DS2_v2",
       ...
     }
   ]
   

   Leva alguns minutos para atualizar os nós para a versão especificada.

Como prática recomendada, você deve atualizar todos os pools de nós em um cluster AKS para a mesma versão do Kubernetes. O comportamento padrão é az aks upgrade atualizar todos os pools de nós junto com o plano de controle para obter esse alinhamento. A capacidade de atualizar pools de nós individuais permite que você execute uma atualização contínua e programe pods entre pools de nós para manter o tempo de atividade do aplicativo dentro das restrições mencionadas acima.

Atualizar um plano de controle de cluster com vários pools de nós

Nota

O Kubernetes usa o esquema de versionamento semântico padrão. O número da versão é expresso como x.y.z, onde x é a versão principal, y é a versão secundária e z é a versão do patch. Por exemplo, na versão 1.12.6, 1 é a versão principal, 12 é a versão secundária e 6 é a versão do patch. A versão do Kubernetes do plano de controle e o pool de nós inicial são definidos durante a criação do cluster. Outros pools de nós têm sua versão do Kubernetes definida quando são adicionados ao cluster. As versões do Kubernetes podem diferir entre pools de nós e entre um pool de nós e o plano de controle.

Um cluster AKS tem dois objetos de recurso de cluster com versões do Kubernetes associadas a eles:

1. A versão do Kubernetes do plano de controle de cluster e
2. Um pool de nós com uma versão do Kubernetes.

O plano de controle mapeia para um ou vários pools de nós. O comportamento de uma operação de atualização depende de qual comando da CLI do Azure você usa.

• az aks upgrade atualiza o plano de controle e todos os pools de nós no cluster para a mesma versão do Kubernetes.
• az aks upgrade com o sinalizador atualiza apenas o --control-plane-only plano de controle de cluster e deixa todos os pools de nós inalterados.
• az aks nodepool upgrade atualiza apenas o pool de nós de destino com a versão especificada do Kubernetes.

Regras de validação para atualizações

As atualizações do Kubernetes para um plano de controle de cluster e pools de nós são validadas usando os seguintes conjuntos de regras:

• Regras para versões válidas para atualizar pools de nós:

  • A versão do pool de nós deve ter a mesma versão principal do plano de controle.
  • A versão secundária do pool de nós deve estar dentro de duas versões secundárias da versão do plano de controle.
  • A versão do pool de nós não pode ser maior do que a versão de controle major.minor.patch .

• Regras para enviar uma operação de atualização:

  • Não é possível fazer downgrade do plano de controle ou de uma versão do Kubernetes do pool de nós.
  • Se uma versão do Kubernetes do pool de nós não for especificada, o comportamento dependerá do cliente. Nos modelos do Gerenciador de Recursos, a declaração retorna à versão existente definida para o pool de nós. Se nada estiver definido, ele usa a versão do plano de controle para recorrer.
  • Não é possível enviar simultaneamente várias operações em um único plano de controle ou recurso de pool de nós. Você pode atualizar ou dimensionar um plano de controle ou um pool de nós em um determinado momento.

Dimensionar um pool de nós manualmente

À medida que a carga de trabalho do aplicativo exige alterações, talvez seja necessário dimensionar o número de nós em um pool de nós. O número de nós pode ser dimensionado para cima ou para baixo.

1. Dimensione o número de nós em um pool de nós usando o az aks node pool scale comando.

   az aks nodepool scale \
       --resource-group myResourceGroup \
       --cluster-name myAKSCluster \
       --name mynodepool \
       --node-count 5 \
       --no-wait
   

2. Liste o status dos pools de nós usando o az aks node pool list comando.

   az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
   

   O exemplo de saída a seguir mostra que mynodepool está no estado Scaling com uma nova contagem de cinco nós:

   [
     {
       ...
       "count": 5,
       ...
       "name": "mynodepool",
       "orchestratorVersion": "1.15.7",
       ...
       "provisioningState": "Scaling",
       ...
       "vmSize": "Standard_DS2_v2",
       ...
     },
     {
       ...
       "count": 2,
       ...
       "name": "nodepool1",
       "orchestratorVersion": "1.15.7",
       ...
       "provisioningState": "Succeeded",
       ...
       "vmSize": "Standard_DS2_v2",
       ...
     }
   ]
   

   Leva alguns minutos para que a operação de escala seja concluída.

Dimensionar um pool de nós específico automaticamente usando o autoscaler de cluster

O AKS oferece um recurso separado para dimensionar automaticamente pools de nós com um recurso chamado autoscaler de cluster. Você pode habilitar esse recurso com contagens de escala mínimas e máximas exclusivas por pool de nós.

Para obter mais informações, consulte Usar o autoscaler de cluster.

Associar grupos de reserva de capacidade a pools de nós

À medida que suas demandas de carga de trabalho mudam, você pode associar grupos de reserva de capacidade existentes a pools de nós para garantir a capacidade alocada para seus pools de nós.

Pré-requisitos para usar grupos de reserva de capacidade com AKS

• Use CLI versão 2.56 ou superior e API versão 2023-10-01 ou superior.

• O grupo de reserva de capacidade já deve existir e deve conter pelo menos uma reserva de capacidade, caso contrário, o pool de nós será adicionado ao cluster com um aviso e nenhum grupo de reserva de capacidade será associado. Para obter mais informações, consulte Grupos de reserva de capacidade.

• Você precisa criar uma identidade gerenciada atribuída pelo usuário para o grupo de recursos que contém o grupo de reserva de capacidade (CRG). As identidades gerenciadas atribuídas ao sistema não funcionarão para esse recurso. No exemplo a seguir, substitua as variáveis de ambiente por seus próprios valores.

  IDENTITY_NAME=myID
  RG_NAME=myResourceGroup
  CLUSTER_NAME=myAKSCluster
  VM_SKU=Standard_D4s_v3
  NODE_COUNT=2
  LOCATION=westus2
  az identity create --name $IDENTITY_NAME --resource-group $RG_NAME  
  IDENTITY_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RG_NAME --query identity.id -o tsv)
  

• Você precisa atribuir a Contributor função à identidade atribuída pelo usuário criada acima. Para obter mais detalhes, consulte Etapas para atribuir uma função do Azure.

• Crie um novo cluster e atribua a identidade recém-criada.

    az aks create --resource-group $RG_NAME --name $CLUSTER_NAME --location $LOCATION \
        --node-vm-size $VM_SKU --node-count $NODE_COUNT \
        --assign-identity $IDENTITY_ID --enable-managed-identity         
  

• Você também pode atribuir a identidade gerenciada pelo usuário em um cluster gerenciado existente com o comando update.

    az aks update --resource-group $RG_NAME --name $CLUSTER_NAME --location $LOCATION \
            --node-vm-size $VM_SKU --node-count $NODE_COUNT \
            --assign-identity $IDENTITY_ID --enable-managed-identity         
  

Associar um grupo de reserva de capacidade existente a um pool de nós

Associe um grupo de reserva de capacidade existente a um pool de nós usando o comando e especifique um grupo de reserva de capacidade com o az aks nodepool add--crg-id sinalizador. O exemplo a seguir pressupõe que você tenha um CRG chamado "myCRG".

RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
NODEPOOL_NAME=myNodepool
CRG_NAME=myCRG
CRG_ID=$(az capacity reservation group show --capacity-reservation-group $CRG_NAME --resource-group $RG_NAME --query id -o tsv)
az aks nodepool add --resource-group $RG_NAME --cluster-name $CLUSTER_NAME --name $NODEPOOL_NAME --crg-id $CRG_ID

Associar um grupo de reserva de capacidade existente a um pool de nós do sistema

Para associar um grupo de reserva de capacidade existente a um pool de nós do sistema, associe o cluster à identidade atribuída pelo usuário à função de Colaborador em seu CRG e ao próprio CRG durante a criação do cluster. Use o az aks create comando com os --assign-identity sinalizadores e --crg-id .

IDENTITY_NAME=myID
RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
NODEPOOL_NAME=myNodepool
CRG_NAME=myCRG
CRG_ID=$(az capacity reservation group show --capacity-reservation-group $CRG_NAME --resource-group $RG_NAME --query id -o tsv)
IDENTITY_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RG_NAME --query identity.id -o tsv)
az aks create --resource-group $RG_NAME --cluster-name $CLUSTER_NAME --crg-id $CRG_ID --assign-identity $IDENTITY_ID --enable-managed-identity

Nota

A exclusão de um pool de nós dissocia implicitamente esse pool de nós de qualquer grupo de reserva de capacidade associado antes que o pool de nós seja excluído. A exclusão de um cluster dissocia implicitamente todos os pools de nós desse cluster de seus grupos de reserva de capacidade associados.

Nota

Não é possível atualizar um pool de nós existente com um grupo de reserva de capacidade. A abordagem recomendada é associar um grupo de reserva de capacidade durante a criação do pool de nós.

Especificar um tamanho de VM para um pool de nós

Talvez seja necessário criar pools de nós com diferentes tamanhos e recursos de VM. Por exemplo, você pode criar um pool de nós que contenha nós com grandes quantidades de CPU ou memória ou um pool de nós que forneça suporte a GPU. Na próxima seção, você usa manchas e tolerâncias para dizer ao agendador do Kubernetes como limitar o acesso a pods que podem ser executados nesses nós.

No exemplo a seguir, criamos um pool de nós baseado em GPU que usa o tamanho Standard_NC6s_v3 VM. Estas VMs são alimentadas pela placa NVIDIA Tesla K80. Para obter informações, consulte Tamanhos disponíveis para máquinas virtuais Linux no Azure.

1. Crie um pool de nós usando o az aks node pool add comando. Especifique o nome gpunodepool e use o parâmetro para especificar o --node-vm-size tamanho do Standard_NC6.

   az aks nodepool add \
       --resource-group myResourceGroup \
       --cluster-name myAKSCluster \
       --name gpunodepool \
       --node-count 1 \
       --node-vm-size Standard_NC6s_v3 \
       --no-wait
   

2. Verifique o status do pool de nós usando o az aks nodepool list comando.

   az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
   

   A saída de exemplo a seguir mostra que o pool de nós gpunodepool está criando nós com o VmSize:

   [
     {
       ...
       "count": 1,
       ...
       "name": "gpunodepool",
       "orchestratorVersion": "1.15.7",
       ...
       "provisioningState": "Creating",
       ...
       "vmSize": "Standard_NC6s_v3",
       ...
     },
     {
       ...
       "count": 2,
       ...
       "name": "nodepool1",
       "orchestratorVersion": "1.15.7",
       ...
       "provisioningState": "Succeeded",
       ...
       "vmSize": "Standard_DS2_v2",
       ...
     }
   ]
   

   Leva alguns minutos para que o gpunodepool seja criado com êxito.

Especificar uma mancha, rótulo ou tag para um pool de nós

Ao criar um pool de nós, você pode adicionar manchas, rótulos ou tags a ele. Quando você adiciona uma mancha, rótulo ou marca, todos os nós dentro desse pool de nós também obtêm essa mancha, rótulo ou marca.

Importante

Adicionar manchas, rótulos ou tags aos nós deve ser feito para todo o pool de nós usando az aks nodepoolo . Não recomendamos o uso kubectl para aplicar manchas, rótulos ou tags a nós individuais em um pool de nós.

Definir manchas do pool de nós

1. Crie um pool de nós com uma mancha usando o az aks nodepool add comando. Especifique o nome taintnp e use o parâmetro para especificar sku=gpu:NoSchedule para o --node-taints taint.

   az aks nodepool add \
       --resource-group myResourceGroup \
       --cluster-name myAKSCluster \
       --name taintnp \
       --node-count 1 \
       --node-taints sku=gpu:NoSchedule \
       --no-wait
   

2. Verifique o status do pool de nós usando o az aks nodepool list comando.

   az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
   

   A saída de exemplo a seguir mostra que o pool de nós taintnp está criando nós com os nodeTaints especificados:

   [
     {
       ...
       "count": 1,
       ...
       "name": "taintnp",
       "orchestratorVersion": "1.15.7",
       ...
       "provisioningState": "Creating",
       ...
       "nodeTaints":  [
         "sku=gpu:NoSchedule"
       ],
       ...
     },
    ...
   ]
   

As informações de contaminação são visíveis no Kubernetes para lidar com regras de agendamento para nós. O agendador do Kubernetes pode usar manchas e tolerâncias para restringir quais cargas de trabalho podem ser executadas em nós.

• Uma mancha é aplicada a um nó que indica que apenas pods específicos podem ser programados neles.
• Uma tolerância é então aplicada a um pod que lhes permite tolerar a mancha de um nó.

Para obter mais informações sobre como usar recursos agendados avançados do Kubernetes, consulte Práticas recomendadas para recursos avançados do agendador no AKS

Definir tolerações do pool de nós

Na etapa anterior, você aplicou a coloração sku=gpu:NoSchedule ao criar seu pool de nós. O exemplo de manifesto YAML a seguir usa uma tolerância para permitir que o agendador do Kubernetes execute um pod NGINX em um nó nesse pool de nós.

1. Crie um arquivo nomeado nginx-toleration.yaml e copie no exemplo a seguir YAML.

   apiVersion: v1
   kind: Pod
   metadata:
     name: mypod
   spec:
     containers:
    - image: mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine
       name: mypod
       resources:
         requests:
           cpu: 100m
           memory: 128Mi
         limits:
           cpu: 1
           memory: 2G
     tolerations:
    - key: "sku"
       operator: "Equal"
       value: "gpu"
       effect: "NoSchedule"
   

2. Agende o pod usando o kubectl apply comando.

   kubectl apply -f nginx-toleration.yaml
   

   Leva alguns segundos para agendar o pod e puxar a imagem NGINX.

3. Verifique o status usando o kubectl describe pod comando.

   kubectl describe pod mypod
   

   A saída de exemplo condensado a seguir mostra que a tolerância sku=gpu:NoSchedule é aplicada. Na seção de eventos, o agendador atribuiu o pod ao nó aks-taintnp-28993262-vmss000000:

   [...]
   Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                    node.kubernetes.io/unreachable:NoExecute for 300s
                    sku=gpu:NoSchedule
   Events:
     Type    Reason     Age    From                Message
     ----    ------     ----   ----                -------
     Normal  Scheduled  4m48s  default-scheduler   Successfully assigned default/mypod to aks-taintnp-28993262-vmss000000
     Normal  Pulling    4m47s  kubelet             pulling image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
     Normal  Pulled     4m43s  kubelet             Successfully pulled image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
     Normal  Created    4m40s  kubelet             Created container
     Normal  Started    4m40s  kubelet             Started container
   

   Apenas pods que têm essa tolerância aplicada podem ser programados em nós em taintnp. Quaisquer outros pods são agendados no pool de nós nodepool1 . Se você criar mais pools de nós, poderá usar taints e tolerações para limitar quais pods podem ser agendados nesses recursos de nó.

Definindo rótulos de pool de nós

Para obter mais informações, consulte Usar rótulos em um cluster do Serviço Kubernetes do Azure (AKS).

Definindo tags do Azure do pool de nós

Para obter mais informações, consulte Usar marcas do Azure no Serviço Kubernetes do Azure (AKS).

Gerenciar pools de nós usando um modelo do Gerenciador de Recursos

Ao usar um modelo do Azure Resource Manager para criar e gerenciar recursos, você pode alterar as configurações em seu modelo e reimplantá-lo para atualizar recursos. Com os pools de nós AKS, não é possível atualizar o perfil inicial do pool de nós depois que o cluster AKS for criado. Esse comportamento significa que você não pode atualizar um modelo existente do Gerenciador de Recursos, fazer uma alteração nos pools de nós e reimplantar o modelo. Em vez disso, você deve criar um modelo separado do Gerenciador de Recursos que atualize os pools de nós para o cluster AKS existente.

1. Crie um modelo, como aks-agentpools.json, e cole no manifesto de exemplo a seguir. Certifique-se de editar os valores conforme necessário. Este modelo de exemplo define as seguintes configurações:

   • Atualiza o pool de nós do Linux chamado myagentpool para executar três nós.
   • Define os nós no pool de nós para executar o Kubernetes versão 1.15.7.
   • Define o tamanho do nó como Standard_DS2_v2.

   {
       "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
       "contentVersion": "1.0.0.0",
       "parameters": {
           "clusterName": {
               "type": "string",
               "metadata": {
                   "description": "The name of your existing AKS cluster."
               }
           },
           "location": {
               "type": "string",
               "metadata": {
                   "description": "The location of your existing AKS cluster."
               }
           },
           "agentPoolName": {
               "type": "string",
               "defaultValue": "myagentpool",
               "metadata": {
                   "description": "The name of the agent pool to create or update."
               }
           },
           "vnetSubnetId": {
               "type": "string",
               "defaultValue": "",
               "metadata": {
                   "description": "The Vnet subnet resource ID for your existing AKS cluster."
               }
           }
       },
       "variables": {
           "apiVersion": {
               "aks": "2020-01-01"
           },
           "agentPoolProfiles": {
               "maxPods": 30,
               "osDiskSizeGB": 0,
               "agentCount": 3,
               "agentVmSize": "Standard_DS2_v2",
               "osType": "Linux",
               "vnetSubnetId": "[parameters('vnetSubnetId')]"
           }
       },
       "resources": [
           {
               "apiVersion": "2020-01-01",
               "type": "Microsoft.ContainerService/managedClusters/agentPools",
               "name": "[concat(parameters('clusterName'),'/', parameters('agentPoolName'))]",
               "location": "[parameters('location')]",
               "properties": {
                   "maxPods": "[variables('agentPoolProfiles').maxPods]",
                   "osDiskSizeGB": "[variables('agentPoolProfiles').osDiskSizeGB]",
                   "count": "[variables('agentPoolProfiles').agentCount]",
                   "vmSize": "[variables('agentPoolProfiles').agentVmSize]",
                   "osType": "[variables('agentPoolProfiles').osType]",
                   "type": "VirtualMachineScaleSets",
                   "vnetSubnetID": "[variables('agentPoolProfiles').vnetSubnetId]",
                   "orchestratorVersion": "1.15.7"
               }
           }
       ]
   }
   

2. Implante o modelo usando o az deployment group create comando.

   az deployment group create \
       --resource-group myResourceGroup \
       --template-file aks-agentpools.json
   

   Gorjeta

   Você pode adicionar uma tag ao seu pool de nós adicionando a propriedade tag no modelo, conforme mostrado no exemplo a seguir:

   ...
   "resources": [
   {
     ...
     "properties": {
       ...
       "tags": {
         "name1": "val1"
       },
       ...
     }
   }
   ...
   

   Pode levar alguns minutos para atualizar seu cluster AKS, dependendo das configurações do pool de nós e das operações definidas no modelo do Gerenciador de Recursos.

Próximos passos

• Para obter mais informações sobre como controlar pods em pools de nós, consulte Práticas recomendadas para recursos avançados do agendador no AKS.
• Use grupos de posicionamento de proximidade para reduzir a latência de seus aplicativos AKS.
• Use endereços IP públicos no nível da instância para permitir que seus nós sirvam diretamente o tráfego.