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

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. Disponibiliza configurações predefinidas prontas para produção para operações do ciclo de vida do cluster e dos nós, incluindo comportamento de atualização gerida, salvaguardas incorporadas e redução da sobrecarga operacional.

O AKS Standard continua disponível para cenários em que é necessário um maior controlo manual sobre os mecanismos de atualização, as opções de configuração de rede ou o comportamento do conjunto de nós.

Este artigo dá-lhe uma base técnica para as atualizações do AKS, abordando opções de atualização, cenários comuns e recomendações tanto para o AKS Automatic como para o AKS Standard.

O que este artigo abrange

Esta referência técnica cobre:

  • Porque é que o AKS Automatic é a opção predefinida recomendada e pronta para produção para a maioria das cargas de trabalho.
  • Como o comportamento das atualizações difere entre o AKS Automático e o AKS Standard.
  • Caminhos de atualização manuais versus automáticos, e quando usar cada um.
  • Cenários de atualização comuns com recomendações específicas.
  • Técnicas de otimização para desempenho e interrupção mínima.
  • Processos de validação e verificações de pré-atualização.

Para orientações relacionadas:

Navegação rápida

A sua situação Caminho recomendado
Carga de trabalho de produção nova ou existente sem requisitos especiais de personalização Criar um cluster automático AKS
Cluster de produção com controlos personalizados rigorosos de atualização Estratégias de atualização de produção
Base de dados ou cargas de trabalho com estado persistente Padrões de carga de trabalho com monitoração de estado
Primeira atualização AKS Standard Atualização básica do cluster AKS
Múltiplos ambientes ou operações de frota Hub de cenários de atualização
Conjuntos de nós ou nós Windows no AKS Standard Atualizações do pool de nós
Apenas grupo de nós específico Atualização do pool de único nó

Atualizar modelos operacionais

O AKS Automatic foi concebido para utilização em produção, por predefinição. Para melhorias, o AKS Automatic oferece:

  • Gestão de pools de nós do sistema.
  • Comportamento da atualização automática do cluster com predefinições geridas pela plataforma.
  • Comportamento automático de atualização de imagem do sistema operativo de nós com cadência focada na segurança.
  • Verificações integradas para APIs Kubernetes obsoletas.
  • Apoio ao cronograma de manutenção planeada.

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

Padrão AKS (modelo de controlo avançado)

O AKS Standard dá-te controlo direto sobre a sequência e afinação das atualizações. Escolhe e gere:

  • Configuração de atualização manual ou automática.
  • Atualizar a seleção do canal.
  • Pool de nós e comportamento de surto.
  • Procedimentos operacionais relacionados com janelas de manutenção e orçamentos de interrupção de carga de trabalho.

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

Opções de atualização

Realizar 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. Estas atualizações são úteis para testes, implementações faseadas e adoção direcionada de versões.

Configurar atualizações automáticas

No AKS Standard, as atualizações automáticas ajudam a manter clusters nas versões suportadas, preservando o controlo sobre políticas e agendamentos. No AKS Automatic, a automação de atualizações e os guarda-corpos já fazem parte do modelo operacional padrão.

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

O AKS utiliza o balanceamento de zonas de melhor esforço em pools 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. Os pedidos de volume persistente que utilizam discos de armazenamento redundantes localmente do Azure estão restritos a uma zona e podem causar tempo de paragem se os nós de armazenamento estiverem numa zona diferente. Utilize um orçamento de interrupção de pod (PDB) para manter alta disponibilidade durante manutenções.

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

Combine janela de manutenção planeada, pico máximo, PDB, tempo de esgotamento do nó e tempo de absorção do nó para aumentar a probabilidade de atualizações bem-sucedidas e com baixa interrupção.

AKS Automático

No AKS Automatic, o comportamento de atualização ao nível da plataforma está pré-configurado. Concentre-se na otimização da resiliência da carga de trabalho e na preparação da capacidade:

  • Valide os orçamentos para interrupções de pods e o número de réplicas.
  • Garanta capacidade suficiente das quotas e das sub-redes para o crescimento esperado.
  • Definir calendários de manutenção planeados alinhados a períodos de baixo tráfego.
  • Monitorize os eventos de atualização e a prontidão das cargas de trabalho críticas.

Padrão AKS

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

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 expansão insuficientes.
maxSurge=0, maxUnavailable=5 N/A Cinco nós existentes estão a ser drenados para a 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.
  • Verificação de Bloqueio de Recursos Geridos: Verificações de bloqueios de recursos aplicados ao grupo de recursos do cluster gerido.

Estas verificações aplicam-se em todo o AKS. No AKS Automatic, estão integrados no caminho de atualização gerido; no AKS Standard, fazem parte do teu 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 pela camada de produto ou capacidade regional, as atualizações poderão falhar caso os nós de pico não possam 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.

Orientação automática AKS

  • Mantenha as janelas de manutenção programadas.
  • Verifique a quota da subscrição e a margem disponível na sub-rede antes dos períodos de atualização esperados.
  • Mantenha os orçamentos de escalabilidade da carga de trabalho e de interrupção alinhados com as janelas de manutenção.

Orientação padrão AKS

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.

Orientação automática AKS

  • Trate o PDB e a estratégia de réplica como os principais controlos de fiabilidade.
  • Validar orçamentos de disrupção na preparação antes do lançamento da produção.
  • Mantenha as cargas de trabalho críticas configuradas para o sucesso contínuo das expulsões.

Orientação padrão AKS

Opção 1: Forçar a atualização, contornar as restrições do 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 esvaziar 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).

Utilize a atualização forçada apenas quando os PDBs impedirem atualizações críticas e não puderem ser resolvidos. Esta ação sobrepõe-se às proteções do PDB e pode potencialmente causar total indisponibilidade de serviço durante a atualização.

Requisitos: CLI do Azure 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 yyyy-mm-ddT13: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, a janela é, por predefinição, de três dias a contar da hora atual.
  • Indica Z 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 definições de comportamento do nó não drenável (Opção 2) não são aplicadas quando a atualização forçada está ativa.

Opção 2: Lidar com nós não drenáveis enquanto se respeita os PDBs

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

Configurar o comportamento dos nós não drená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:

  • Schedule (predefinido): Elimina o nó bloqueado e aumenta a substituição.
  • Cordon (recomendado): Cordons node e rotula-o como kubernetes.azure.com/upgrade-status=Quarantined.

Máximo de nós bloqueados (pré-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.
  • Tal como no pico máximo, se o valor calculado for superior ao número de nós restantes para atualizar na operação atual, utiliza-se o número de nós que ainda precisam de ser atualizados
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
Opção 3: Gestão automática de PDB (pré-visualização)

Use a extensão automática de gestão do PDB para resolver proativamente os drenos bloqueados por PDB sem contornar as proteções do PDB ou exigir a limpeza manual dos nós em quarentena. A gestão automática do PDB deteta quando um PDB bloqueia a expulsão num nó isolado e escala temporariamente as réplicas da implementação para que o orçamento de perturbação seja satisfeito. Após a conclusão do esvaziamento, as réplicas voltam ao seu número original.

A gestão automática de PDBs também pode criar automaticamente PDBs para implementações que não têm, garantindo que as suas cargas de trabalho estão protegidas durante os drenos de atualização. Para detalhes de instalação e configuração, consulte Gerir automaticamente os Orçamentos de Interrupção de Pods durante as atualizações do AKS.

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
  • Prolongue o tempo limite de drenagem se as tarefas de trabalho precisarem de mais tempo. (O padrão é 30 minutos.)
  • Utilize a gestão automática de PDB para automatizar a criação de PDB e a escalabilidade de réplicas durante as operações de drenagem.
  • 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> 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 este passo, pode reconciliar o estado do cluster realizando 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. Esta ação assegura que o pool de nós retorne ao seu 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).

Orientação automática AKS

  • Mantenha os planos de manutenção atualizados.
  • Monitorize o estado do evento de atualização e a preparação da carga de trabalho.
  • Resolva rapidamente problemas de PDB ou de capacidade que causam bloqueios para evitar lentidão prolongada.

Orientação padrão AKS

  • Use maxSurge=33%, maxUnavailable=1 para produção.
  • Use maxSurge=50%, maxUnavailable=2 para dev/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 --undrainable-node-behavior 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.

Orientação automática AKS

  • Validar planos de sub-redes e capacidade antes da expansão da produção.
  • Monitorizar a utilização da rede como parte das operações rotineiras.

Orientação padrão AKS

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

  • Reduza maxSurge se não for possível expandir a sub-rede.

    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

Devo usar o AKS Automático ou o AKS Standard para upgrades de produção?

Para a maioria das cargas de produção, usa o AKS Automatic. Foi concebido como a predefinição pronta para produção, com comportamento de atualização gerido e mecanismos de proteção integrados.

Utilize o AKS Standard quando precisar de controlo manual avançado sobre a sequência de atualizações, as opções de infraestrutura ou as operações do conjunto de nós.

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:

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

  • Percursos operacionais geridos no AKS Automatic para reduzir a sobrecarga das atualizações.
  • Integração nativa do Azure com o Gestor de Tráfego do Azure, Balanceador de Carga do Azure e rede.
  • Azure Kubernetes Fleet Manager para atualizações coordenadas de vários clusters.
  • Atualização automática de imagens de nós sem gestão manual de nós.
  • Validação integrada para cotas, 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... Em seguida, aceda a...
Carga de trabalho de produção e sem restrições especiais de personalização Criar um cluster automático AKS
Ambiente de produção com necessidades avançadas de atualização personalizada Estratégias de atualização de produção
Bancos de dados ou aplicativos com estado Padrões de carga de trabalho com monitoração de estado
Vários ambientes Hub de cenários de atualização
Cluster básico AKS Standard Atualizar um cluster AKS

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

Recomendações finais

  • Usa o AKS Automatic para a maioria das cargas de trabalho de produção.
  • 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