Estratégias de upgrade de nós

Autopilot Padrão

Nesta página, discutiremos as estratégias de upgrade de nós que podem ser usadas com seus clusters do Google Kubernetes Engine (GKE).

Nos clusters do GKE Standard, é possível configurar uma das seguintes estratégias de upgrade de nós para cada pool de nós:

Upgrades súbitos: os nós são atualizados em uma janela contínua. É possível controlar quantos nós podem ser atualizados de uma só vez e como os upgrades causam interrupções nas cargas de trabalho.
Upgrades azul-verde: os nós atuais são mantidos disponíveis para reversão enquanto as cargas de trabalho são validadas na nova configuração de nós.

Nos clusters do Autopilot, o GKE usa upgrades súbitos. Para saber mais, consulte a seção Upgrades súbitos da página de upgrades de clusters do Autopilot.

Ao escolher uma estratégia de upgrade para o pool de nós do cluster do Standard, é possível escolher o processo com o equilíbrio certo entre velocidade, interrupção da carga de trabalho, redução de riscos e otimização de custos. Para saber mais sobre qual estratégia de upgrade de nós é ideal para seu ambiente, consulte Escolher upgrades súbitos e Escolher upgrades azuis/verdes.

Com as duas estratégias, é possível definir as configurações de upgrade para otimizar o processo com base nas necessidades do seu ambiente. Para saber mais, consulte Configurar sua estratégia de upgrade escolhida. Garanta que, para a estratégia escolhida, você tenha cota, disponibilidade de recursos ou capacidade de reserva suficientes para fazer upgrade dos seus nós usando essa estratégia. Para mais informações, consulte Garantir recursos para upgrades de nós.

Upgrades de sobretensão

Os upgrades súbitos são a estratégia de upgrade padrão e são melhores para aplicativos que podem processar alterações incrementais. Eles usam um método contínuo para fazer upgrade de nós, em uma ordem indefinida. Encontre o equilíbrio ideal entre velocidade e interrupção para seu ambiente escolhendo quantos nós novos e súbitos podem ser criados com maxSurge e quantos nós já existentes podem ser interrompidos de uma só vez com maxUnavailable.

Os upgrades súbitos também funcionam com o escalonador automático de cluster para impedir alterações nos nós que estão passando por um upgrade.

Escolher upgrades súbitos para seu ambiente

Se a otimização de custos for importante para você e a carga de trabalho puder tolerar ser desativada em menos de 60 minutos, recomendamos escolher upgrades de sobretensão para os Pools de nós.

Os upgrades súbitos são ideais para os seguintes cenários:

se quiser otimizar para a velocidade dos upgrades.
se as cargas de trabalho forem mais tolerantes em caso de interrupções, em que o encerramento normal de até 60 minutos é aceitável.
se quiser controlar os custos minimizando a criação de novos nós.

Quando o GKE usa upgrades súbitos

Se ativado, o GKE usa upgrades súbitos quando ocorrem os seguintes tipos de mudanças:

Alterações de versão (upgrades)
Como escalonar os nós verticalmente alterando os atributos da máquina do nó, incluindo o tipo de máquina, o tipo de disco e o tamanho do disco
Mudanças no tipo de imagem
Rotação de IP
Rotação de credenciais
Criação de políticas de rede
Ativar o streaming de imagens
Atualizações de configuração de desempenho da rede
Ativar a gVNIC
Alterações na configuração do sistema
Nós confidenciais

Outras alterações, incluindo a aplicação de atualizações a rótulos de nós e taints de pools de nós atuais, não usam upgrades súbitos porque não exigem a recriação dos nós.

Noções básicas sobre as configurações de upgrade súbito

Use as configurações de upgrade súbito para selecionar o equilíbrio adequado entre velocidade e interrupção do pool de nós durante a manutenção dos clusters usando as configurações súbitas. Para controlar o número de nós dos quais o GKE tentará fazer upgrade ao mesmo tempo, mude os parâmetros de upgrade súbito em um pool de nós do Standard.

O comportamento do upgrade súbito é determinado pelas configurações maxSurge e maxUnavailable, que determinam quantos nós farão upgrade ao mesmo tempo em uma janela contínua com as etapas descritas.

`maxSurge`: o GKE cria um novo nó súbito antes de remover outro que já existe

Defina maxSurge para escolher o número máximo de nós súbitos extras que podem ser adicionados ao pool de nós durante um upgrade, por zona, aumentando a probabilidade de que as cargas de trabalho em execução no nó já existente possam migrar de imediato para um novo nó. O padrão é um. Para fazer upgrade de um nó, o GKE segue estas etapas:

Provisionar um novo nó.
Aguardar até que o novo nó esteja pronto.
Demarcar o nó que já existe.
Drenar o nó que já existe, respeitando as configurações de PodDisruptionBudget e GracefulTerminationPeriod por até um hora.
Excluir o nó que já existe.

Para que o GKE crie nós súbitos, seu projeto precisa ter os recursos para criar mais nós temporariamente. Se você não tiver capacidade extra, o GKE não começará a fazer upgrade de um nó até que os recursos estejam disponíveis. Para saber mais, consulte Recursos para upgrades súbitos.

`maxUnavailable`: o GKE indisponibiliza um nó já existente para recriá-lo

Defina maxUnavailable para escolher o número máximo de nós que podem ficar indisponíveis simultaneamente durante um upgrade, por zona. O padrão é zero. As cargas de trabalho em execução no nó já existente talvez precisem aguardar o upgrade dele, se nenhum outro nó tiver capacidade. Para fazer upgrade de um nó, o GKE segue estas etapas:

Demarcar o nó que já existe.
Drenar o nó que já existe, respeitando as configurações de PodDisruptionBudget e GracefulTerminationPeriod por até um hora.
Recriar o nó já existente com a nova configuração.
Aguardar até que o nó já existente esteja pronto.
Desfazer a demarcação do nó já existente que fez upgrade.

Quando o GKE recria o nó já existente, ele libera temporariamente a capacidade do nó quando ela não vem de uma reserva. Isso significa que, se houver capacidade limitada, você corre o risco de perder a capacidade que já existe. Portanto, se o ambiente tiver restrição de recursos, use essa configuração apenas se for usar nós reservados. Para saber mais, consulte Fazer upgrade em um ambiente com restrição de recursos.

Exemplo de uso das configurações `maxSurge` e `maxUnavailable`

Por exemplo, um cluster do GKE tem um pool de nós de zona única com cinco nós e a seguinte configuração de upgrade súbito: maxSurge=2;maxUnavailable=1.

Durante um upgrade súbito com esse pool de nós, em uma janela contínua, o GKE cria dois nós atualizados e interrompe no máximo um nó já existente por vez. O GKE reduzirá no máximo três nós já existentes depois que os nós atualizados estiverem prontos. Durante o processo de upgrade, o pool de nós incluirá entre quatro e sete nós.

Considerações para as configurações de upgrade súbito

Considere estas informações antes de definir as configurações de upgrade súbito:

Os nós criados pelo upgrade súbito estão sujeitos às cotas de recursos, à disponibilidade de recursos e à capacidade de reserva do Google Cloud para pools de nós com afinidade de reserva específica. Se o ambiente tiver restrição de recursos, consulte Fazer upgrade em um ambiente com restrição de recursos.
O número de nós dos quais o GKE faz upgrade simultaneamente é a soma de maxSurge e maxUnavailable. O número máximo de nós que podem fazer upgrade simultaneamente é limitado a 20. Os upgrades súbitos também funcionam com o escalonador automático de cluster para impedir alterações nos nós que estão passando por upgrade.
O GKE faz upgrade dos pools de nós de várias zonas uma zona por vez. Os parâmetros de upgrade súbito são aplicáveis apenas até o número de nós na zona. O número máximo de nós que podem fazer upgrade em paralelo não será maior que a soma de maxSurge mais maxUnavailable nem maior que o número de nós na zona.
Se o pool de nós usar VMs spot, o GKE criará nós súbitos com VMs spot, mas não aguardará as VMs spot estarem prontas antes de demarcar e drenar os nós já existentes. Para saber mais, consulte Fazer upgrade de pools de nós do Standard usando VMs spot.

Ajustar as configurações de upgrade súbito para equilibrar velocidade e interrupção

A tabela a seguir descreve quatro perfis de upgrade diferentes como exemplos para ajudar você a entender diferentes configurações:

Descrição	Configuração	Caso de uso típico
Balanceado (padrão), mais lento, mas menos prejudicial	`maxSurge=1 maxUnavailable=0`	Maioria das cargas de trabalho
Rápido, sem recursos de sobretensão, mais interruptivo	`maxSurge=0 maxUnavailable=20`	Pools de nós grandes após os jobs serem executados até a conclusão
Rápido, a maioria dos recursos é de sobretensão e é menos interruptivo	`maxSurge=20 maxUnavailable=0`	Pools de nós grandes
Mais lento, com interrupção, sem recursos súbitos	`maxSurge=0 maxUnavailable=1`	Pool de nós com restrição de recursos com reserva

Balanceado (padrão)

A maneira mais simples de aproveitar os upgrades súbitos é usar a configuração padrão: maxSurge=1;maxUnavailable=0.. Com essa configuração, os upgrades progridem lentamente, com apenas um nó súbito adicionado por vez. Ou seja, apenas um nó é atualizado por vez. Os pods podem ser reiniciados imediatamente no novo nó súbito. Essa configuração requer apenas que os recursos criem temporariamente um novo nó.

Rápido e sem recursos súbitos

Se você tiver um pool de nós grande e a carga de trabalho não for sensível a interrupções (por exemplo, um job em lote executado até a conclusão), use a configuração a seguir para maximizar a velocidade sem usar recursos extras: maxSurge=0;maxUnavailable=20. Essa configuração não exibe novos nós súbitos e permite que 20 nós sejam atualizados ao mesmo tempo.

Rápido e com menos interrupção

Se sua carga de trabalho for sensível à interrupção, e você já tiver configurado PodDisruptionBudgets (PDB) e não estiver usando externalTrafficPolicy: Local, que não funciona com drenos de nó em paralelo, será possível aumentar a velocidade do upgrade usando maxSurge=20;maxUnavailable=0. Essa configuração atualiza 20 nós em paralelo, enquanto o PDB limita o número de pods que podem ser drenados em um determinado momento. Ainda que as configurações dos PDBs possam variar, se você criar um PDB com maxUnavailable=1 para uma ou mais cargas de trabalho em execução no pool de nós, somente um pod dessas cargas de trabalho poderá ser removido por vez, limitando o paralelismo de todo o upgrade. Essa configuração requer que os recursos criem temporariamente 20 novos nós.

Lento, mas sem recursos súbitos

Se não for possível usar recursos extras, use maxSurge=0;maxUnavailable=1 para recriar um nó por vez.

Controlar um upgrade de sobrecarga em andamento

Com os upgrades súbitos, enquanto um upgrade estiver em andamento, você pode usar comandos para exercitar parte do controle. Para ter mais controle sobre o processo de upgrade, recomendamos o uso de upgrades azul-verde.

Cancelar (pausar) um upgrade súbito

É possível cancelar um upgrade de sobrecarga em andamento a qualquer momento durante o processo de upgrade. O cancelamento pausa o upgrade, impedindo o GKE de fazer upgrade de novos nós, mas não reverte automaticamente o upgrade dos nós já atualizados. Depois do cancelamento, é possível retomar ou reverter um upgrade.

Quando você cancela um upgrade, o GKE faz o seguinte com cada um dos nós:

os nós que iniciaram o upgrade o concluem;
Nós que não iniciaram o upgrade não são atualizados.
Os upgrades dos nós que já tiverem sido concluídos não serão afetados nem revertidos.

Isso significa que o pool de nós pode acabar em um estado em que os nós estão executando duas versões diferentes. Se os upgrades automáticos estiverem ativados para o pool de nós, ele poderá ser programado para upgrade automático novamente, que atualizaria os nós restantes no pool que executa o versão mais antiga.

Saiba como cancelar um upgrade do pool de nós.

Retomar um upgrade súbito

Se um upgrade do pool de nós tiver sido cancelado e você tiver feito um upgrade parcial, será possível retomá-lo para concluir o processo de upgrade do pool de nós. Isso fará o upgrade dos nós restantes que não foram atualizados na operação original. Saiba como retomar um upgrade do pool de nós.

Reverter um upgrade súbito

Se um pool de nós for parcialmente atualizado, será possível revertê-lo para revertê-lo ao estado anterior. Não é possível revertê-lo depois do upgrade. Os nodes que não iniciaram um upgrade não são afetados. Saiba como reverter um upgrade de pool de nós.

Se você quiser fazer downgrade de um pool de nós para a versão anterior após a conclusão do upgrade, consulte Downgrade de pools de nós.

Upgrades azuis-verdes

Os upgrades azul-verde são uma estratégia de upgrade alternativa da estratégia padrão de upgrade súbito. Com upgrades azul-verde, o GKE primeiro cria um novo conjunto de recursos do nó (nós verdes) com a nova configuração do nó antes de eliminar qualquer carga de trabalho nos recursos originais (nós azuis). O GKE mantém os recursos "azuis", se necessário, para reverter cargas de trabalho até que o tempo de imersão seja cumprido. Você pode ajustar o ritmo dos upgrades e do tempo de imersão com base nas necessidades do seu ambiente.

Com essa estratégia, você tem mais controle sobre o processo de upgrade. É possível reverter um upgrade em andamento, se necessário, porque o ambiente original é mantido durante o upgrade. No entanto, essa estratégia de upgrade também exige mais recursos. Como o ambiente original é replicado, o pool de nós usa o dobro do número de recursos durante o upgrade.

Escolha upgrades azul-verde para seu ambiente

Se você tiver cargas de trabalho de produção altamente disponíveis que precisam ser revertidas rapidamente caso a carga de trabalho não tolere o upgrade e um aumento temporário de custo seja aceitável, recomendamos escolher upgrades azul-verde dos seus pools de nós.

Os upgrades azuis/verdes são ideais para os seguintes cenários:

Se você quiser um lançamento gradual em que a mitigação de riscos seja mais importante, em que seja necessário encerrar normalmente mais de 60 minutos.
se as cargas de trabalho são menos tolerantes a interrupções.
se um aumento temporário de custo devido ao maior uso de recursos for aceitável.

Quando o GKE usa upgrades azul-verde

Para os nós do GKE, há diferentes tipos de alterações de configuração que exigem que os nós sejam recriados. Se ativado, o GKE usará upgrades azul-verde quando os seguintes tipos de alterações ocorrerem:

Alterações de versão (upgrades)
Como escalonar os nós verticalmente alterando os atributos da máquina do nó, incluindo o tipo de máquina, o tipo de disco e o tamanho do disco
Mudanças no tipo de imagem

Os upgrades súbitos serão usados para outros recursos que exigem a recriação dos nós. Para saber mais, consulte Quando os upgrades súbitos são usados.

Fases de upgrades azul-verde

Com os upgrades azul-verde, é possível personalizar e controlar o processo da seguinte forma:

usando os parâmetros de configuração do upgrade.
usando comandos para cancelar (pausar), retomar, reverter ou concluir as etapas.

Esta seção explica as fases do processo de upgrade. Você pode usar as configurações de upgrade para ajustar o funcionamento das fases e comandos para controlar o processo de upgrade.

Fase 1: criar pool verde

Nesta fase, um novo conjunto de grupos de instâncias gerenciadas (MIGs, na sigla em inglês), conhecido como o pool "verde", é criado para cada zona no pool de destino com a nova configuração de nó (nova versão ou tipo de imagem) de dados.

A cota será verificada antes de começar a provisionar novos recursos verdes.

Nesta fase, os MIGs originais, conhecidos como pools azuis, o escalonador automático de clusters deixará de aumentar ou diminuir. O pool verde só pode ser escalonado nessa fase.

Fase 2: pool azul de Cordon

Nesta fase, todos os nós originais no pool azul (MIGs existentes) serão marcados (marcados como não programáveis). As cargas de trabalho existentes continuarão em execução, mas as novas cargas de trabalho não serão programadas nos nós atuais.

Fase 3: drenar o pool azul

Nesta fase, os nós originais no pool azul (MIGs existentes) serão drenado em lotes. Quando o Kubernetes drena um nó, as solicitações de remoção são enviadas para todos os pods em execução no nó. Os pods serão reprogramados. Para pods que têmOrçamento PodDisruptionBudget violações ou longaTerminaçãoGracePeriodSeconds durante a drenagem, eles serão excluídos na fase Excluir pool azul, quando o nó é excluído. É possível usar BATCH_SOAK_DURATION e NODE_POOL_SOAK_DURATION, que são descritos aqui e na próxima seção, para estender o período antes da exclusão dos pods.

É possível controlar o tamanho dos lotes com uma das seguintes configurações:

BATCH_NODE_COUNT: o número absoluto de nós a serem drenados em um lote.
BATCH_PERCENT: a porcentagem de nós a serem drenados em um lote, expressa como um decimal entre 0 e 1, inclusive. O GKE arredondará para a porcentagem mais próxima de nós, para um valor mínimo de um nó, se a porcentagem não for um número inteiro de nós.

Se uma dessas configurações for definida como zero, o GKE pulará essa fase e avançará para a fase do Pool de nós Soak.

Além disso, é possível controlar por quanto tempo cada drenagem em lote fica imerso em BATCH_SOAK_DURATION. Essa duração é definida em segundos, sendo o padrão zero em segundos.

Nesta fase, é possível cancelar o upgrade, se necessário. Quando você cancela um upgrade azul-verde, ele é pausado na fase atual. Depois do cancelamento, é possível retomar ou reverter o upgrade. Nesta fase, a reversão interrompe a drenagem do pool azul e desamarra o pool azul. As cargas de trabalho podem ser reprogramadas no pool azul (não garantidas), e o pool verde será excluído.

Fase 4: imersão do pool de nós

Essa fase é usada para verificar a integridade da carga de trabalho depois que os nós do pool azul forem drenados.

O tempo de imersão é definido com NODE_POOL_SOAK_DURATION em segundos. Por padrão, ele é definido como 1 hora (3.600 segundos). Se a duração total da imersão atingir 7 dias (604.800 segundos), a fase de exclusão do pool azul vai começar imediatamente.

A duração total da imersão é a soma de NODE_POOL_SOAK_DURATION mais BATCH_SOAK_DURATION multiplicada pelo número de lotes, que é determinado por BATCH_NODE_COUNT ou BATCH_PERCENT.

Nessa fase, é possível concluir o upgrade e ignorar o tempo de imersão restante concluindo o upgrade. Isso iniciará imediatamente o processo de remoção dos nós do pool azul.

Ainda é possível cancelar o upgrade, se necessário. Quando você cancela um upgrade azul-verde, ele é pausado na fase atual. Depois do cancelamento, é possível retomar ou reverter o upgrade.

Nesta fase, agora o escalonador automático de clusters pode aumentar ou diminuir o pool verde normalmente.

Fase 5: excluir pool azul

Após a expiração do tempo de imersão, os nós do pool azul serão removidos do pool de destino. Não é possível pausar esta fase. Além disso, essa fase não usa remoção e, em vez disso, tenta excluir os pods. Ao contrário da remoção, a exclusão não respeita os PDBs e exclui os pods. A exclusão limita o terminationGracePeriodSeconds de um pod a no máximo 60 minutos. Depois que essa última tentativa for feita para excluir os pods restantes, os nós do pool azul serão excluídos do pool.

Na conclusão desta fase, o pool de nós terá apenas novos nós com a configuração atualizada (versão ou tipo de imagem).

Como o escalonador automático de clusters funciona com upgrades azul-verde

Durante as fases de um upgrade azul-verde, o pool "azul" original não aumenta nem diminui. Quando o novo pool "verde" é criado, ele só pode ser escalonado verticalmente até a fase de pool de nós do Soak, em que é possível aumentar ou diminuir o escalonamento. Se um upgrade for revertido, o pool "azul" original poderá ser escalonado durante esse processo, se necessário.

Controlar um upgrade azul-verde em andamento

Com os upgrades azul-verde, enquanto um upgrade está em andamento, você pode usar comandos para exercer controle sobre ele. Isso oferece um alto nível de controle sobre o processo, caso você determine, por exemplo, que as cargas de trabalho precisam ser revertidas para a configuração do nó antigo.

Cancelar (pausar) um upgrade azul-verde

Ao cancelar um upgrade azul-verde, você o pausa na fase atual. Esse comando pode ser usado em todas as fases, exceto na fase de exclusão do pool azul. Quando cancelado, o pool de nós é pausado em um status intermediário com base na fase em que a solicitação foi emitida.

Saiba como cancelar um upgrade de pool de nós.

Depois do cancelamento, é possível retomar ou reverter o upgrade.

Retomar um upgrade azul-verde

Se você determinou que o upgrade pode continuar, poderá retomá-lo.

Se você retomar, o processo de upgrade continuará na fase intermediária em que foi pausado. Para saber como retomar um upgrade de pool de nós, consulte Retomar um upgrade de pool de nós.

Reverter um upgrade azul-verde

Se você determinou que o upgrade não precisa avançar e quer trazer o pool de nós de volta ao estado original, é possível fazer uma reversão. Para saber como reverter um upgrade de pool de nós, consulte Reverter um upgrade de pool de nós.

Com o fluxo de trabalho de reversão, o processo é revertido para fazer com que o pool de nós volte ao estado original. O pool azul não será restringido para que as cargas de trabalho possam ser reprogramadas nele. Durante esse processo, o escalonador automático de clusters pode escalonar o pool azul conforme necessário. A piscina verde será drenada e excluída.