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

Azure Kubernetes Service (AKS) realiza atualizações contínuas para minimizar a perturbação das cargas de trabalho em execução.

Para a maioria das cargas de trabalho de produção, o AKS Automatic é o padrão recomendado quando aplicável. O AKS Automatic inclui valores predefinidos prontos para produção para operações de atualização, como atualizações automáticas de versões do Kubernetes, atualizações automáticas de imagens do sistema operativo (SO), operações geridas dos nós do sistema e salvaguardas incorporadas que reduzem a sobrecarga manual. Para mais informações, consulte Introdução ao AKS Automático.

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

Pré-requisitos

Modelo de atualização: AKS Automático e AKS Padrão

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

Preocupação com a atualização AKS Automático Padrão AKS
Posicionamento de produção Padrão recomendado para a maioria das cargas de trabalho de produção, quando aplicável Modelo flexível com configuração mais manual por defeito
Atualizações de versões menores do Kubernetes Canal de atualização automática pré-configurado Manual predefinido, canal automático opcional
Atualizações de imagem do sistema operativo de nós Canal de imagem do sistema operativo automático pré-configurado Manual predefinido, canal automático opcional
Operações do conjunto de nós do sistema Gerido pela AKS Gerido pelo cliente
Janelas de manutenção planeada Disponível por predefinição Configuração opcional
Controlo de perturbação da carga de trabalho Gerido pelo cliente, incluindo estratégia de replicação, comportamento de preparação e política de interrupção Gerido pelo cliente, incluindo estratégia de replicação, comportamento de preparação e política de interrupção

Note

O AKS Automatic simplifica as operações da plataforma, mas a responsabilidade partilhada continua a aplicar-se. O design de disponibilidade ao nível da carga de trabalho e o comportamento das políticas de despejo continuam a ser responsabilidades do cliente.

Comportamento de atualização contínua no AKS

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

A um nível geral, AKS:

  1. Adiciona capacidade adicional temporária com base nas definições de atualização.
  2. Cordões e drenos de nós para mover cargas de trabalho.
  3. Reimagina ou substitui nós para a versão de destino.
  4. Remove a capacidade de pico temporária após a conclusão.

Exemplo de atualização contínua

Este exemplo demonstra a atualização de um cluster de dois nós do Kubernetes 1.30 para o 1.31 com maxSurge definido para 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 aplicativos.

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

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

Passo 2: Cordão e drenagem do primeiro nó

AKS isola o Node 1 para evitar o agendamento de novos pods e, em seguida, desvazia os pods existentes.

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

  • Pod A → Removido e substituído no Surge Node
  • Pod B → Despejado e substituído no Nó 2

Etapa 3: Atualização do primeiro nó

O nó 1 é reimaginado com a versão 1.31 do Kubernetes, enquanto os pods continuam a correr noutros nós.

Diagrama que mostra o Nó 1 recriado com a versão 1.31, enquanto os pods de aplicação continuam a correr 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

Passo 4: Cordão e drenagem do segundo nó

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

Diagrama que mostra o Nó 2 a ser isolado e esvaziado, com pods expulsos e substituídos no Nó 1 atualizado e no Nó de expansão.

  • Pod C, B → Despejado e substituído no Nó 1
  • Pod D → removido e substituído no Surge Node
  • Nó 2: Isolado e reinicializado para v1.31

Etapa 5: Remover o nó de impulso

Depois de todos os nós permanentes serem atualizados, o Nó Surge é isolado, drenado e eliminado.

Diagrama que mostra o nó de sobrecapacidade a ser esvaziado e eliminado, com pods removidos e substituídos nos nós permanentes atualizados.

  • Pod A → Removido e substituído no Node 1
  • Pod D → Desalojado e substituído no Nó 2
  • Nó de sobrecarga: Excluído

Estado final

Todos os nós agora estão executando o Kubernetes versão 1.31 com pods agendados no cluster.

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

Comportamento restritivo do Pod Disruption Budget (PDB)

Se uma PDB restritiva bloquear a desocupação, a drenagem de nós pode ser atrasada ou impedida. O AKS pode usar o comportamento de nó não drenável Cordon para continuar a atualizar outros nós elegíveis, consoante o comportamento configurado. Os nodos bloqueados podem permanecer numa versão anterior até que a condição de bloqueio seja resolvida.

Exemplo restritivo de PDB

Este exemplo mostra a atualização de um cluster de dois nós da versão 1.30 para a 1.31 do Kubernetes, com maxSurge definido como 2 e um PDB a bloquear 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 da remoção.

Diagrama que mostra o cluster inicial com dois nós, um Nó de Surge e um Orçamento de Disrupção de Pods a proteger o Pod A da expulsão.

  • Nó 1: Pod A (protegido por PDB), Pod B
  • Nó 2: Pod C, Pod D
  • Nós de pico: Foram criados 2 novos nós
  • PDB: Previne o despejo do Pod A

Etapa 2: Tente esvaziar o primeiro nó (obstruído)

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

Diagrama que mostra o Nó 1 isolado, mas com a drenagem bloqueada pelo Pod Disruption Budget, com o Pod A preso e o Pod B expulso para o nó de expansão.

  • Nó 1: Isolado e marcado como em quarentena (Pod A bloqueado)
  • O Pod B → expulso e substituído no Surge Node 1, enquanto o Surge Node 2 temporariamente não é usado
  • Estado: Atualização do nó 1 bloqueada

Passo 3: Avançar para o segundo nó

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

Diagrama que mostra o Node 1 a permanecer em quarentena, enquanto o Node 2 é isolado e esvaziado com sucesso, com os pods transferidos para o node de reforço.

  • Nó 1: Permanece em quarentena (v1.30)
  • Nó 2: Isolado e drenado com sucesso
  • Pod C → Removido e substituído no Surge Node 2
  • Pod D → Removido e substituído no Surge Node 2

Etapa 4: Atualizar o segundo nó

O nó 2 foi recriado 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ó Surge 2: Pod C, Pod D

Passo 5: Um nó de expansão passa a substituição permanente enquanto outro é removido

Como o Nó 1 permanece em quarentena, o Nó Surge 1 torna-se o substituto permanente a correr a v1.31 e o Nó Surge 2 é eliminado.

Diagrama que mostra o Nó Surge a tornar-se um substituto permanente a executar a versão 1.31 enquanto o Nó 1 permanece em quarentena.

  • Nó 1: Em quarentena (v1.30) - requer 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): Eliminado

Estado final

A atualização é concluída com um nó em quarentena que requer intervenção manual.

  • Nó 1: Em quarentena (v1.30) com Pod A - O cliente deve resolver manualmente (consulte Resolver nós não drenáveis)
  • Nó 2 (v1.31): Funcionando normalmente
  • Antigo Surge Node (v1.31): Agora substituição permanente

Importante

O nó em quarentena (Nó 1) continua sendo de responsabilidade do cliente. Deve ou:

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

Principais considerações para upgrades bloqueados por PDB

  • Comportamento do nó não drenável: Defina Cordon no conjunto de nós para ativar este comportamento de quarentena.
  • Responsabilidade do cliente: Os nós em quarentena requerem intervenção manual para serem resolvidos.
  • Capacidade do cluster: O nó de pico torna-se permanente, afetando potencialmente o planeamento da capacidade do cluster.
  • Monitorização: Acompanhe os nós em quarentena através do Azure Monitor ou kubectl para garantir uma resolução atempada.

Sugestão

Para evitar completamente o cenário de quarentena, pode usar a gestão automática de PDB para escalar automaticamente as réplicas da implementação, de modo a que as restrições do PDB sejam satisfeitas antes do início da drenagem. Isto permite que a expulsão prossiga sem bloqueio, eliminando a necessidade de resolução manual da quarentena.

Blue-Green atualizações do pool de nós (controlo manual)

As atualizações Blue-Green proporcionam uma abordagem de atualização mais controlada, ao criar manualmente um conjunto completo de novos pools de nós antes de migrar as cargas de trabalho. Esta abordagem manual dá-lhe controlo total sobre o processo de atualização e tempo.

Para mais informações, veja Blue-Green atualizações do pool de nós no AKS.

Quando usar atualizações Blue-Green

As atualizações manuais Blue-Green do conjunto de nós são uma estratégia avançada para requisitos especializados, como pontos de controlo explícitos de migração, etapas de validação personalizadas ou transições rigorosamente controladas.

Use Blue-Green manual quando precisar de:

  • Fases de migração controladas pelo operador.
  • Validação personalizada e critérios de aceitação antes do commit.
  • Orquestração explícita da reversão associada a procedimentos operacionais internos.

Para a maioria das cargas de trabalho de produção, quando aplicável, o comportamento predefinido de atualização do AKS Automatic é a opção inicial preferida, e a abordagem Blue-Green manual fica normalmente reservada para casos excecionais.

Conceitos-chave

  • Pool de nós azul: O pool de nós existente com a versão atual do Kubernetes.
  • Pool de nós verdes: Novo pool de nós que crias a correr a versão alvo do Kubernetes.
  • Controlo manual: Geres todos os aspetos do processo de migração.
  • Pontos de verificação de validação: Decides quando prosseguir, pausar ou recuar.

Benefícios das atualizações Blue-Green

  • Controlo total: Decides exatamente quando ocorre cada passo.
  • Validação personalizada: Implemente os seus próprios critérios de validação e timing.
  • Migração gradual: Avance as cargas de trabalho ao ritmo que preferir.
  • Reversão simples: Os nós originais permanecem disponíveis até serem eliminados.

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

  • Esforço manual: Requer uma gestão ativa ao longo de todo o processo.
  • Requisitos de quota: Requer 2x a capacidade do nó durante a atualização.
  • Planeamento: Documente os seus critérios de validação e procedimentos de reversão.

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

Este exemplo demonstra a atualização manual de um cluster de dois nós do Kubernetes 1.30 para 1.31 usando a implantação Blue-Green.

Etapa 1: Criar pool de nós verdes

Você começa criando manualmente um novo pool de nós com a versão Kubernetes de destino ao lado do pool de nós existente.

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

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

Passo 2: Isolar manualmente os nós azuis

Isolem os nós azuis para evitar o agendamento de novos pods enquanto mantêm os pods existentes a funcionar.

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

Passo 3: Drenar manualmente os nós azuis (ritmo controlado)

Você controla o ritmo de migração, podendo esvaziar manualmente os nós, um de cada vez ou em grupos.

Diagrama que mostra o nó azul a ser esvaziado, com os pods removidos e substituídos no pool de nós verdes, e o segundo nó azul a ser esvaziado, com os pods restantes migrados para o pool de nós verdes.

  • 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 nos nós verdes antes de prosseguir

Passo 4: Validar e decidir

Após a migração das cargas de trabalho, valide o desempenho da aplicação nos nós verdes.

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

Durante essa fase, você pode:

  • Monitor: Verifique as métricas e os logs do aplicativo
  • Teste: Execute testes de validação no pool de nós verdes
  • Decidir: Adotar o verde ou voltar ao azul

Etapa 5: confirmar ou reverter

Com base na tua validação, concluis manualmente a atualização ou o restauro.

Opção A - Comprometer-se (Sucesso):

Diagrama que mostra a confirmação bem sucedida, com o conjunto de nós Azul eliminado e o conjunto de nós Verde a passar a ser o conjunto de nós principal.

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

Opção B - Reverter (Problemas detetados):

Diagrama que mostra a reversão, com as cargas de trabalho a regressarem ao conjunto de nós Blue e o conjunto de nós Green a ser eliminado.

  • A sua ação: Descordar os nós azuis usando kubectl uncordon, drenar os nós verdes usando kubectl drain, e eliminar o pool de nós verdes usando az aks nodepool delete
  • Resultado: As cargas de trabalho regressam aos nós Azuis

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

  • Configuração de pico (maxSurge): Controla o número de nós de pico criados durante as atualizações. Valores mais altos aceleram as atualizações, mas consomem mais recursos.
  • Orçamentos de interrupção de pods (PDBs): Configure estes PDBs para garantir a disponibilidade da aplicação durante o processo de atualização.
  • Atualizações do pool de nós: cada pool de nós é atualizado de forma independente. Planeie a sua estratégia de atualização em conformidade.
  • Capacidade e quota: Valide os requisitos de capacidade temporária e em regime permanente antes das janelas de atualização.
  • Monitorização e alertas: Configure a monitorização e os alertas antes de a atualização começar.

No AKS Automatic, várias opções de atualização ao nível da plataforma estão pré-configuradas para a prontidão de produção. No AKS Standard, as equipas normalmente fazem estas escolhas de forma explícita.

Conteúdo relacionado

  • Last updated on