Compartilhar via

Opções de atualização para clusters do Serviço de Kubernetes do Azure (AKS)

  • Artigo

Este artigo aborda as diferentes opções de atualização dos clusters do AKS. Para executar uma atualização básica da versão do Kubernetes, confira Atualizar um cluster do AKS.

Para clusters do AKS que usam vários pools de nós ou nós do Windows Server, confira Atualizar um pool de nós no AKS. Para atualizar um pool de nós específico sem fazer uma atualização de cluster do Kubernetes, confira Atualizar um pool de nós específico.

Executar atualizações manuais

Você pode executar atualizações manuais para controlar quando o cluster é atualizado para uma nova versão do Kubernetes. Atualizações manuais são úteis quando você deseja testar uma nova versão do Kubernetes antes de atualizar seu cluster de produção. Você também pode usar atualizações manuais para atualizar seu cluster para uma versão específica do Kubernetes que não é a versão mais recente disponível.

Para executar atualizações manuais, confira os seguintes artigos:

Configurar atualizações automáticas

Você pode configurar atualizações automáticas para atualizar automaticamente o cluster para a versão mais recente do Kubernetes disponível. Atualizações automáticas são úteis quando você deseja garantir que o cluster esteja sempre executando a versão mais recente do Kubernetes. Você também pode usar atualizações automáticas para garantir que o cluster esteja sempre executando uma versão do Kubernetes com suporte.

Para configurar atualizações automáticas, confira os seguintes artigos:

Considerações especiais para pools de nós que abrangem várias zonas de disponibilidade

O AKS usa o balanceamento de zonas de melhor esforço em grupos de nós. Durante uma sobretensão da atualização, as zonas para os nós de sobretensão nos Conjuntos de Dimensionamento de Máquinas Virtuais são desconhecidas com antecedência, o que pode causar temporariamente uma configuração de zona desequilibrada durante uma atualização. No entanto, o AKS exclui os nós de sobretensão quando a atualização é concluída e preserva o equilíbrio da zona original. Se quiser manter suas zonas equilibradas durante as atualizações, você pode aumentar a sobretensão para um múltiplo de três nós, e os Conjuntos de Dimensionamento de Máquinas Virtuais equilibra seus nós entre as zonas de disponibilidade com o balanceamento de zona de melhor esforço. Com melhor balanceamento de zona possível, o conjunto de dimensionamento tenta reduzir e expandir mantendo o balanceamento. No entanto, se por alguma razão não for possível (por exemplo, se uma zona ficar inativa, o conjunto de dimensionamento não poderá criar uma nova VM nessa zona), o conjunto de dimensionamento permitirá o desbalanceamento temporário para expandir ou reduzir corretamente.

As declarações de volume persistente (PVCs) com suporte do armazenamento com redundância local (LRS) do Azure são associadas a uma zona específica e podem não se recuperar imediatamente se o nó de aumento não corresponder à zona de PVC. Se as zonas não corresponderem, isso poderá causar tempo de inatividade em seu aplicativo quando a operação de atualização continuar a esvaziar nós, mas as PVs estiverem associadas a uma zona. Para lidar com esse caso e manter a alta disponibilidade, configure um Orçamento de Interrupção de Pod em seu aplicativo para permitir que o Kubernetes respeite seus requisitos de disponibilidade durante a operação de esvaziamento.

Otimizar para comportamento de nó não drenável (versão prévia)

Você pode configurar o comportamento do processo de atualização para falhas de drenagem. O comportamento de atualização padrão é Schedule, que consiste em uma falha de drenagem de nó, fazendo com que a operação de atualização falhe, deixando os nós não inseridos em um estado programável. Como alternativa, você pode selecionar o comportamento Cordon, que ignora nós cuja drenagem falhou colocando-os em um estado de quarentena, rotulá-los kubernetes.azure.com/upgrade-status:Quarantinede prosseguir com a atualização dos nós restantes. Esse comportamento garante que todos os nós sejam atualizados ou colocados em quarentena. Essa abordagem permite solucionar problemas de falhas de drenagem e gerenciar normalmente os nós em quarentena.

Como definir o novo comportamento de Cordon?

Use a versão prévia da CLI e instale a extensão aks-preview 9.0.0b3 ou posterior.

Você pode usar os seguintes comandos para atualizar ou instalar a extensão aks-preview:

az extension update --name aks-preview

az extension add --name aks-preview

Atualize o comportamento do nó não drenável do pool de nós para Cordon:

az aks nodepool update --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP --max-surge 1 --undrainable-node-behavior Cordon

A saída de exemplo a seguir mostra o comportamento do nó não drenável atualizado:

"upgradeSettings": {
    "drainTimeoutInMinutes": null,
    "maxSurge": "1",
    "nodeSoakDurationInMinutes": null,
    "undrainableNodeBehavior": "Cordon"
  }

Verifique o rótulo em quaisquer nós bloqueados. Quando há uma falha de nó de drenagem na atualização usando o seguinte comando:

kubectl get nodes --show-labels=true

Os nós bloqueados não são programados para pods e marcados com o rótulo "kubernetes.azure.com/upgrade-status: Quarantined". O número máximo de nós que podem ser deixados bloqueados não pode ser maior que o valor Max-Surge.

Como remover os nós bloqueados?

Primeiro resolva o problema que causa o dreno. O exemplo a seguir remove o PDB responsável:

kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.

Em seguida, exclua o nó bloqueado usando o comando az aks nodepool delete-machines. Esse comando será útil se você pretende reduzir o volume do pool de nós removendo nós deixados para trás em versões mais antigas.

az aks nodepool delete-machines --cluster-name MyCluster --machine-names aks-nodepool1-test123-vmss000000 --name nodepool1 --resource-group TestRG

Depois de concluir esta etapa, você pode reconciliar o status do cluster executando qualquer operação de atualização sem os campos opcionais, conforme descrito aqui.

Exemplo de comando :

az aks update --resource-group TestRG --name MyCluster

Como alternativa, você pode dimensionar o pool de nós para o mesmo número de nós que a contagem de nós atualizados. Essa ação garante que o pool de nós chegue ao tamanho original pretendido. O AKS prioriza a remoção dos nós bloqueados. Esse comando também restaura o status de provisionamento de cluster para Succeeded. No exemplo dado, 2 é o número total de nós atualizados.

az aks nodepool scale --resource-group TestRG --cluster-name MyCluster --name nodepool1 --node-count 2

Otimizar atualizações para melhorar o desempenho e minimizar interrupções

A combinação de Janela de Manutenção Planejada, Pico Máximo, Orçamento de Interrupção do Pod, tempo limite de drenagem de nó e tempo de estabilização do nó pode aumentar significativamente a probabilidade de as atualizações de nós serem concluídas com sucesso até o final da janela de manutenção, ao mesmo tempo que minimiza as interrupções.

  • A janela de manutenção planejada permite que as equipes de serviço agendem a atualização automática durante uma janela predefinida, normalmente, um período de baixo tráfego, para minimizar o impacto na carga de trabalho. Recomendamos uma duração de janela de pelo menos quatro horas.
  • O Pico máximo no pool de nós permite a solicitação de cota extra durante o processo de atualização e limita o número de nós selecionados para atualização simultaneamente. Um pico máximo maior resulta em um processo de atualização mais rápido. Não recomendamos defini-lo como 100%, pois isso atualiza todos os nós simultaneamente, o que pode causar interrupções na execução de aplicativos. Recomendamos uma cota máxima de aumento de 33% para pools de nós de produção.
  • O Orçamento de Interrupção do Pod é definido para aplicativos de serviço e limita o número de pods que podem ficar inativos durante interrupções voluntárias, como atualizações de nó controladas pelo AKS. Ele pode ser configurado como réplicas minAvailable, indicando o número mínimo de pods de aplicativo que precisam estar ativos ou réplicas maxUnavailable, indicando o número máximo de pods de aplicativo que podem ser encerrados, garantindo alta disponibilidade para o aplicativo. Consulte as diretrizes fornecidas para configurar PDBs (Orçamentos de Interrupção de Pod). Os valores do PDB devem ser validados para determinar as configurações que funcionam melhor para seu serviço específico.
  • Tempo limite de drenagem de nó no pool de nós permite que você configure a duração de espera para remoção de pods e terminação normal por nó durante uma atualização. Essa opção é útil ao lidar com cargas de trabalho de execução prolongada. Quando o tempo limite de drenagem do nó é especificado (em minutos), o AKS respeita a espera dos orçamentos de interrupção do pod. Se não for especificado, o tempo limite padrão será 30 minutos.
  • O tempo de estabilização do nó ajuda a equilibrar atualizações de nó de maneira controlada e pode minimizar o tempo de inatividade do aplicativo durante uma atualização. Você pode especificar um tempo de espera, preferencialmente o mais razoavelmente próximo possível de 0 minutos, para verificar a preparação do aplicativo entre atualizações de nó. Se não for especificado, o valor padrão será 0 minutos. O tempo de estabilização do nó funciona em conjunto com as propriedades máximas de tempo limite de drenagem de nó e aumento máximo disponíveis no pool de nós para fornecer os resultados certos em termos de velocidade de atualização e disponibilidade do aplicativo.

Próximas etapas

Este artigo listou diferentes opções de atualização para clusters do AKS. Para obter uma discussão detalhada sobre as melhores práticas de atualização e outras considerações, veja Diretrizes de patch e atualização do AKS.