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

Este artigo fornece uma base técnica para atualizações de cluster do AKS (Serviço de Kubernetes do Azure) abrangendo opções de atualização e cenários comuns. Para obter diretrizes detalhadas adaptadas às suas necessidades, use os caminhos de navegação baseados em cenários no final deste artigo.

O que este artigo aborda

Essa referência técnica fornece conceitos básicos abrangentes de atualização do AKS sobre:

• Opções de atualização manual versus automatizada e quando usar cada uma.
• Cenários comuns de atualização com recomendações específicas.
• Técnicas de otimização para desempenho e interrupção mínima.
• Diretrizes de solução de problemas de capacidade, falhas de drenagem e tempo.
• Processos de validação e verificações de pré-atualização.

Esse hub é melhor para ajudar você a entender a mecânica de atualização, solucionar problemas, otimizar as configurações de atualização e aprender sobre a implementação técnica.

Para obter mais informações, consulte estes artigos relacionados:

• Para atualizar seus clusters aks de produção, consulte estratégias de atualização de produção do AKS.
• Para obter padrões de atualização para clusters AKS com cargas de trabalho com estado, consulte padrões de atualização de carga de trabalho com estado.
• Para usar o hub de cenários para ajudá-lo a escolher a abordagem de atualização correta do AKS, consulte os cenários de atualização do AKS: Escolha seu caminho.

Se você não estiver familiarizado com as atualizações do AKS, comece com o hub de cenários de atualização para obter assistência guiada e baseada em cenários.

Navegação rápida

Opções de atualização

Executar atualizações manuais

As atualizações manuais permitem controlar quando o cluster é atualizado para uma nova versão do Kubernetes. Essas atualizações são úteis para testar ou direcionar uma versão específica:

• Atualizar um cluster do AKS
• Upgrade de vários clusters do AKS por meio do Gerenciador de Frota de Kubernetes do Azure
• Atualizar a imagem do nó
• Personalizar a atualização de pico de nó
• Atualizações do sistema operacional do nó de processo

Configurar atualizações automáticas

As atualizações automáticas mantêm o cluster em uma versão com suporte e atualizada. Use estas atualizações quando quiser automatizar suas configurações:

• Atualizar automaticamente um cluster do AKS
• Atualizar automaticamente vários clusters do AKS por meio do Azure Kubernetes Fleet Manager
• Usar a manutenção planejada para agendar e controlar atualizações
• Parar atualizações de cluster do AKS automaticamente em alterações interruptivas da API (versão prévia)
• Atualizar automaticamente imagens do sistema operacional do nó de cluster do AKS
• Aplicar atualizações de segurança a nós do AKS automaticamente usando ações do GitHub

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 um aumento de atualização, as zonas para nós de aumento em conjuntos de dimensionamento de máquinas virtuais são desconhecidas com antecedência, o que pode causar temporariamente uma configuração de zona desequilibrada. O AKS exclui nós de aumento após a atualização e restaura o balanceamento de zona original.

Para manter as zonas balanceadas, defina o aumento para um múltiplo de três nós. As declarações de volume persistente que usam discos de armazenamento com redundância local do Azure são associadas à zona e podem causar tempo de inatividade se os nós de aumento estiverem em uma zona diferente. Use um PDB (orçamento de interrupção de pod) para manter a alta disponibilidade durante os drenos.

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

Combine a janela de manutenção planejada, o aumento máximo, o PDB, o tempo limite de drenagem do nó e o tempo de imersão do nó para aumentar a probabilidade de atualizações bem-sucedidas e de baixa interrupção:

• Janela de manutenção planejada: agendar a atualização automática durante períodos de baixo tráfego. Recomendamos pelo menos quatro horas.
• Aumento máximo: os valores mais altos aceleram atualizações, mas podem interromper cargas de trabalho. Recomendamos 33% para produção.
• Máximo indisponível: use quando a capacidade for limitada.
• Orçamento de interrupção do pod: definido para limitar os pods para baixo durante as atualizações. Valide para seu serviço.
• Tempo limite de drenagem do nó: configurar a duração da espera de remoção do pod. O padrão é 30 minutos.
• Tempo de imersão do nó: atualizações escalonadas para minimizar o tempo de inatividade. O padrão é 0 minuto.

Validações usadas no processo de atualização

O AKS executa validações de pré-atualização para garantir a integridade do cluster:

• Alterações significativas na API: detecta APIs preteridas.
• Versão de atualização do Kubernetes: Garante um caminho de atualização válido.
• Configuração do PDB: Verifica se há PDBs configurados incorretamente (por exemplo, maxUnavailable=0).
• Cota: confirma se há cota suficiente para nós em surto.
• Sub-rede: verifica se há endereços IP suficientes.
• Certificados/entidades de serviço: Detecta credenciais expiradas.

Essas verificações ajudam a minimizar falhas de atualização e fornecem visibilidade antecipada sobre problemas.

Cenários e recomendações comuns de atualização

Cenário 1: Restrições de capacidade

Se o cluster for limitado por camada de produto ou capacidade regional, as atualizações poderão falhar quando nós de aumento não puderem ser provisionados. Essa situação é comum com camadas de produtos especializados (como nós de GPU) ou em regiões com recursos limitados. Erros como SKUNotAvailable, AllocationFailedou OverconstrainedAllocationRequest podem ocorrer se maxSurge estiverem definidos muito alto para a capacidade disponível.

Recomendações para impedir ou resolver

• Use maxUnavailable para atualizar usando nós existentes em vez de criar novos. Para obter mais informações, consulte Personalizar nós indisponíveis durante a atualização.
• Abaixe maxSurge para reduzir as necessidades de capacidade extra. Para saber mais, confira Personalizar a atualização de sobretensão de nó.
• Para atualizações de segurança, use reimplantações com nova imagem de patch de segurança que não exigem nós em surto. Para obter mais informações, consulte Aplicar atualizações de segurança e kernel a nós do Linux no Serviço de Kubernetes do Azure.

Cenário 2: falhas de esvaziamento de nós e PDBs

As atualizações exigem esvaziamento de nós (remoção de pods). Os drenos poderão falhar se:

• Pods demoram a terminar (ganchos de desligamento longos ou conexões persistentes).
• PDBs estritos bloqueiam remoções de pod.

Exemplo de mensagem de erro:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... failed with Too Many Requests error. This error is often caused by a restrictive PDB policy. See https://aka.ms/aks/debugdrainfailures. Original error: Cannot evict pod as it would violate the pod's disruption budget. PDB debug info: ... blocked by pdb ... with 0 unready pods.

Recomendações para impedir ou resolver

• Defina maxUnavailable nos PDBs para permitir que pelo menos um pod seja removido.
• Aumente as réplicas de pod para que o orçamento de interrupção possa tolerar remoções.
• Use undrainableNodeBehavior para permitir que as atualizações prossigam mesmo que alguns nós não possam ser esvaziados:
  • Agendamento (padrão): Exclua o nó e a substituição de surto para reduzir a capacidade.
  • Cordão (recomendado): O nó é isolado e rotulado como kubernetes.azure.com/upgrade-status=Quarantined.

    • Exemplo de comando:

      az aks nodepool update \
        --resource-group <resource-group-name> \
        --cluster-name <cluster-name> \
        --name <node-pool-name> \
        --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"
      }
      

Máximo de nós bloqueados permitidos (versão prévia)

O recurso Máximo de Nós Bloqueados Permitidos (versão prévia) permite especificar quantos nós que não conseguem drenar (nós bloqueados) são tolerados durante atualizações ou operações semelhantes. Esse recurso só funcionará se a propriedade de comportamento do nó não indisponível estiver definida. Caso contrário, o comando retornará um erro.

Pré-requisitos

• A extensão da CLI aks-preview do Azure versão 18.0.0b9 ou posterior é necessária para usar esse recurso.

  Exemplo de comando:

  az aks nodepool update \
    --cluster-name jizenMC1 \
    --name nodepool1 \
    --resource-group jizenTestMaxBlockedNodesRG \
    --max-surge 1 \
    --undrainable-node-behavior Cordon \
    --max-blocked-nodes 2 \
    --drain-timeout 5
  

• Estenda o tempo limite de drenagem se as cargas de trabalho precisarem de mais tempo. (O padrão é 30 minutos.)
• Teste PDBs no preparo, monitore eventos de atualização e use implantações blue-green para cargas de trabalho críticas. Para obter mais informações, consulte a implantação azul-verde de clusters AKS.

Verificar nós não indeseráveis

• Os nós bloqueados não são agendados para pods e marcados com o rótulo "kubernetes.azure.com/upgrade-status: Quarantined".

• Verifique o rótulo de quaisquer nós bloqueados quando houver falha de esvaziamento de nós na atualização:

  kubectl get nodes --show-labels=true
  

Resolver nós não indeseráveis

1. Remova o PDB responsável:

   kubectl delete pdb <pdb-name>
   

2. Remova o kubernetes.azure.com/upgrade-status: Quarantined rótulo:

   kubectl label nodes <node-name> <label-name>
   

3. Opcionalmente, exclua o nó bloqueado:

   az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>
   

4. 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 no az aks. 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 a seguir, 2 está o número total de nós atualizados.

   # Update the cluster to restore the provisioning status
   az aks update --resource-group <resource-group-name> --name <cluster-name>
   
   # Scale the node pool to restore the original size
   az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2
   

Cenário 3: atualizações lentas

Configurações conservadoras ou problemas no nível do nó podem atrasar atualizações, o que afeta sua capacidade de se manter atualizado com patches e melhorias.

As causas comuns de atualizações lentas incluem:

• Valores baixos maxSurge ou maxUnavailable limitam o paralelismo.
• Altos períodos de imersão (longas esperas entre atualizações de nós).
• Falhas de drenagem (consulte falhas de drenagem de nó).

Recomendações para impedir ou resolver

• Use maxSurge=33%, maxUnavailable=1 para produção.
• Use maxSurge=50%, maxUnavailable=2 para desenvolvimento/teste.
• Use o Patch de Segurança do SO para uma aplicação de patch rápida e direcionada (evita a reimplantação com nova imagem completa do nó).
• Habilite undrainableNodeBehavior para evitar bloqueadores de atualização.

Cenário 4: esgotamento de IP

Os nós de aumento exigem mais IPs. Se a sub-rede estiver perto da capacidade, o provisionamento de nós poderá falhar (por exemplo, Error: SubnetIsFull). Esse cenário é comum com a Interface de Rede de Contêiner do Azure, contagens altas maxPodsou grandes de nós.

Recomendações para impedir ou resolver

• Verifique se sua sub-rede tem IPs suficientes para todos os nós, nós de surto e pods. A fórmula é Total IPs = (Number of nodes + maxSurge) * (1 + maxPods).

• Recupere IPs não utilizados ou expanda a sub-rede (por exemplo, de /24 para /22).

• Reduza maxSurge se a expansão da sub-rede não for possível:

  az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --max-surge 10%
  

• Monitore o uso de IP com o Azure Monitor ou alertas personalizados.

• Reduza maxPods por nó, limpe IPs de balanceador de carga órfãos e planeje o dimensionamento da sub-rede para clusters de alta escala.

Perguntas frequentes

Posso usar ferramentas de software livre para validação?

Sim. Muitas ferramentas de software livre integram-se bem aos processos de atualização do AKS:

• kube-no-trouble (kubent): verifica se há APIs preteridas antes das atualizações.
• Trivy: Verificação de segurança para imagens de contêiner e configurações do Kubernetes.
• Sonobuoy: teste de conformidade do Kubernetes e validação de cluster.
• kube-bench: Verificações de parâmetro de comparação de segurança em relação aos padrões do Center for Internet Security.
• Polaris: validação das melhores práticas do Kubernetes.
• kubectl-neat: limpe os manifestos do Kubernetes para validação.

Como fazer para validar a compatibilidade da API antes de atualizar?

Execute verificações de substituição usando ferramentas como kubent:

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

O que torna as atualizações do AKS diferentes de outras plataformas do Kubernetes?

O AKS oferece várias vantagens exclusivas:

• Integração nativa do Azure ao Gerenciador de Tráfego do Azure, ao Azure Load Balancer e à rede.
• Gerenciador de Frotas do Kubernetes do Azure para atualizações multicluster coordenadas.
• Aplicação automática de patch de imagem de nó sem gerenciamento manual de nó.
• Validação interna para cota, rede e credenciais.
• Suporte do Azure para problemas relacionados à atualização.

Escolha seu caminho de atualização

Este artigo forneceu uma base técnica. Agora, selecione seu caminho baseado em cenário.

Pronto para execução?

Ainda decidindo?

Use o hub de cenários de atualização para uma árvore de decisão guiada que considere seu:

• Tolerância ao tempo de inatividade
• Complexidade do ambiente
• Perfil de risco
• Restrições de linha do tempo

Próximas tarefas

• Examine as diretrizes de patch e atualização do AKS para obter as melhores práticas e dicas de planejamento antes de iniciar qualquer atualização.
• Sempre verifique se há alterações significativas na API e valide a compatibilidade da carga de trabalho com a versão de destino do Kubernetes.
• Teste as configurações de atualização (como maxSurge, maxUnavailable, e PDBs) em um ambiente de teste para minimizar o risco de produção.
• Monitore os eventos de atualização e a integridade do cluster durante todo o processo.