Partilhar via

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

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

O que este artigo abrange

Esta referência técnica fornece fundamentos abrangentes de atualização do AKS sobre:

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

Este hub é melhor para ajudá-lo 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:

Se você é novo nas 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

A sua situação Caminho recomendado
O cluster de produção precisa de uma atualização Estratégias de atualização de produção
Cargas de trabalho de banco de dados/com monitoração de estado Padrões de carga de trabalho com monitoração de estado
Atualização pela primeira vez ou cluster básico Atualização básica do cluster AKS
Vários ambientes ou frota Hub de cenários de atualização
Pools de nós ou nós do Windows Atualizações do pool de nós
Apenas pool de nós específicos Atualização do pool de nó único

Opções de atualização

Realizar 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:

Configurar atualizações automáticas

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

Considerações especiais para pools de nós que cobrem 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 nós de surto em conjuntos de escala de máquina virtual são desconhecidas com antecedência, o que pode causar temporariamente uma configuração de zona desequilibrada. O AKS exclui os nós de surto após a atualização e restaura o equilíbrio da zona original.

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

Otimize as 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 com baixas interrupções:

Configurações de atualização Como os nós extras são usados Comportamento esperado
maxSurge=5, maxUnavailable=0 5 nós de surto Cinco nós são aumentados para atualização.
maxSurge=5, maxUnavailable=0 0-4 nós de surto A atualização falha devido a nós de aumento insuficientes.
maxSurge=0, maxUnavailable=5 N/A Cinco nós existentes são drenados para atualização.

Observação

Antes de atualizar, verifique se há alterações de quebra de API e revise as notas de versão do AKS para evitar interrupções.

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

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

  • Alterações de quebra de API: Detecta APIs obsoletas.
  • Versão de atualização do Kubernetes: Garante um caminho de atualização válido.
  • Configuração do PDB: Verifica se há PDBs mal configurados (por exemplo, maxUnavailable=0).
  • Quota: Confirma quota suficiente para nodos de expansão.
  • Sub-rede: Verifica a disponibilidade de endereços IP suficientes.
  • Certificados/entidades de serviço: Deteta credenciais expiradas.

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

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

Cenário 1: Restrições de capacidade

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

Recomendações para prevenir ou resolver

Cenário 2: Falhas de drenagem de nós e PDBs

As atualizações exigem a drenagem de nós (remoção de pods). Os drenos podem falhar quando os pods demoram a ser encerrados ou quando os Pod Disruption Budgets (PDBs) bloqueiam as remoções de pods.

Exemplo de erro:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

Opção 1: Forçar atualização (ignorar PDB)

Advertência

A atualização forçada contorna as restrições do Pod Disruption Budget (PDB) e pode causar interrupção do serviço ao drenar todos os pods simultaneamente. Antes de usar essa opção, primeiro tente corrigir as configurações incorretas do PDB (revise as configurações minAvailable/maxUnavailable do PDB, verifique se há réplicas de pod adequadas, verifique se os PDBs não estão bloqueando todas as evicções).

Use somente a atualização forçada quando os PDBs impedirem atualizações críticas e não puderem ser resolvidos. Isso substituirá as proteções PDB e potencialmente causará indisponibilidade completa do serviço durante a atualização.

Prescrições: Azure CLI 2.79.0+ ou AKS API versão 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until 2023-10-01T13:00:00Z

Observação

  • O upgrade-override-until parâmetro define quando o bypass de validação termina (deve ser uma data/hora futura)
  • Se não for especificado, o padrão da janela será de 3 dias a partir da hora atual
  • O 'Z' indica o fuso horário UTC/GMT

Advertência

Quando a atualização de força está habilitada, ela tem precedência sobre todas as outras configurações de drenagem. As configurações de comportamento do nó não drenável (Opção 2) não serão aplicadas quando a atualização de força estiver ativa.

Opção 2: Manipular nós não drenáveis (respeitar PDB)

Use esta abordagem cuidadosa para preservar a integridade dos PDBs, evitando falhas de atualização.

Configure o comportamento do nó não drenável:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Opções de comportamento:

  • Horário (padrão): Exclui o nó bloqueado e aumenta a substituição
  • Cordão (recomendado): Cordons nó e rotula-lo como kubernetes.azure.com/upgrade-status=Quarantined

Máximo de nós bloqueados (visualização):

  • Especifica quantos nós que não conseguem drenar são tolerados
  • Requer que undrainable-node-behavior seja definido
  • O valor padrão é definido como maxSurge (normalmente 10%) se não for especificado.
Pré-requisitos para o máximo de nós bloqueados

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

    # Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview
Exemplo de configuração com o máximo de nós bloqueados
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

Recomendações para evitar falhas de drenagem

  • Defina maxUnavailable nos PDBs para permitir pelo menos uma expulsão de pod
  • Aumente as réplicas de pods para atender aos requisitos de orçamento de interrupção
  • Estenda o tempo limite de drenagem se as cargas de trabalho precisarem de mais tempo. (O padrão é 30 minutos.)
  • Teste PDBs em preparação, monitore eventos de atualização e use implantações azul-verde para cargas de trabalho críticas. Para obter mais informações, consulte Implantação azul-verde de clusters AKS.
Verificar nós não drenáveis

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

  • Verifique o rótulo em todos os nós bloqueados quando houver uma falha no nó de drenagem na atualização:

    kubectl get nodes --show-labels=true
Resolver nós impossíveis de drenar

  1. Suprimir o PDB responsável:

    kubectl delete pdb <pdb-name>

  2. Retire 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 em az aks. Como alternativa, podes dimensionar o pool de nós para corresponder ao número 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 a seguir, 2 é 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 as 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 (limita o paralelismo).
  • Tempos de imersão elevados (longas esperas entre atualizações de nós).
  • Falhas de drenagem (consulte Falhas de drenagem de nós).

Recomendações para prevenir ou resolver

  • Use maxSurge=33%, maxUnavailable=1 para produção.
  • Use maxSurge=50%o , maxUnavailable=2 para desenvolvimento/teste.
  • Utilize o patch de segurança do sistema operativo para aplicação rápida e direcionada de patches (evita a reconfiguração completa dos nós).
  • Habilite undrainableNodeBehavior para evitar bloqueadores de atualização.

Cenário 4: Exaustão de IP

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

Recomendações para prevenir ou resolver

  • Certifique-se de que sua sub-rede tenha IPs suficientes para todos os nós, nós de aumento 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 a /22).

  • Reduzir 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 os IPs órfãos dos balanceadores de carga e planeie o dimensionamento de sub-redes para clusters de grande escala.

Perguntas frequentes

Posso usar ferramentas de código aberto para validação?

Yes. Muitas ferramentas de código aberto integram-se bem com os processos de atualização do AKS:

  • kube-no-trouble (kubent): Verifica APIs preteridas antes de atualizações.
  • Trivy: Verificação de segurança para imagens de contêiner e configurações do Kubernetes.
  • Sonobuoy: testes de conformidade do Kubernetes e validação de cluster.
  • kube-bench: Verificações de benchmark 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 faço para validar a compatibilidade da API antes de atualizar?

Execute verificações de descontinuaçã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 Kubernetes?

O AKS oferece várias vantagens únicas:

  • Integração nativa do Azure com o Azure Traffic Manager, Azure Load Balancer e rede.
  • Azure Kubernetes Fleet Manager para atualizações coordenadas de vários clusters.
  • Correção automática de imagem de nó sem gerenciamento manual de nós.
  • Validação interna para cota, rede e credenciais.
  • Suporte do Azure para problemas relacionados à atualização.

Escolha o caminho de atualização

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

Pronto para executar?

Se tiver... Então vá para...
Ambiente de produção Estratégias de atualização de produção: padrões testados em batalha para upgrades sem tempo de inatividade
Bancos de dados ou aplicativos com monitoração de estado Padrões de carga de trabalho com monitoração de estado: padrões de atualização seguros para persistência de dados
Vários ambientes Hub de cenários de atualização: árvore de decisão para configurações complexas
Cluster básico Atualizar um cluster AKS: Atualização passo a passo do cluster

Ainda está decidindo?

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

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

Próximas tarefas

  • Revise as diretrizes de patch e atualização do AKS para obter práticas recomendadas e dicas de planejamento antes de iniciar qualquer atualização.
  • Sempre verifique se há alterações de quebra de API e valide a compatibilidade da sua 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.
  • Last updated on