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

Artigo
10/31/2024

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

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

Realizar atualizações manuais

Você pode executar atualizações manuais para controlar quando o cluster atualiza para uma nova versão do Kubernetes. As 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 seja a versão mais recente disponível.

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

Configurar atualizações automáticas

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

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

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

O AKS usa o balanceamento de zona de melhor esforço em grupos de nós. Durante um surto de atualização, as zonas para os nós de aumento nos Conjuntos de Escala de Máquina Virtual 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 surto assim que 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 o aumento para um múltiplo de três nós, e os Conjuntos de Escala de Máquina Virtual equilibram seus nós entre as zonas de disponibilidade com o melhor balanceamento de zona. Com o equilíbrio da zona de melhor esforço, o conjunto de escalas tenta escalar para dentro e para fora, mantendo o equilíbrio. No entanto, se, por algum motivo, isso não for possível (por exemplo, se uma zona cair, o conjunto de escala não poderá criar uma nova VM nessa zona), o conjunto de escalas permitirá que o desequilíbrio temporário seja dimensionado com êxito para dentro ou para fora.

PVCs (declarações de volume persistentes) apoiadas pelo LRS (armazenamento redundante local) do Azure Os discos estão vinculados a uma zona específica e podem falhar na recuperação imediata se o nó de aumento não corresponder à zona do PVC. Se as zonas não corresponderem, isso pode causar tempo de inatividade em seu aplicativo quando a operação de atualização continuar a drenar nós, mas os PVs estiverem vinculados a uma zona. Para lidar com esse caso e manter a alta disponibilidade, configure um orçamento de interrupção do pod em seu aplicativo para permitir que o Kubernetes respeite seus requisitos de disponibilidade durante a operação de drenagem.

Otimizar para o comportamento do nó não drenável (Visualização)

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ó que faz com que a operação de atualização falhe, deixando os nós não drenados em um estado escalonável. Como alternativa, você pode selecionar o comportamento, que ignora os Cordon nós que não são drenados colocando-os em um estado de quarentena, rotula-os kubernetes.azure.com/upgrade-status:Quarantinede prossegue 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 defino o novo comportamento do Cordon?

Use a visualização da CLI e instale a aks-preview extensão 9.0.0b3 ou posterior.

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

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 todos os nós bloqueados. Quando há uma falha no 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 do que o Max-Surge valor.

Como faço para remover os nós bloqueados?

Primeiro, resolva o problema que está causando o dreno. O exemplo seguinte remove o APO responsável:

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

Em seguida, exclua o nó bloqueado usando o az aks nodepool delete-machines comando. Este comando é útil se você pretende reduzir a pegada 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 atinja o tamanho original pretendido. O AKS prioriza a remoção dos nós bloqueados. Este comando também restaura o status de provisionamento do 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

Otimize as atualizações para melhorar o desempenho e minimizar interrupções

A combinação de Janela de Manutenção Planejada, Max Surge, Orçamento de Interrupção do Pod, tempo limite de drenagem do nó e tempo de imersão do nó pode aumentar significativamente a probabilidade de as atualizações do nó serem concluídas com êxito até o final da janela de manutenção, ao mesmo tempo em que minimiza as interrupções.

A Janela de Manutenção Planejada permite que as equipes de serviço programem a atualização automática durante uma janela predefinida, normalmente um período de baixo tráfego, para minimizar o impacto da carga de trabalho. Recomendamos uma duração de janela de pelo menos quatro horas.
Max Surge no pool de nós permite solicitar cota extra durante o processo de atualização e limita o número de nós selecionados para atualização simultaneamente. Um aumento máximo mais alto resulta em um processo de atualização mais rápido. Não recomendamos defini-lo em 100%, pois ele atualiza todos os nós simultaneamente, o que pode causar interrupções nos aplicativos em execução. Recomendamos uma cota máxima de aumento de 33% para pools de nós de produção.
O Orçamento de Interrupção de 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 minAvailable réplicas, indicando o número mínimo de pods de aplicativo que precisam estar ativos, ou maxUnavailable réplicas, indicando o número máximo de pods de aplicativo que podem ser encerrados, garantindo alta disponibilidade para o aplicativo. Consulte as orientações fornecidas para configurar Pod Disruption Budgets (PDBs). Os valores de PDB devem ser validados para determinar as configurações que funcionam melhor para seu serviço específico.
O tempo limite de drenagem do nó no pool de nós permite configurar a duração da espera para remoção de pods e terminação normal por nó durante uma atualização. Esta opção é útil ao lidar com cargas de trabalho de longa duração. Quando o tempo limite de drenagem do nó é especificado (em minutos), o AKS respeita os orçamentos de interrupção do pod. Se não for especificado, o tempo limite padrão é de 30 minutos.
O tempo de imersão do nó ajuda a escalonar as atualizações do nó de forma controlada e pode minimizar o tempo de inatividade do aplicativo durante uma atualização. Você pode especificar um tempo de espera, de preferência o mais próximo possível de 0 minutos, para verificar a prontidão do aplicativo entre as atualizações do nó. Se não for especificado, o valor padrão será 0 minutos. O tempo de imersão do nó funciona em conjunto com as propriedades de aumento máximo e tempo limite de drenagem do nó disponíveis no pool de nós para fornecer os resultados certos em termos de velocidade de atualização e disponibilidade do aplicativo.

Próximos passos

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

Partilhar via