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

Aplica-se a: ✔️ AKS Automatic ✔️ AKS Standard

Para a maioria das cargas de trabalho de produção, o AKS Automatic é a experiência de cluster padrão recomendada. Ele fornece configurações padrão prontas para produção nas operações de ciclo de vida de clusters e nós, incluindo comportamento de atualização gerenciada, mecanismos de proteção integrados e redução da sobrecarga operacional.

O AKS Standard permanece disponível para cenários em que você precisa de um controle manual mais profundo sobre a mecânica de atualização, as opções de rede ou o comportamento do pool de nós.

Este artigo fornece uma base técnica para atualizações do AKS abrangendo opções de atualização, cenários comuns e recomendações para o AKS Automatic e o AKS Standard.

O que este artigo aborda

Esta referência técnica aborda:

• Por que o AKS Automatic é o padrão recomendado e pronto para produção para a maioria das cargas de trabalho.
• Como o comportamento de atualização difere entre o AKS Automatic e o AKS Standard.
• Caminhos de atualização manuais versus automatizados e quando usar cada um.
• Cenários comuns de atualização com recomendações específicas.
• Técnicas de otimização para desempenho e interrupções mínimas.
• Processos de validação e verificações antes da atualização.

Para obter diretrizes relacionadas:

• Para uma visão geral do AKS Automatic e suas configurações padrão, consulte Introdução ao AKS (Serviço de Kubernetes do Azure) Automatic.
• Para obter detalhes da estratégia de atualização do AKS orientada à produção, consulte estratégias de atualização de produção do AKS.
• Para padrões de atualização da carga de trabalho com estado, consulte Padrões de atualização da carga de trabalho com estado.
• Para obter diretrizes orientadas a cenários, consulte 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.

Navegação rápida

Atualizar modelos operacionais

AKS Automático (padrão de produção recomendado)

O AKS Automatic foi projetado para operar em produção por padrão. Para atualizações, o AKS Automatic fornece:

• Conjuntos de nós gerenciados do sistema.
• Comportamento automático de atualização de cluster com padrões gerenciados pela plataforma.
• Comportamento da atualização de imagem do sistema operacional do nó com cadência concentrada na segurança.
• Verificações integradas para APIs do Kubernetes descontinuadas.
• Suporte de agendamento de manutenção planejado.

Use o AKS Automatic quando quiser minimizar a orquestração de atualização manual e manter os clusters de produção alinhados a versões com suporte com menos esforço.

AKS Standard (modelo de controle avançado)

O AKS Standard dá a você controle direto sobre sequenciamento e ajuste da atualização. Você escolhe e gerencia:

• Configuração de atualização manual ou automática.
• Atualize a seleção do canal.
• Pool de nós e comportamento de pico.
• Procedimentos operacionais em torno de janelas de manutenção e orçamentos de interrupção da carga de trabalho.

Use o AKS Standard quando seu ambiente exigir personalização que vá além dos padrões automáticos do AKS.

Opções de atualização

Executar atualizações manuais

Aplica-se principalmente ao AKS Standard ou a fluxos de trabalho operacionais especializados.

As atualizações manuais permitem controlar quando o cluster é atualizado para uma nova versão do Kubernetes. Essas atualizações são úteis para testes, distribuições em etapas e adoção de versão direcionada.

• 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

Para o AKS Standard, as atualizações automáticas ajudam a manter os clusters em versões com suporte, preservando o controle sobre a política e o agendamento. No AKS Automatic, a automação de atualização e os guardrails já fazem parte do modelo operacional padrão.

• Atualizar automaticamente um cluster do AKS
• Atualizar automaticamente vários clusters do AKS por meio do Azure Kubernetes Fleet Manager
• Use a manutenção planejada para agendar e controlar as atualizações
• Interromper automaticamente as atualizações de cluster do AKS em caso de alterações interruptivas na API (versão prévia)
• Atualizar automaticamente imagens do sistema operacional do nó de cluster do AKS
• Aplicar atualizações de segurança automaticamente aos nós do AKS 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 pools de nós. Durante um pico de atualização, as zonas dos nós surge em conjuntos de dimensionamento de máquinas virtuais são desconhecidas com antecedência, o que pode causar temporariamente uma configuração de zona desbalanceada. 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 solicitações de volume persistente que usam discos de armazenamento com redundância local do Azure são limitadas à zona e podem causar tempo de inatividade se os nós surge estiverem em uma zona diferente. Use um orçamento de interrupção de pod (PDB) para manter alta disponibilidade durante esvaziamentos.

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

Combine janela de manutenção planejada, surge máximo, PDB, tempo limite de esvaziamento de nó e tempo de espera do nó para aumentar a probabilidade de atualizações bem-sucedidas e com pouca interrupção.

AKS Automático

No AKS Automatic, o comportamento de atualização no nível da plataforma é pré-configurado. Concentre seu ajuste na resiliência da carga de trabalho e na preparação da capacidade:

• Valide orçamentos de interrupção de pod e contagens de réplicas.
• Garanta a capacidade da cota e da sub-rede para o crescimento esperado.
• Defina agendamentos de manutenção planejados alinhados a períodos de baixo tráfego.
• Monitore os eventos de atualização e a preparação crítica da carga de trabalho.

AKS Standard

No AKS Standard, ajuste os controles de atualização diretamente:

• Janela de manutenção planejada: agenda atualização automática durante períodos de baixo tráfego. Use pelo menos quatro horas.
• Surge máximo: valores mais altos aceleram as atualizações, mas podem interromper cargas de trabalho. Use 33% na produção.
• Máximo indisponível: usado quando a capacidade for limitada.
• Orçamento de interrupção do pod: definido para limitar a inatividade dos pods durante as atualizações. Validar para o seu serviço.
• Tempo limite de esvaziamento de nó: configura a duração de espera para remoção de pods. O padrão é 30 minutos.
• Tempo de espera do nó: escalona atualizações 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 PDBs mal configurados (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.
• Verificação de bloqueio de recurso gerenciado: Verifica se há bloqueios de recursos aplicados ao grupo de recursos do cluster gerenciado.

Essas verificações se aplicam ao AKS. No AKS Automatic, eles são integrados ao caminho de atualização gerenciado; no AKS Standard, eles fazem parte do fluxo de trabalho operacional.

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 surge não puderem ser provisionados. Essa situação é comum em 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 estiverem definidos muito alto para a capacidade disponível.

Orientação automática do AKS

• Mantenha as janelas de manutenção planejadas implantadas.
• Valide a cota da assinatura e a capacidade disponível da sub-rede antes dos períodos previstos de atualização.
• Mantenha o escalonamento da carga de trabalho e os orçamentos de interrupção alinhados às janelas de manutenção.

Diretrizes padrão do AKS

• Use maxUnavailable para atualizar usando nós existentes em vez de provisionar novos. Para obter mais informações, confira 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, confira Aplicar atualizações de segurança e kernel a nós 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). As drenagens podem falhar quando os pods demoram a encerrar ou quando Orçamentos de interrupção de pods (PDBs) rígidos bloqueiam as remoções de pods.

Erro de exemplo:

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

Orientação automática do AKS

• Trate o PDB e a estratégia de réplica como os principais controles de confiabilidade.
• Valide orçamentos de interrupção no preparo antes da distribuição da produção.
• Mantenha as cargas de trabalho críticas configuradas para que a remoção gradual seja bem-sucedida.

Diretrizes padrão do AKS

Opção 1: forçar a atualização, ignorar restrições do PDB

Só use a atualização forçada quando PDBs impedirem atualizações críticas e não possam ser resolvidas. Essa ação substitui as proteções do PDB e pode potencialmente causar indisponibilidade completa do serviço durante a atualização.

Requisitos: CLI do Azure 2.79.0+ ou a API do AKS 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 yyyy-mm-ddT13:00:00Z

Opção 2: Resolver nós não esvaziáveis respeitando PDBs

Use essa abordagem conservadora para respeitar os PDBs e evitar falhas de atualização.

Configurar comportamento de nós não esvaziáveis:

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:

• Agendar (padrão): exclui o nó bloqueado e cria temporariamente um nó substituto.
• Isolamento (recomendado): isola o nó e o rotula como kubernetes.azure.com/upgrade-status=Quarantined.

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

• Especifica quantos nós que falham ao esvaziar serão tolerados
• Requer undrainable-node-behavior que seja definido
• Assume como padrão o valor de maxSurge (normalmente 10%) se não for especificado
• Assim como o aumento máximo, se o valor calculado 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 em vez disso

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 máximo de nós bloqueados.

# Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview

Configuração de exemplo com nós bloqueados máximos

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

Opção 3: gerenciamento automático do PDB (versão prévia)

Use a extensão de gerenciamento automático do PDB para resolver proativamente os drenos bloqueados pelo PDB sem ignorar as proteções do PDB ou exigir a limpeza manual de nós em quarentena. O gerenciamento do PDB automático detecta quando um PDB bloqueia a remoção em um nó isolado e aumenta temporariamente as réplicas da implantação para atender ao orçamento de interrupção. Ao concluir a drenagem, ele redimensiona réplicas para a contagem original.

O gerenciamento automático de PDBs também pode criar PDBs automaticamente para implantações sem um PDB, garantindo a proteção de suas cargas de trabalho durante drenagens de atualização. Para obter detalhes sobre instalação e configuração, consulte Gerenciar Pod Disruption Budgets automaticamente durante as atualizações do AKS.

Recomendações para evitar falhas de drenagem

• Defina maxUnavailable nos PDBs para permitir pelo menos uma remoção de pod
• Aumente as réplicas de pod para atender aos requisitos de orçamento de interrupção
• Estenda o tempo limite de esvaziamento se as cargas de trabalho precisarem de mais tempo. (O padrão é 30 minutos.)
• Use o gerenciamento automático do PDB para automatizar a criação do PDB e o dimensionamento de réplicas durante operações de drenagem.
• Teste PDBs no preparo, monitore eventos de atualização e use implantações blue-green para cargas de trabalho críticas. Para mais informações, confira Implantação azul-verde de clusters do AKS.

Verificar nós não drená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 drená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> kubernetes.azure.com/upgrade-status-
   

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, você pode dimensionar o pool de nós para o mesmo número de nós que a contagem de nós atualizados. Esta ação garante que o pool de nós atinja seu 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 é 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 manter-se 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 (confira Falhas de drenagem de nós).

Orientação automática do AKS

• Mantenha os agendamentos de manutenção atualizados.
• Monitore o status do evento de atualização e o preparo da carga de trabalho.
• Resolva o bloqueio de PDB ou problemas de capacidade rapidamente para evitar atraso prolongado.

Diretrizes padrão do AKS

• 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 --undrainable-node-behavior para evitar bloqueadores de atualização.

Cenário 4: esgotamento de IP

Nós surge exigem mais IPs. Se a sub-rede estiver próxima da capacidade, o provisionamento de nós poderá falhar (por exemplo, Error: SubnetIsFull). Este cenário é comum com a Interface de Rede de Contêiner do Azure, alta maxPods ou grande número de nós.

Orientação automática do AKS

• Valide os planos de sub-rede e capacidade antes da expansão da produção.
• Monitore a utilização da rede como parte das operações de rotina.

Diretrizes padrão do AKS

• Verifique se a sub-rede tem IPs suficientes para todos os nós, nós surge 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

Devo usar o AKS Automatic ou o AKS Standard para atualizações de produção?

Para a maioria das cargas de trabalho de produção, use o AKS Automatic. Foi projetado como padrão pronto para produção, com comportamento de atualização gerenciado e proteções integradas.

Use o AKS Standard quando precisar de controle manual avançado sobre o sequenciamento de atualizações, as opções de infraestrutura ou as operações de pools de nós.

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

Sim. Muitas ferramentas de código aberto se integram bem aos processos de atualização do AKS:

• 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âmetros de segurança em relação aos padrões do Center for Internet Security.
• Polaris: validação das práticas recomendadas do Kubernetes.
• kubectl-neat: limpar manifestos do Kubernetes para validação.

Como fazer para validar a compatibilidade da API antes da atualização?

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:

• Caminhos operacionais gerenciados no AKS Automatic para menor sobrecarga de atualização.
• Integração nativa com o Gerenciador de Tráfego do Microsoft Azure, Azure Load Balancer e sistema de rede.
• Gerenciador de Frota de Kubernetes do Azure para atualizações multicluster coordenadas.
• Aplicação automática de patches de imagem de nó sem gerenciamento manual de nós.
• Validação interna de cotas, sistema de rede e credenciais.
• Suporte do Azure para problemas relacionados à atualização.

Escolha o caminho de atualização

Este artigo forneceu uma base técnica. Agora, selecione o caminho com base no cenário.

Pronto para executar?

Ainda decidindo?

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

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

Recomendações finais

• Use AKS Automatic para a maioria das cargas de trabalho de produção.
• Consulte as diretrizes sobre 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 API que podem causar interrupções e valide a compatibilidade da carga de trabalho com a versão do Kubernetes de destino.
• 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.