Estratégias de upgrade de nós

Neste documento, 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 do GKE Standard:

  • 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.
  • Upgrades azul-verde com escalonamento automático (prévia): as cargas de trabalho podem ser executadas por mais tempo, enquanto você minimiza o custo de nós ociosos ou subutilizados.

O GKE escolhe as seguintes estratégias para esses cenários específicos:

  • Nos clusters do Autopilot, o GKE usa upgrades súbitos. Para mais informações, consulte a seção Upgrades súbitos do documento sobre upgrades de clusters do Autopilot.
  • Para pools de nós gerenciados pelo Autopilot em clusters Padrão, o GKE usa upgrades súbitos. Não é possível selecionar outra estratégia nem mudar a configuração.
  • Para nós que usam VMs de início flexível, o GKE usa upgrades de curta duração. O início flexível com provisionamento em fila é compatível com novas flags que fazem parte do lançamento da prévia do início flexível. O início flexível é alimentado pelo Programador dinâmico de cargas de trabalho.

Ao escolher uma estratégia de upgrade para o pool de nós 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:

Com cada uma dessas estratégias, é possível definir as configurações de upgrade para otimizar o processo com base nas necessidades do seu ambiente. Para mais informações, 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.

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

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:

  1. Provisionar um novo nó.
  2. Aguardar até que o novo nó esteja pronto.
  3. Demarcar o nó que já existe.
  4. Drenar o nó que já existe, respeitando as configurações de PodDisruptionBudget e GracefulTerminationPeriod por até um hora. Depois de uma hora, todos os pods restantes são removidos à força para que o upgrade possa continuar.
  5. 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 mais informações, 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:

  1. Demarcar o nó que já existe.
  2. Drenar o nó que já existe, respeitando as configurações de PodDisruptionBudget e GracefulTerminationPeriod por até um hora. Depois de uma hora, todos os pods restantes são removidos à força para que o upgrade possa continuar.
  3. Recriar o nó já existente com a nova configuração.
  4. Aguardar até que o nó já existente esteja pronto.
  5. 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 mais informações, 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:

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 reverter-los 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.

Quando escolher 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.

Os upgrades azul-verde continuam até a conclusão, mesmo que excedam uma janela de manutenção. Para mais informações, consulte Como as estratégias de upgrade de nós funcionam com janelas de manutenção.

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:

Os upgrades súbitos são usados para outras atualizações que exigem a recriação dos nós. Para mais informações, 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:

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.

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 excluirá o pool verde.

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.

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 vai desamarrar o pool azul e excluir o pool verde.

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êm violações de PodDisruptionBudget ou um longo terminationGracePeriodSeconds durante a drenagem, eles serão excluídos na fase Excluir pool azul quando o nó for 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. Se o lote anterior já estiver esgotado e você retomar o upgrade, o próximo lote de nós poderá ser processado imediatamente sem respeitar o BATCH_SOAK_DURATION desse lote. A reversão nesta fase interrompe a drenagem do pool azul e o desamarra. As cargas de trabalho podem ser reprogramadas no pool azul (não garantidas), e o pool verde é drenado e 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.

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.

Conclua um upgrade azul-verde

Durante a fase de Soak, é possível concluir um upgrade se você determinou que a carga de trabalho não precisa de validação extra na configuração do novo nó e os nós antigos podem ser removidos. Concluir um upgrade ignora o restante da Fase de Soak e passa para a Fase de exclusão do pool azul.

Para mais informações sobre como usar o comando complete, consulte Concluir um upgrade do pool de nós azul-verde.

Upgrades azul-verde escalonados

Os upgrades azul-verde escalonados são um tipo diferente de estratégia de upgrade que maximiza o tempo antes que as cargas de trabalho intolerantes a interrupções sejam removidas, minimizando o custo. Essa estratégia é derivada dos upgrades azul-verde padrão. No entanto, com os upgrades azul-verde escalonados automaticamente, o GKE não drena nós com cargas de trabalho marcadas como não seguras para remoção por até sete dias após o isolamento dos nós.

A seção a seguir explica quando escolher essa estratégia, como a implementação dela de upgrades azul-verde é diferente dos upgrades azul-verde padrão e quais práticas recomendadas seguir ao usar essa estratégia.

Para usar upgrades azul-verde com escalonamento automático, consulte Configurar upgrades azul-verde com escalonamento automático.

Quando escolher upgrades azul-verde com escalonamento automático para seu ambiente

Se você tiver cargas de trabalho que precisem do tempo máximo antes da remoção, mas não precisarem ser reprogramadas o mais rápido possível, recomendamos escolher upgrades azul-verde com escalonamento automático para seus pools de nós.

Os upgrades azul-verde escalonados funcionam bem se estes cenários se aplicarem a você:

  • Você tem cargas de trabalho em lote (incluindo treinamento de IA/ML) que precisam ser executadas até a conclusão.
  • Você quer minimizar os custos em comparação com upgrades azul-verde padrão, minimizando a quantidade de nós inativos ou subutilizados.
  • Não é preciso garantir que os pods tenham reprogramação imediata ou reversão imediata para a configuração do nó anterior.

Escolha upgrades azul-verde padrão se precisar minimizar o tempo de reprogramação de cargas de trabalho para novos nós e a capacidade de reverter para a configuração anterior do nó.

Os upgrades azul-verde com escalonamento automático, assim como os upgrades azul-verde padrão, continuam até a conclusão, mesmo que excedam uma janela de manutenção. Para mais informações, consulte Como as estratégias de upgrade de nós funcionam com janelas de manutenção.

Fases de upgrades azul-verde com escalonamento automático

Quando o GKE faz upgrade de pools de nós com upgrades azul-verde escalonados automaticamente, as fases são diferentes dos upgrades azul-verde padrão. Para ver as fases da estratégia de upgrade padrão, consulte as fases de upgrades azul-verde.

Quando a política de upgrades azul-verde escalonada automaticamente está ativada, o GKE executa estas etapas durante uma operação:

  1. O GKE cria o pool verde. No entanto, o pool verde começa com zero nós. Quando o GKE remover pods do pool azul em uma fase posterior, o escalonador automático de cluster vai escalonar o pool verde para executar esses pods.
  2. O GKE restringe o pool azul.

  3. O GKE aguarda um período que pode ser configurado de zero a sete dias (o padrão é três dias). Durante esse período, o GKE faz o seguinte:

  4. O GKE drena o pool azul, drenando os nós restantes do pool azul até 20 por vez em paralelo. O GKE respeita as configurações de PodDisruptionBudget por até 1 hora e as configurações de terminationGracePeriodSeconds por até 24 horas.

  5. O GKE ignora a fase do pool de nós de imersão.

  6. O GKE exclui o pool azul.

Práticas recomendadas para upgrades azul-verde com escalonamento automático

As seções a seguir oferecem práticas recomendadas para cluster, pool de nós e pods, a fim de minimizar a interrupção da carga de trabalho durante upgrades azul-verde com escalonamento automático.

Configuração de cluster e pool de nós

  • O GKE respeita os limites de escalonamento automático ao escalonar verticalmente o pool verde. Defina os parâmetros --max-nodes ou --total-max-nodes altos o suficiente para que o escalonador automático de cluster possa escalonar verticalmente o pool verde quando o GKE reprogramar as cargas de trabalho do pool azul para o pool verde. O GKE não respeita os parâmetros --min-nodes ou --total-min-nodes ao reduzir o pool azul.
  • Configure o perfil de escalonamento automático optimize-utilization se quiser que o GKE reduza verticalmente os nós subutilizados no pool azul de forma mais agressiva. Para mais informações, consulte Perfis de escalonamento automático.
  • Não atualize pools de nós criados com provisionamento automático de nós para usar upgrades azul-verde com escalonamento automático. Além disso, não configure o cluster para usar upgrades azul-verde com escalonamento automático para novos pools de nós provisionados automaticamente.

Configuração do pod

  • Para garantir que os pods não sejam removidos durante a pausa antes de drenar o pool azul, adicione a anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" a esses pods. Essa anotação impede que o escalonador automático de cluster remova o pod se o nó dele estiver subutilizado.
  • Assim como nos upgrades azul-verde padrão, para garantir que os pods removidos dos nós no pool azul sejam reprogramados apenas para os nós no pool verde, adicione um nodeSelector ao rótulo cloud.google.com/gke-nodepool:NODE_POOL_NAME à sua carga de trabalho. Se você omitir esse rótulo e tiver outros pools de nós no cluster, os pods removidos poderão ser programados para nós nesses outros pools.

Limitações dos upgrades azul-verde com escalonamento automático

  • É possível cancelar e retomar os upgrades azul-verde escalonados automaticamente. No entanto, não é possível reverter o upgrade cancelado.
  • Quando o pool azul é isolado e drenado, os pods podem se tornar temporariamente não programáveis se o escalonador automático de clusters não puder escalonar verticalmente o pool verde devido a cotas e limites ou disponibilidade de recursos, porque o pool verde é criado sem nós.
  • Só será possível fazer upgrade de pools de nós com upgrades azul-verde escalonados automaticamente se o plano de controle do cluster estiver executando a versão 1.34.0-gke.2201000 ou posterior e o escalonador automático de clusters estiver ativado.

Quando o GKE usa upgrades azul-verde com escalonamento automático

O GKE usa upgrades azul-verde com escalonamento automático para os mesmos tipos de mudanças que os upgrades azul-verde padrão. Para mais informações sobre os tipos de mudanças em que o GKE usa a estratégia padrão de upgrade azul-verde, consulte Quando o GKE usa upgrades azul-verde.

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

Para configurar upgrades azul-verde com escalonamento automático, também é necessário configurar o escalonador automático de cluster.

Se você usar upgrades azul-verde com escalonamento automático, o escalonador automático de cluster fará o seguinte:

  • Durante a fase em que o GKE aguarda a drenagem do pool azul, ele não é escalonar verticalmente e só é reduzido pelo escalonador automático de cluster quando os nós ficam subutilizados. O escalonador automático de cluster pode reduzir escala vertical a escala do pool azul a zero, sem respeitar os parâmetros --min-nodes ou --total-min-nodes. Em todas as outras fases, o escalonador automático de cluster não escalonar verticalmente nem diminui o pool azul.
  • O escalonador automático de cluster aumenta o pool verde de zero nós ou reduz para a configuração --min-nodes, conforme necessário em todas as fases da estratégia de upgrade.

Upgrades de curta duração (somente provisionamento de início flexível e em fila)

Os upgrades de curta duração são uma estratégia de upgrade de nós para uso exclusivo com nós que usam VMs de início flexível e nós que usam provisionamento em fila (com 1.32.2-gke.1652000 ou versões mais recentes), ambos com tecnologia do Programador Dinâmico de Cargas de Trabalho. Para mais informações sobre os nós que usam upgrades de curta duração, consulte Sobre a capacidade de obtenção de GPU com o Dynamic Workload Scheduler.

O GKE usa a estratégia de upgrades de curta duração para pools de nós padrão e grupos de nós em clusters do Autopilot.

Com essa estratégia, o GKE faz upgrade desses nós de tempo de execução limitado sem interromper as cargas de trabalho atuais. A estratégia funciona da seguinte maneira:

  1. Os nós atuais são executados até serem interrompidos.
  2. Os novos nós usam a nova configuração.
  3. Em um período máximo de sete dias, os nós fazem a transição da configuração atual para a nova.

O GKE configura automaticamente essa estratégia para nós que usam VMs Flex-start. Essa estratégia não tem configurações.

Quando o GKE usa upgrades de curta duração

O GKE define automaticamente os nós que usam VMs de início flexível para aplicar upgrades de curta duração. Os nós que usam apenas o provisionamento em fila, mas são executados em clusters na versão 1.32.2-gke.1652000 ou mais recente do GKE, também usam upgrades de curta duração.

Para pools de nós padrão e grupos de nós em clusters do Autopilot que usam upgrades de curta duração, o GKE usa essa estratégia em situações em que upgrades súbitos seriam usados. Além dos upgrades de nós (mudanças de versão), o GKE usa upgrades de curta duração para outros tipos de atualizações de nós, semelhante a como os upgrades súbitos são usados. Para mais informações, consulte Quando os upgrades súbitos são usados.

A seguir