Configurar atualizações contínuas para pools de nós do AKS (Serviço de Kubernetes do Azure)

Uma estratégia de atualização gradual atualiza os nós um de cada vez (ou alguns de cada vez), minimizando a interrupção da carga de trabalho e garantindo que o conjunto de nós permaneça disponível durante todo o processo de atualização. Este artigo explica como configurar atualizações contínuas para pools de nós do AKS, incluindo configurações de pico, tempo limite de esgotamento e tempo de espera.

Antes de começar

  • Verifique se o plano de controle já foi atualizado para a versão do Kubernetes de destino. Você não pode atualizar pools de nós para uma versão superior à do plano de controle. Para obter mais informações, consulte Atualizar o plano de controle de cluster do AKS.
  • Se você estiver usando o CLI do Azure, este artigo exigirá CLI do Azure versão 2.34.1 ou posterior. Use o az --version comando para localizar a versão. Se precisar instalar ou atualizar, consulte Instalar CLI do Azure.
  • Você precisa da Microsoft.ContainerService/managedClusters/agentPools/write permissão de função RBAC para configurar atualizações contínuas para pools de nós do AKS.

Visão geral do comportamento de atualização sem interrupção

Durante uma atualização gradual, o AKS executa as seguintes operações para cada nó no pool de nós:

  1. Adicionar nós de surto: adicione novos nós de buffer com base nas configurações de pico máximo (--max-surge) para manter a capacidade durante a atualização.
  2. Isolar e drenar nós: Isole e drene os nós antigos um de cada vez para minimizar a interrupção para os aplicativos em execução. Se você estiver usando o surto máximo, ele isola e drena tantos nós simultaneamente quanto o número especificado de nós de buffer.
  3. Aguarde o tempo de imersão (opcional): aguarde uma duração de imersão configurada antes de continuar a permitir que as cargas de trabalho se estabilizem nos novos nós antes de continuar a atualização.
  4. Refazer imagem de nós antigos: quando os nós antigos são esvaziados, suas imagens são recriadas para receber a nova versão. Os nós reestruturados tornam-se nós de buffer para o próximo conjunto de nós a serem atualizados.
  5. Repetir: O processo é repetido até que todos os nós no pool de nós sejam atualizados.
  6. Remover nós de pico: Depois que todos os nós forem atualizados, os nós de buffer restantes serão removidos, mantendo o tamanho e o equilíbrio original do pool de nós.

Definir configurações de atualização sem interrupção

Personalizar o pico de nós

Importante

  • Os picos de nós exigem uma cota de assinatura com a contagem de pico máximo solicitada para cada operação de atualização. Por exemplo, um cluster que tem cinco agrupamentos de nós, cada um com uma quantidade de quatro nós, tem um total de 20 nós. Se cada pool de nós tiver um valor máximo de aumento de 50%, a computação extra e a cota de IP de 10 nós (dois nós × cinco pools) serão necessários para concluir a atualização.
  • A configuração de pico máximo em um pool de nós é persistente. Esta configuração é utilizada em atualizações subsequentes do Kubernetes ou de versões de nós. Você pode alterar o valor do aumento súbito máximo para seus pools de nós a qualquer momento. Para pools de nós de produção, recomendamos uma configuração de pico máximo de 33%.
  • Se você estiver usando Azure CNI, valide se há IPs disponíveis na sub-rede para satisfação de requisitos ip de Azure CNI.
  • Conjuntos de Dimensionamento de Máquinas Virtuais do Microsoft Azure (VMSS) permitem um máximo de 1.000 instâncias por conjunto de dimensionamento. Se o tamanho atual de um pool de nós mais a contagem de aumento calculada exceder 1.000 instâncias, o AKS rejeitará a atualização antes de ser iniciada.

O AKS configura os upgrades para aumentarem subitamente com um nó extra por padrão. Um valor padrão de um para a configuração de pico máximo permite que o AKS minimize a interrupção da carga de trabalho, criando um nó extra antes do isolamento/desativação de aplicativos existentes para substituir um nó de versão mais antiga. Você pode personalizar o valor do aumento súbito máximo por pool de nós. Quando você aumenta o valor máximo do aumento, o processo de atualização é concluído mais rapidamente, mas você pode enfrentar mais interrupções durante o processo de atualização.

Por exemplo, um valor do aumento súbito máximo de 100% proporciona o processo de atualização mais rápido possível, mas também faz com que todos os nós no pool de nós sejam drenados simultaneamente. Talvez você queira usar um valor mais alto como este para ambientes de teste. Para pools de nós de produção, recomendamos uma configuração de pico máximo de 33%.

O AKS aceita valores inteiros e um valor percentual para o pico máximo. Por exemplo:

Tipo de valor Example Description
Integer 5 Cinco nós extras a serem gerados
Porcentagem 50% Valor de pico de metade da contagem de nós atual no pool

O aumento máximo pode ser definido como um inteiro ou uma porcentagem. Um valor percentual é arredondado para cima, para a contagem de nós mais próxima. Se o valor máximo de aumento for maior do que o número necessário de nós a serem atualizados, o número de nós a serem atualizados será usado como valor máximo de aumento.

Se o dimensionamento não for possível até o valor máximo de expansão devido por causa das limitações de cota ou capacidade, para pools de agentes com Kubernetes versão >= 1.35, o AKS tenta automaticamente uma expansão de 1 como fallback. Se o aumento de 1 for bem-sucedido, a atualização continuará com um nó de pico.

Configurar o valor máximo de surto

Defina valores máximos de aumento para pools de nós novos ou existentes usando o comando az aks nodepool add ou az aks nodepool update com o parâmetro --max-surge. Por exemplo:

# Set max surge for a new node pool
az aks nodepool add \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 33%

# Update max surge for an existing node pool 
az aks nodepool update \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 5

Personalizar nós indisponíveis

Importante

  • A indisponibilidade máxima impede a criação de nós de pico durante o processo de atualização. Em vez disso, o AKS isola n nós (o valor máximo indisponível) por vez e move os pods para outros nós no pool de agentes. Isso pode causar interrupções na carga de trabalho se os pods não puderem ser alocados.
  • A indisponibilidade máxima pode causar mais falhas devido ao não cumprimento dos Orçamentos de Interrupção de Pods (PDBs), uma vez que há menos recursos disponíveis para o agendamento de pods. Para obter mais informações, consulte Solução de Problemas para Orçamentos de Interrupção do Pod.
  • Você não pode definir o máximo indisponível em pools de nós do sistema.

O AKS também pode configurar atualizações para não usar um nó de alta disponibilidade e atualizar os nós no local. O valor máximo de indisponibilidade determina quantos nós podem ser isolados e removidos simultaneamente do conjunto de nós existente. Recomenda-se usar o valor MaxUnavailable para uma atualização in-place quando não for possível obter cota ou capacidade adicional para o aumento de escala da atualização.

O AKS aceita valores inteiros e um valor percentual para o máximo indisponível. Por exemplo:

Tipo de valor Example Description
Integer 5 Cinco nós são isolados dos nós existentes
Porcentagem 50% Metade da contagem de nós atual no pool ficará indisponível

O valor padrão de maxUnavailable é 0. Quando maxUnavailable é 0, o AKS precisa maxSurge ser maior que 0. Para obter mais detalhes, consulte a referência da API AgentPoolUpgradeSettings.

Assim como o aumento máximo, se o valor máximo indisponível for maior do que o número de nós restantes a serem atualizados na operação atual, o número de nós restantes a serem atualizados será usado para o valor máximo indisponível. Essa condição pode ocorrer, por exemplo, quando uma operação de atualização é retomada depois que apenas alguns nós no pool foram atualizados anteriormente.

Definir o valor máximo indisponível

Defina valores máximos indisponíveis para pools de nós novos ou existentes usando o az aks nodepool addaz aks nodepool update, ou o az aks nodepool upgrade comando com o --max-unavailable parâmetro. Por exemplo:

# Set max unavailable for a new node pool
az aks nodepool add \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 0 \
    --max-unavailable 5

# Update max unavailable for an existing node pool 
az aks nodepool update \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 0 \
    --max-unavailable 5

# Set max unavailable at upgrade time
az aks nodepool upgrade \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 0 \
    --max-unavailable 5

Fallback de MaxUnavailable (prévia)

Importante

As funcionalidades em versão preliminar do AKS estão disponíveis de forma optativa e por autoatendimento. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Quando maxSurge e maxUnavailable são maiores que 0, o AKS usa uma estratégia de contingência durante as atualizações:

  1. Tentativa de aumento total: O AKS primeiro tenta fazer o aumento usando o valor maxSurge configurado.
  2. Volte ao pico de 1: se o pico todo não for possível por causa das limitações de cota ou capacidade, o AKS tentará um aumento de 1 nó em vez disso (para pools de agentes com Kubernetes versão > = 1,35).
  3. Recorra à atualização local: se não conseguir obter um nó extra, o AKS recorrerá a uma atualização local usando maxUnavailable, isolando e drenando os nós existentes sem adicionar novos.

Essa abordagem de fallback garante que as atualizações possam continuar mesmo quando a capacidade é restrita, ao mesmo tempo em que prefere a abordagem menos disruptiva baseada em surto quando os recursos estão disponíveis.

A extensão aks-preview da CLI do Azure é necessária para usar o fallback de MaxUnavailable. maxSurge e maxUnavailable pode ser usado em conjunto para comportamento de fallback ou individualmente.

Definir o pico e os valores indisponíveis máximos

# Configure fallback: try surge first, fall back to in-place upgrade if capacity is unavailable
az aks nodepool add \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 33% \
    --max-unavailable 3

# Update an existing node pool with fallback configuration
az aks nodepool update \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 33% \
    --max-unavailable 3

Personalizar o tempo limite de esgotamento do nó

Você pode ter cargas de trabalho de longa duração em determinados pods que não podem ser reagendadas para outro nó durante a execução. Por exemplo, uma carga de trabalho com estado que exige muita memória e precisa ser concluída. Nesses casos, você pode configurar um tempo limite de esvaziamento de nó que o AKS respeita no fluxo de trabalho de atualização.

O valor de tempo limite de drenagem de nó padrão é de 30 minutos. Os valores de tempo limite de esvaziamento de nó podem ser, no mínimo, 5 minutos e um máximo de 24 horas.

Se o valor do tempo limite de drenagem se esgotar e os pods ainda estiverem em execução, a operação de atualização será interrompida. Qualquer operação subsequente retoma a atualização interrompida PUT.

Dica

Para pods de execução longa, você também deve configurar o terminationGracePeriodSeconds na especificação do seu pod.

Definir o valor de tempo limite de esvaziamento do nó

Defina o tempo limite de esvaziamento do nó (em minutos) para pools de nós novos ou existentes usando o comando az aks nodepool add ou az aks nodepool update com o parâmetro --drain-timeout.

# Set drain timeout for a new node pool
az aks nodepool add \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --drain-timeout 100

# Update drain timeout for an existing node pool
az aks nodepool update \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --drain-timeout 45

Personalizar o tempo de imersão do nó

Para permitir um período de espera com uma duração específica entre o esvaziamento de um nó e o processo de reinstalação da imagem e passagem para o próximo nó, você pode definir o tempo de espera (ou tempo de espera). Esse tempo de imersão oferece a oportunidade de executar outras tarefas durante o processo de atualização, como verificar a integridade do aplicativo de um painel de monitoramento.

O tempo de imersão do nó padrão é de 0 minutos. Os valores de tempo de imersão do nó podem ser, no mínimo, 0 minutos e no máximo 30 minutos. Recomendamos manter o tempo de imersão o mais curto possível. Um tempo de imersão de nó maior aumenta a duração total da atualização e atrasa a descoberta de problemas.

Definir o valor do tempo de estabilização do nó

Defina o tempo de estabilização do nó (em minutos) para pools de nós novos ou existentes usando o comando az aks nodepool add, az aks nodepool update ou az aks nodepool upgrade com o sinalizador --node-soak-duration.

# Set node soak time for a new node pool
az aks nodepool add \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --node-soak-duration 10

# Update node soak time for an existing node pool
az aks nodepool update \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 33% \
    --node-soak-duration 5

# Set node soak time when upgrading an existing node pool
az aks nodepool upgrade \
    --name <node-pool-name> \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --max-surge 33% \
    --node-soak-duration 20

Exibir eventos de atualização de nó do AKS

Exiba eventos de atualização usando o kubectl get events comando para monitorar o progresso da atualização sem interrupção.

kubectl get events --field-selector reason=Drain,reason=Surge,reason=Upgrade

Saída de exemplo durante um evento de atualização:

default  2m1s  Normal  Drain    node/aks-nodepool1-12345678-vmss000001  Draining node: [aks-nodepool1-12345678-vmss000001]
default  9m22s Normal  Surge    node/aks-nodepool1-12345678-vmss000002  Created a surge node [aks-nodepool1-12345678-vmss000002 nodepool1] for agentpool nodepool1
default  1m45s Normal  Upgrade  node/aks-nodepool1-12345678-vmss000001  Soak duration 5m0s after draining node: aks-nodepool1-12345678-vmss000001

A tabela a seguir descreve as configurações recomendadas para atualização do pool de nós para cargas de trabalho de produção:

Configurações Recomendação
Sobretensão máxima Definido como 33% para pools de nós de produção
Tempo limite de drenagem Configurar com base nos requisitos do pod com execução mais longa
Tempo de imersão Use uma curta duração (0 a 5 minutos), a menos que você precise de verificação manual
Orçamentos de interrupção de pods Configurar PDBs para cargas de trabalho críticas para controlar a remoção do pod
Ordem de atualização Atualize os pools de nós de não produção primeiro para validar a nova versão