Como as atualizações de cluster do AKS (Serviço de Kubernetes do Azure) funcionam

AKS (Serviço de Kubernetes do Azure) executa atualizações sem interrupção para minimizar a interrupção na execução de cargas de trabalho.

Para a maioria das cargas de trabalho de produção, o AKS Automatic é o padrão recomendado quando aplicável. O AKS Automatic inclui configurações padrão prontas para produção para operações de atualização, como atualizações automáticas de versão do Kubernetes, atualizações automáticas de imagem do sistema operacional (SO) do nó, operações de nó do sistema gerenciado e proteções integradas que reduzem a sobrecarga manual. Para obter mais informações, consulte Introdução ao AKS Automatic.

Este artigo explica a mecânica de atualização do AKS e destaca onde o AKS Automatic e o AKS Standard diferem.

Pré-requisitos

Modelo de atualização: AKS Automatic e AKS Standard

Os modos de cluster AKS Automatic e AKS Standard usam os mesmos fundamentos de atualização do Kubernetes, mas diferem nas configurações padrão e na responsabilidade operacional.

Preocupação com a atualização AKS Automático AKS Standard
Posicionamento de produção Configuração padrão recomendada para a maioria das cargas de trabalho de produção, quando aplicável Modelo flexível com configuração mais manual por padrão
Atualizações de versão secundária do Kubernetes Canal de atualização automática pré-configurado Manual por padrão, canal automático opcional
Atualizações de imagens do SO com nós Canal de imagem do SO do nó automático pré-configurado Manual por padrão, canal automático opcional
Operações do conjunto de nós do sistema Gerenciado pelo AKS Gerido pelo cliente
Janelas de manutenção planejada Disponível por padrão Configuração opcional
Controles de interrupção da carga de trabalho De propriedade do cliente, incluindo estratégia de réplica, comportamento de prontidão e política de interrupção De propriedade do cliente, incluindo estratégia de réplica, comportamento de prontidão e política de interrupção

Note

O AKS Simplifica automaticamente as operações da plataforma, mas a responsabilidade compartilhada ainda se aplica. O design de disponibilidade no nível da carga de trabalho e o comportamento da política de remoção permanecem responsabilidades do cliente.

Comportamento de atualização sem interrupção no AKS

O AKS atualiza os pools de nós usando um padrão contínuo que mantém a capacidade enquanto substitui ou reinstala a imagem dos nós. Esse comportamento é o mesmo em todos os modos de cluster do AKS.

Em linhas gerais, AKS:

  1. Adiciona capacidade extra temporária com base nas configurações de upgrade.
  2. Isolam e esvaziam nós para mover cargas de trabalho.
  3. Reinstala ou substitui nós para a versão de destino.
  4. Remove a capacidade temporária de pico após a conclusão.

Exemplo de atualização sem interrupção

Este exemplo demonstra como atualizar um cluster de dois nós do Kubernetes 1.30 para 1.31 com maxSurge definido como 1.

Etapa 1: Configuração inicial

O cluster começa com dois nós executando a versão 1.30, cada um hospedando pods de aplicativo.

Diagrama que mostra a configuração inicial do cluster com dois nós executando a versão 1.30, cada um deles hospedando pods de aplicação e um nó de expansão recém-criado.

  • Nó 1: Pod A, Pod B
  • Nó 2: Pod C, Pod D
  • Surge Node: vazio (exceto para DaemonSets e pods novos)

Etapa 2: Isolar e drenar o primeiro nó

O AKS isola o Nó 1 para impedir o agendamento de novos pods e depois esvazia os pods existentes.

Diagrama que mostra o Nó 1 sendo isolado e esvaziado, com pods sendo removidos e substituídos por outros nós disponíveis.

  • Pod A → Removido e substituído no nó de pico
  • Pod B → Removido e substituído no Node 2

Etapa 3: Atualizar o primeiro nó

O Nó 1 é reconfigurado com o Kubernetes versão 1.31, enquanto os pods continuam em execução nos outros nós.

Diagrama que mostra o Nó 1 reinstalado para a versão 1.31 enquanto os pods do aplicativo continuam em execução no Nó 2 e no Nó de Sobrecarga.

  • Nó 1: Atualizado para v1.31
  • Nó 2: Pod B, Pod C, Pod D
  • Nó de surto: Pod A

Etapa 4: Isolar e esvaziar o segundo nó

O AKS repete novamente o processo para o Nó 2, os pods são removidos, e o agendador os redistribui para nós disponíveis apropriados.

Diagrama que mostra o Nó 2 sendo isolado e drenado, com os pods sendo removidos e substituídos no Nó 1 atualizado e no Nó de Sobrecarga.

  • Pod C, B → Removido e substituído no Node 1
  • Pod D → Removido e substituído no Nó de Aumento
  • Nó 2: isolado e com imagem recriada para a v1.31

Etapa 5: Remover o nó de aumento

Após todos os nós permanentes serem atualizados, o Nó de Sobrecarga é isolado, drenado e excluído.

Diagrama que mostra o Nó de Sobrecarga sendo drenado e excluído, com os pods sendo removidos e substituídos nos nós permanentes atualizados.

  • Pod A → Removido e substituído no Nó 1
  • Pod D → Removido e substituído no Nó 2
  • Nó de Surge: Removido

Estado final

Todos os nós agora executam o Kubernetes versão 1.31 com pods agendados em todo o cluster.

  • Nó 1 (v1.31): Pod A, Pod C
  • Nó 2 (v1.31): Pod B, Pod D

Comportamento restritivo do Orçamento de Interrupção de Pod (PDB)

Se um PDB restritivo bloquear a remoção, a drenagem do nó pode ser atrasada ou impedida. O AKS pode usar o comportamento de nó não drenável Cordon para continuar atualizando outros nós elegíveis, dependendo do comportamento configurado. Nós bloqueados podem permanecer em uma versão mais antiga até que a condição de bloqueio seja resolvida.

Exemplo de PDB restritivo

Este exemplo mostra a atualização de um cluster de dois nós do Kubernetes 1.30 para 1.31 com maxSurge definido como 2 e um PDB bloqueando a operação de drenagem do primeiro nó.

Etapa 1: Configuração inicial com PDB restritivo

O cluster começa com dois nós executando a versão 1.30, com um PDB protegendo o Pod A contra remoção.

Diagrama que mostra o cluster inicial com dois nós, um Nó de Sobrecarga e um Orçamento de Interrupção de Pod protegendo o Pod A da remoção.

  • Nó 1: Pod A (protegido por PDB), Pod B
  • Nó 2: Pod C, Pod D
  • Nós de expansão: 2 novos nós criados
  • PDB: impede a expulsão do Pod A

Etapa 2: Tentar esvaziar o primeiro nó (bloqueado)

O AKS isola o Nó 1, mas não consegue drenar o Pod A devido às restrições do Orçamento de Interrupção de Pod.

Diagrama que mostra o Nó 1 isolado, mas a drenagem bloqueada pelo Orçamento de Interrupção de Pod, com o Pod A travado e o Pod B removido para o Nó de Sobrecarga.

  • Nó 1: isolado e marcado como em quarentena (Pod A travado)
  • Pod B → Removido e substituído no Nó de Sobrecarga 1, enquanto o Nó de Sobrecarga 2 fica temporariamente inativo.
  • Status: Atualização do Nó 1 bloqueada

Etapa 3: Prosseguir para o segundo nó

Com o Nó 1 em quarentena, o AKS continua atualizando o Nó 2.

Diagrama que mostra o Nó 1 permanecendo em quarentena enquanto o Nó 2 é isolado e drenado com sucesso, com os pods movidos para o Nó de Sobrecarga.

  • Nó 1: Permanece em quarentena (v1.30)
  • Nó 2: Isolado e esvaziado com êxito
  • Pod C → Removido e substituído no Nodo de Impulso 2
  • Pod D → Removido e substituído no Nodo de Expansão 2

Etapa 4: Atualizar o segundo nó

O Nó 2 foi reconfigurado com êxito para o Kubernetes versão 1.31.

Diagrama que mostra o Node 2 atualizado com êxito para a versão 1.31, enquanto o Node 1 permanece em quarentena com o Pod A.

  • Nó 1: Ainda em quarentena (v1.30) com o Pod A
  • Nó 2: Atualizado para v1.31
  • Nó de surto 1: Pod B
  • Nó de surto 2: Pod C, Pod D

Etapa 5: Um Nó de Sobrecarga torna-se o substituto permanente enquanto outro é removido

Como o Nó 1 permanece em quarentena, o Nó de Sobrecarga 1 torna-se o substituto permanente executando a versão 1.31 e o Nó de Sobrecarga 2 é excluído.

Diagrama que mostra o Nó de Sobrecarga tornando-se um substituto permanente executando a versão 1.31 enquanto o Nó 1 permanece em quarentena.

  • Nó 1: colocado em quarentena (v1.30) – Exige intervenção manual
  • Pod C, Pod D → Removidos do Nó de Sobrecarga 2 e substituídos no Nó 2
  • Surge Node 1 (v1.31): Pod B (agora é permanente)
  • Surge Node 2 (v1.31): Excluído

Estado final

A atualização é concluída com um nó em quarentena, exigindo a intervenção manual.

  • Nó 1: Colocado em quarentena (v1.30) com o Pod A – O cliente precisa resolvê-lo manualmente (veja Resolver nós não esvaziáveis)
  • Nó 2 (v1.31): Em execução normalmente
  • Nó de pico anterior (v1.31): Agora uma substituição permanente

Importante

O nó em quarentena (Nó 1) permanece sob a responsabilidade do cliente para resolução. Você deve escolher uma das seguintes opções:

  • Ajuste o PDB para permitir o despejo do Pod A.
  • Exclua manualmente o Pod A.
  • Exclua e recrie o nó depois de corrigir a condição de bloqueio.

Principais considerações para atualizações bloqueadas pelo PDB

  • Comportamento de nó não drenável: Defina como Cordon para o pool de nós para habilitar esse comportamento de quarentena.
  • Responsabilidade do cliente: os nós em quarentena exigem intervenção manual para serem resolvidos.
  • Capacidade do cluster: O nó de sobrecarga torna-se permanente, podendo afetar o planejamento da capacidade do cluster.
  • Monitoramento: acompanhe os nós em quarentena por meio de Azure Monitor ou kubectl para garantir a resolução oportuna.

Dica

Para evitar o cenário de quarentena, você pode usar o gerenciamento automático de PDB para aumentar automaticamente as réplicas da implantação; assim, as restrições do PDB são atendidas antes do início da drenagem. Isso permite que a remoção prossiga sem bloqueio, eliminando a necessidade de resolução manual de quarentena.

Atualizações do pool de nós Azul-Verde (controle manual)

As atualizações Blue-Green oferecem uma abordagem de atualização mais controlada ao criar manualmente um conjunto completo de novos pools de nós antes de migrar cargas de trabalho. Essa abordagem manual oferece controle total sobre o processo de atualização e o tempo.

Para obter mais informações, consulte Atualizações do pool de nós Azul-Verde no AKS.

Quando usar atualizações de Blue-Green

As atualizações manuais de pools de nós Azul-Verde são uma estratégia avançada para requisitos específicos, como pontos de verificação de migração explícitos, portões de validação personalizados ou transições rigorosamente controladas.

Use o Blue-Green manual quando precisar de:

  • Fases de migração controladas pelo operador.
  • Critérios personalizados de validação e aceitação antes da confirmação.
  • Coreografia de reversão explícita vinculada a runbooks internos.

Para a maioria das cargas de trabalho de produção, quando aplicável, o comportamento de atualização padrão automático do AKS é o ponto de partida preferencial e o Blue-Green manual normalmente é reservado para casos excepcionais.

Conceitos principais

  • Pool de nós Azul: Seu pool de nós existente executando a versão atual do Kubernetes.
  • Pool de nós verdes: novo pool de nós que você cria executando a versão do Kubernetes de destino.
  • Controle manual: você gerencia todos os aspectos do processo de migração.
  • Pontos de verificação de validação: você decide quando prosseguir, pausar ou reverter.

Benefícios das atualizações de Blue-Green

  • Controle total: você decide exatamente quando cada etapa ocorre.
  • Validação personalizada: implemente seus próprios critérios de validação e tempo.
  • Migração gradual: mova cargas de trabalho em seu ritmo preferencial.
  • Reversão fácil: os nós originais permanecem disponíveis até que você os exclua.

Principais considerações para atualizações de Blue-Green

  • Esforço manual: requer gerenciamento ativo durante todo o processo.
  • Requisitos de cota: Requer o dobro da capacidade de nós durante a atualização.
  • Planejamento: documente seus critérios de validação e procedimentos de reversão.

Exemplo de processo de atualização de Blue-Green manual

Este exemplo demonstra como atualizar manualmente um cluster de dois nós do Kubernetes 1.30 para 1.31 usando a estratégia Blue-Green.

Etapa 1: Criar um pool de nós verdes

Comece a tarefa criando manualmente um pool de nós com a versão de destino do Kubernetes, em conjunto com o pool de nós existente.

Diagrama que mostra a configuração inicial do Blue-Green, com o pool de nós Azul executando a versão 1.30 e o pool de nós Verde recém-criado executando a versão 1.31.

  • Pool de nós azul (v1.30): Pod A, Pod B, Pod C, Pod D (existente)
  • Pool de nós verde (v1.31): vazio (criado manualmente por você)
  • Sua ação: az aks nodepool add com a nova versão do Kubernetes

Etapa 2: Isolar manualmente os nós azuis

Isolar os nós azuis para impedir o agendamento de novos pods, mantendo os pods existentes em execução.

  • Sua ação: kubectl cordon em cada nó azul
  • Nós azuis: isolados, sem novos pods agendados
  • Nós verdes: Prontos para receber cargas de trabalho

Etapa 3: Drene manualmente os nós azuis (ritmo controlado)

Você controla o ritmo de migração drenando os nós manualmente, seja um de cada vez ou em lotes.

Diagrama que mostra o nó Azul sendo esvaziado com os pods removidos e substituídos no pool de nós Verde, e o segundo nó Azul sendo esvaziado com os pods restantes migrados para o pool de nós Verde.

  • Sua ação: kubectl drain em nós azuis selecionados
  • Migração de pods: os pods são reagendados automaticamente para nós verdes
  • Validação: verificar cargas de trabalho em nós verdes antes de continuar

Etapa 4: Validar e decidir

Depois de migrar cargas de trabalho, valide o desempenho do aplicativo em nós verdes.

Diagrama que mostra a fase de validação com todas as cargas de trabalho em execução no pool de nós Verde, enquanto o pool de nós Azul permanece disponível para reversão.

Durante essa fase, você pode:

  • Monitor: Verificar as métricas e os logs do aplicativo
  • Teste: executar testes de validação no pool de nós verdes
  • Decidir: Comprometer com o verde ou reverter para o azul

Etapa 5: Confirmar ou reverter

Com base na validação, você concluirá manualmente a atualização ou a reverterá.

Opção A – Confirmação (Êxito):

Diagrama que mostra o commit bem-sucedido com o pool de nós Azul excluído e o pool de nós Verde se tornando o pool de nós primário.

  • Sua ação: excluir o pool de nós azuis usando az aks nodepool delete
  • Resultado: O pool de nós verdes se torna o primário

Opção B — Reverter (Problemas detectados):

Diagrama que mostra a reversão com as cargas de trabalho retornando ao pool de nós Azul e o pool de nós Verde sendo excluído.

  • Sua ação: Desvincule os nós azuis usando kubectl uncordon, esvazie os nós verdes usando kubectl drain, e exclua o pool de nós verde usando az aks nodepool delete
  • Resultado: cargas de trabalho retornam a nós azuis

Considerações de produção para o planejamento de atualização

  • Configuração de aumento (maxSurge) : controla o número de nós de aumento criados durante as atualizações. Valores mais altos aceleram as atualizações, mas consomem mais recursos.
  • Orçamentos de interrupção de pod (PDBs): Configure os PDBs para garantir a disponibilidade do aplicativo durante o processo de atualização.
  • Atualizações de pool de nós: cada conjunto de nós é atualizado de forma independente. Planeje sua estratégia de atualização adequadamente.
  • Capacidade e cota: valide os requisitos temporários e de capacidade de estado estável antes das janelas de atualização.
  • Monitoramento e alertas: configure o monitoramento e alertas antes do início da atualização.

No AKS Automatic, várias opções de atualização no nível da plataforma são pré-configuradas para preparação de produção. No AKS Standard, as equipes normalmente fazem essas escolhas explicitamente.

Conteúdo relacionado

  • Last updated on