Estratégias de atualização de nós

Este documento aborda as estratégias de atualização de nós que pode usar com os seus clusters do Google Kubernetes Engine (GKE).

Nos clusters Standard do GKE, pode configurar uma das seguintes estratégias de atualização de nós para cada conjunto de nós Standard:

  • Atualizações de picos: os nós são atualizados numa janela contínua. Pode controlar o número de nós que podem ser atualizados em simultâneo e o grau de perturbação das atualizações para as cargas de trabalho.
  • Atualizações azul-verde: os nós existentes são mantidos disponíveis para reversão enquanto as cargas de trabalho são validadas na nova configuração de nós.
  • Atualizações azul-verde com escalamento automático (Pré-visualização): As cargas de trabalho podem ser executadas durante mais tempo, enquanto minimiza o custo de nós inativos ou subutilizados.

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

  • Nos clusters do Autopilot, o GKE usa atualizações rápidas. Para mais informações, consulte a secção Atualizações rápidas do documento sobre atualizações de clusters do Autopilot.
  • Para pools de nós geridos pelo Autopilot em clusters Standard, o GKE usa atualizações rápidas. Não pode selecionar uma estratégia diferente nem alterar a configuração.
  • Para nós que usam VMs de início flexível, o GKE usa atualizações de curta duração. O início flexível com aprovisionamento em fila suporta novas flags que fazem parte do lançamento da pré-visualização do início flexível. O início flexível é suportado pelo programador de carga de trabalho dinâmico.

Ao escolher uma estratégia de atualização para o seu conjunto de nós padrão, pode selecionar o processo com o equilíbrio certo entre velocidade, interrupção da carga de trabalho, mitigação de riscos e otimização de custos. Para mais informações sobre a estratégia de atualização de nós adequada para o seu ambiente, consulte o seguinte:

Com cada uma destas estratégias, pode configurar as definições de atualização para otimizar o processo com base nas necessidades do seu ambiente. Para mais informações, consulte o artigo Configure a estratégia de atualização escolhida. Certifique-se de que, para a estratégia que escolher, tem quota suficiente, disponibilidade de recursos ou capacidade de reserva para atualizar os nós através dessa estratégia. Para mais informações, consulte o artigo Garanta recursos para atualizações de nós.

Atualizações de aumentos

As atualizações de picos são a estratégia de atualização predefinida e a melhor opção para aplicações que podem processar alterações incrementais. As atualizações por picos usam um método contínuo para atualizar os nós, numa ordem indefinida. Encontre o equilíbrio ideal entre velocidade e interrupção para o seu ambiente, escolhendo quantos nós de pico novos podem ser criados com maxSurge e quantos nós existentes podem ser interrompidos de uma só vez com maxUnavailable.

As atualizações rápidas também funcionam com o redimensionador automático de clusters para evitar alterações aos nós que estão a ser atualizados.

Quando escolher atualizações de picos para o seu ambiente

Se a otimização de custos for importante para si e a sua carga de trabalho puder tolerar o encerramento em menos de 60 minutos, recomendamos que escolha atualizações rápidas para os seus conjuntos de nós.

As atualizações de picos são ideais para os seguintes cenários:

  • Se quiser otimizar em função da velocidade das atualizações.
  • se as cargas de trabalho forem mais tolerantes a interrupções, em que a terminação elegante até 60 minutos é aceitável.
  • Se quiser controlar os custos minimizando a criação de novos nós.

Quando o GKE usa atualizações rápidas

Se estiver ativada, o GKE usa atualizações rápidas quando ocorrem os seguintes tipos de alterações:

Outras alterações, incluindo a aplicação de atualizações a etiquetas de nós e contaminações de node pools existentes, não usam atualizações rápidas, uma vez que não requerem a recriação dos nós.

Compreenda as definições de atualização de picos

Use as definições de atualização rápida para selecionar o equilíbrio adequado entre a velocidade e a interrupção para o seu conjunto de nós durante a manutenção do cluster através das definições de atualização rápida. Pode alterar o número de nós que o GKE tenta atualizar em simultâneo alterando os parâmetros de atualização rápida num conjunto de nós padrão.

O comportamento de atualização de picos é determinado pelas definições maxSurge e maxUnavailable, que determinam quantos nós são atualizados em simultâneo numa janela de implementação contínua com os passos descritos.

maxSurge: o GKE cria um novo nó de pico antes de remover um existente

Defina maxSurge para escolher o número máximo de nós de picos adicionais que podem ser adicionados ao conjunto de nós durante uma atualização, por zona, aumentando a probabilidade de que as cargas de trabalho em execução no nó existente possam migrar imediatamente para um novo nó. A predefinição é um. Para atualizar um nó, o GKE executa os seguintes passos:

  1. Aprovisionar um novo nó.
  2. Aguarde até que o novo nó esteja pronto.
  3. Cordon o nó existente.
  4. Esvazie o nó existente, respeitando as definições de PodDisruptionBudget e GracefulTerminationPeriod durante um máximo de uma hora. Após uma hora, todos os Pods restantes são removidos à força para que a atualização possa prosseguir.
  5. Elimine o nó existente.

Para que o GKE crie nós de picos, o seu projeto tem de ter os recursos para criar temporariamente nós adicionais. Se não tiver capacidade adicional, o GKE não inicia a atualização de um nó até que os recursos estejam disponíveis. Para mais informações, consulte os Recursos para atualizações rápidas.

maxUnavailable: o GKE torna um nó existente indisponível para o recriar

Defina maxUnavailable para escolher o número máximo de nós que podem estar simultaneamente indisponíveis durante uma atualização, por zona. A predefinição é zero. As cargas de trabalho em execução no nó existente podem ter de aguardar a atualização do nó existente, se não existirem outros nós com capacidade. Para atualizar um nó, o GKE executa os seguintes passos:

  1. Isolar o nó existente.
  2. Drenar o nó existente, respeitando as definições de PodDisruptionBudget e GracefulTerminationPeriod durante um período máximo de uma hora. Após uma hora, todos os Pods restantes são removidos à força para que a atualização possa prosseguir.
  3. Recrie o nó existente com a nova configuração.
  4. Aguarde até que o nó existente esteja pronto.
  5. Remova a restrição do nó existente atualizado.

Quando o GKE recria o nó existente, o GKE liberta temporariamente a capacidade do nó se a capacidade não for de uma reserva. Isto significa que, se houver capacidade limitada, corre o risco de perder a capacidade existente. Assim, se o seu ambiente tiver restrições de recursos, use esta definição apenas se estiver a usar nós reservados. Para mais informações, consulte o artigo Atualize num ambiente com restrições de recursos.

Exemplo de utilização das definições maxSurge e maxUnavailable

Por exemplo, um cluster do GKE tem um conjunto de nós de zona única com 5 nós e a seguinte configuração de atualização rápida: maxSurge=2;maxUnavailable=1.

Durante uma atualização rápida com este conjunto de nós, numa janela de implementação gradual, o GKE cria dois nós atualizados e interrompe, no máximo, um nó existente de cada vez. O GKE desativa, no máximo, três nós existentes depois de os nós atualizados estarem prontos. Durante o processo de atualização, o node pool vai incluir entre quatro e sete nós.

Considerações para as definições de atualização de picos

Considere as seguintes informações antes de configurar as definições de atualização de picos:

Ajuste as definições de atualização do aumento de preços para equilibrar a velocidade e a interrupção

A tabela seguinte descreve quatro perfis de atualização diferentes como exemplos para ajudar a compreender as diferentes configurações:

Descrição Configuração Exemplo de utilização típico
Equilibrada (predefinição), mais lenta, mas menos disruptiva maxSurge=1 maxUnavailable=0 A maioria das cargas de trabalho
Rápido, sem recursos de picos, mais disruptivo maxSurge=0 maxUnavailable=20 Grandes conjuntos de nós após a execução dos trabalhos até à conclusão
Rápido, com a maioria dos recursos de picos e menos disruptivo maxSurge=20 maxUnavailable=0 Node pools grandes
Mais lento, disruptivo, sem recursos de picos maxSurge=0 maxUnavailable=1 Pool de nós com restrições de recursos e reserva

Equilibrada (predefinição)

A forma mais simples de tirar partido das atualizações rápidas é usar a configuração predefinida. maxSurge=1;maxUnavailable=0. Com esta configuração, as atualizações progridem lentamente, com apenas um nó de pico adicionado de cada vez, o que significa que apenas um nó é atualizado de cada vez. Os pods podem ser reiniciados imediatamente no novo nó de pico. Esta configuração só requer que os recursos criem temporariamente um novo nó.

Rápido e sem recursos de picos

Se tiver um conjunto de nós grande e a sua carga de trabalho não for sensível a interrupções (por exemplo, uma tarefa em lote que foi executada até à conclusão), use a seguinte configuração para maximizar a velocidade sem usar recursos adicionais: maxSurge=0;maxUnavailable=20. Esta configuração não apresenta nós de pico adicionais e permite a atualização de 20 nós em simultâneo.

Rápido e menos disruptivo

Se a sua carga de trabalho for sensível a interrupções e já tiver configurado PodDisruptionBudgets (PDB) e não estiver a usar externalTrafficPolicy: Local, que não funciona com esgotamentos de nós paralelos, pode aumentar a velocidade da atualização usando maxSurge=20;maxUnavailable=0. Esta configuração atualiza 20 nós em paralelo, enquanto o PDB limita o número de pods que podem ser esvaziados num determinado momento. Embora as configurações dos PDBs possam variar, se criar um PDB com maxUnavailable=1 para uma ou mais cargas de trabalho em execução no conjunto de nós, então apenas um pod dessas cargas de trabalho pode ser removido de cada vez, o que limita o paralelismo de toda a atualização. Esta configuração requer que os recursos criem temporariamente 20 novos nós.

Lento, mas sem recursos de pico

Se não puder usar recursos adicionais, pode usar maxSurge=0;maxUnavailable=1 para recriar um nó de cada vez.

Controle uma atualização de pico em curso

Com as atualizações rápidas, enquanto uma atualização está em curso, pode usar comandos para exercer algum controlo sobre a mesma. Para ter mais controlo sobre o processo de atualização, recomendamos a utilização de atualizações azul-verde.

Cancele (pause) uma atualização de pico

Pode cancelar uma atualização de pico em curso em qualquer altura durante o processo de atualização. O cancelamento pausa a atualização, impedindo que o GKE atualize novos nós, mas não reverte automaticamente a atualização dos nós já atualizados. Depois de cancelar uma atualização, pode retomar ou reverter.

Quando cancela uma atualização, o GKE faz o seguinte com cada um dos nós:

  • Os nós que iniciaram a atualização concluem-na.
  • Os nós que não iniciaram a atualização não são atualizados.
  • Os nós que já concluíram com êxito a atualização não são afetados e não são revertidos.

Isto significa que o conjunto de nós pode acabar num estado em que os nós estão a executar duas versões diferentes. Se as atualizações automáticas estiverem ativadas para o conjunto de nós, é possível agendar novamente o conjunto de nós para atualização automática, o que atualiza os nós restantes no conjunto de nós que executam a versão mais antiga.

Saiba como cancelar uma atualização do conjunto de nós.

Retome uma atualização de aumento

Se uma atualização do node pool foi cancelada e ficou parcialmente atualizada, pode retomar a atualização para concluir o processo de atualização do node pool. Esta ação atualiza todos os nós restantes que não foram atualizados na operação original. Saiba como retomar uma atualização do node pool.

Reverta uma atualização de aumento

Se um conjunto de nós ficar parcialmente atualizado, pode reverter o conjunto de nós para revertê-lo para o estado anterior. Não é possível reverter os conjuntos de nós depois de terem sido atualizados com êxito. Os nós que não iniciaram uma atualização não são afetados. Saiba como reverter uma atualização do conjunto de nós.

Se quiser reverter um conjunto de nós para a versão anterior depois de a atualização estar concluída, consulte o artigo Reverter conjuntos de nós.

Atualizações azul-verde

As atualizações azul-verde são uma estratégia de atualização alternativa à estratégia de atualização por picos predefinida. Com as atualizações azul-verde, o GKE cria primeiro um novo conjunto de recursos de nós (nós "verdes") com a nova configuração de nós antes de desalojar quaisquer cargas 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 teste de stress seja cumprido. Pode ajustar o ritmo das atualizações e o tempo de teste com base nas necessidades do seu ambiente.

Com esta estratégia, tem mais controlo sobre o processo de atualização. Se necessário, pode reverter uma atualização em curso, uma vez que o ambiente original é mantido durante a atualização. No entanto, esta estratégia de atualização também requer mais recursos. À medida que o ambiente original é replicado, o node pool usa o dobro do número de recursos durante a atualização.

Quando escolher atualizações azul-verde para o seu ambiente

Se tiver cargas de trabalho de produção de elevada disponibilidade que precise de poder reverter rapidamente caso a carga de trabalho não tolere a atualização e um aumento temporário do custo for aceitável, recomendamos que escolha atualizações azul-verde para os seus conjuntos de nós.

As atualizações azul-verde são ideais para os seguintes cenários:

  • Se quiser uma implementação gradual em que a mitigação de riscos seja mais importante e em que seja necessário um encerramento elegante superior a 60 minutos.
  • se as suas cargas de trabalho forem menos tolerantes a interrupções.
  • Se um aumento temporário do custo devido a uma maior utilização de recursos for aceitável.

As atualizações azul-verde continuam até à conclusão se excederem um período de manutenção. Para mais informações, consulte o artigo Como funcionam as estratégias de atualização de nós com janelas de manutenção.

Quando o GKE usa atualizações azul-verde

Para os nós do GKE, existem diferentes tipos de alterações de configuração que requerem a recriação dos nós. Se estiver ativada, o GKE usa atualizações azul-verde quando ocorrem os seguintes tipos de alterações:

As atualizações rápidas são usadas para quaisquer outras atualizações que exijam a recriação dos nós. Para mais informações, consulte o artigo Quando são usadas atualizações de picos.

Fases das atualizações azul-verde

Com as atualizações azul-verde, pode personalizar e controlar o processo das seguintes formas:

Esta secção explica as fases do processo de atualização. Pode usar as definições de atualização para ajustar o funcionamento das fases e os comandos para controlar o processo de atualização.

Fase 1: crie um conjunto verde

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

A Quota vai ser verificada antes de iniciar o aprovisionamento de novos recursos verdes.

Nesta fase, o escalador automático do cluster dos MIGs originais, conhecido como o conjunto azul, vai parar de aumentar ou diminuir a escala. O conjunto verde só pode ser aumentado nesta fase.

Nesta fase, pode cancelar a atualização, se necessário. Quando cancela uma atualização azul/verde, a atualização é pausada na fase atual. Depois de a cancelar, pode retomá-la ou reverter. Nesta fase, a reversão elimina o conjunto verde.

Fase 2: piscina azul

Nesta fase, todos os nós originais no conjunto azul (MIGs existentes) são isolados (marcados como não agendáveis). As cargas de trabalho existentes vão continuar a ser executadas, mas as novas cargas de trabalho não vão ser agendadas nos nós existentes.

Nesta fase, pode cancelar a atualização, se necessário. Quando cancela uma atualização azul/verde, a atualização é pausada na fase atual. Depois de a cancelar, pode retomá-la ou reverter. Nesta fase, a reversão vai remover a restrição do conjunto azul e eliminar o conjunto verde.

Fase 3: esvazie o conjunto azul

Nesta fase, os nós originais no conjunto azul (MIGs existentes) vão ser esvaziados em lotes. Quando o Kubernetes esgota os nós, são enviados pedidos de despejo a todos os pods em execução no nó. Os Pods vão ser reagendados. Os pods que tenham violações de PodDisruptionBudget ou um terminationGracePeriodSeconds longo durante a drenagem são eliminados na fase Eliminar grupo azul quando o nó é eliminado. Pode usar BATCH_SOAK_DURATION e NODE_POOL_SOAK_DURATION, que são descritos aqui e na secção seguinte, para prolongar o período antes de os pods serem eliminados.

Pode controlar o tamanho dos lotes com qualquer uma das seguintes definições:

  • BATCH_NODE_COUNT: o número absoluto de nós a esvaziar num lote.
  • BATCH_PERCENT: a percentagem de nós a esvaziar num lote, expressa como um decimal entre 0 e 1, inclusive. O GKE arredonda para baixo para a percentagem mais próxima de nós, até um valor mínimo de 1 nó, se a percentagem não for um número inteiro de nós.

Se qualquer uma destas definições estiver definida como zero, o GKE ignora esta fase e avança para a fase Soak node pool.

Além disso, pode controlar a duração da imersão de cada lote de drenagem com BATCH_SOAK_DURATION. Esta duração é definida em segundos, sendo o valor predefinido zero segundos.

Nesta fase, ainda pode cancelar a atualização, se necessário. Quando cancela uma atualização azul/verde, a atualização é pausada na fase atual. Depois de a cancelar, pode retomá-la ou reverter. Se o lote anterior já tiver sido esgotado e retomar a atualização, o lote seguinte de nós pode ser processado imediatamente sem respeitar o BATCH_SOAK_DURATION para esse lote. A reversão nesta fase interrompe a drenagem do conjunto azul e remove a vedação. Em seguida, as cargas de trabalho podem ser reagendadas no conjunto azul (não garantido), e o conjunto verde é esvaziado e eliminado.

Fase 4: período de teste do pool de nós

Esta fase é usada para verificar o estado de funcionamento da carga de trabalho depois de os nós do conjunto azul terem sido esvaziados.

O tempo de imersão é definido com NODE_POOL_SOAK_DURATION, em segundos. Por predefinição, está definido como uma hora (3600 segundos). Se a duração total do teste de estabilidade atingir 7 dias (604 800 segundos), a fase de eliminação do grupo azul começa imediatamente.

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

Nesta fase, pode concluir a atualização e ignorar qualquer período de teste restante concluindo a atualização. Esta ação inicia imediatamente o processo de remoção dos nós do conjunto azul.

Ainda pode cancelar a atualização, se necessário. Quando cancela uma atualização azul/verde, a atualização é pausada na fase atual. Depois de a cancelar, pode retomá-la ou reverter.

Nesta fase, o redimensionador automático de cluster já pode aumentar ou reduzir os recursos do conjunto verde como normal.

Fase 5: elimine o conjunto azul

Após a expiração do tempo de preparação, os nós do conjunto azul são removidos do conjunto de destino. Não é possível pausar esta fase. Além disso, esta fase não usa a remoção e, em vez disso, tenta eliminar os pods. Ao contrário da expulsão, a eliminação não respeita os PDBs e elimina à força os pods. A eliminação limita a duração de um podcast a, no máximo, 60 minutos.terminationGracePeriodSeconds Após esta última tentativa de eliminar os restantes pods, os nós azuis do conjunto são eliminados do conjunto de nós.

Quando esta fase estiver concluída, o seu conjunto de nós terá apenas novos nós com a configuração atualizada (versão ou tipo de imagem).

Como funciona o redimensionador automático de clusters com atualizações azul-verde

Durante as fases de uma atualização azul-verde, o conjunto "azul" original não é dimensionado para cima nem para baixo. Quando o novo conjunto "verde" é criado, só pode ser dimensionado até à fase do conjunto de nós de teste de esforço, em que pode ser dimensionado para cima ou para baixo. Se uma atualização for revertida, o conjunto "azul" original pode ser dimensionado durante este processo se for necessária capacidade adicional.

Controle uma atualização azul-verde em curso

Com as atualizações azul-verde, enquanto uma atualização está em curso, pode usar comandos para exercer controlo sobre a mesma. Isto dá-lhe um elevado nível de controlo sobre o processo, caso determine, por exemplo, que as suas cargas de trabalho têm de ser revertidas para a configuração do nó antigo.

Cancele (pause) uma atualização azul-verde

Quando cancela uma atualização azul/verde, pausa a atualização na fase atual. Este comando pode ser usado em todas as fases, exceto na fase de eliminação do conjunto azul. Quando cancelado, o conjunto de nós é pausado num estado intermédio com base na fase em que o pedido foi emitido.

Saiba como cancelar uma atualização do conjunto de nós.

Depois de cancelar uma atualização, pode escolher um de dois caminhos: retomar ou reverter.

Retome uma atualização azul-verde

Se determinou que a atualização pode avançar, pode retomá-la.

Se retomar, o processo de atualização continua na fase intermédia em que foi pausado. Para saber como retomar uma atualização de um node pool, consulte o artigo Retome uma atualização de um node pool.

Reverter uma atualização azul-verde

Se determinou que a atualização não deve avançar e quer reverter o conjunto de nós para o estado original, pode fazê-lo. Para saber como reverter uma atualização do node pool, consulte o artigo Reverta uma atualização do node pool.

Com o fluxo de trabalho de reversão, o processo inverte-se para repor o conjunto de nós ao estado original. O conjunto azul vai ser descoberto para que as cargas de trabalho possam ser reagendadas no mesmo. Durante este processo, o redimensionador automático de clusters pode aumentar a escala do conjunto azul conforme necessário. A piscina verde vai ser esvaziada e eliminada.

Se quiser reverter um conjunto de nós para a versão anterior depois de a atualização estar concluída, consulte o artigo Reverter conjuntos de nós.

Conclua uma atualização azul-verde

Durante a fase de teste de esforço, pode concluir uma atualização se tiver determinado que a carga de trabalho não precisa de validação adicional na nova configuração do nó e os nós antigos podem ser removidos. A conclusão de uma atualização ignora o resto da fase de teste de esforço e avança para a fase de eliminação do conjunto azul.

Para mais informações sobre como usar o comando complete, consulte o artigo Conclua uma atualização do conjunto de nós azul/verde.

Atualizações azul-verde com escalamento automático

As atualizações azul-verde com dimensionamento automático são um tipo diferente de estratégia de atualização que maximiza o tempo antes de as cargas de trabalho intolerantes a interrupções serem removidas, ao mesmo tempo que minimiza o custo. Esta estratégia deriva das atualizações azul-verde padrão. No entanto, com as atualizações azul-verde com dimensionamento automático, o GKE não esgota os nós com cargas de trabalho marcadas como não seguras para despejar durante um período máximo de sete dias após os nós serem isolados.

A secção seguinte explica quando deve escolher esta estratégia, como a implementação de atualizações azul-verde desta estratégia é diferente das atualizações azul-verde padrão e que práticas recomendadas deve seguir quando usar esta estratégia.

Para usar atualizações azul/verde com dimensionamento automático, consulte o artigo Configure atualizações azul/verde com dimensionamento automático.

Quando escolher atualizações azul-verde com dimensionamento automático para o seu ambiente

Se tiver cargas de trabalho que precisem do máximo de tempo antes da remoção, mas não precisem de ser reagendadas o mais rapidamente possível, recomendamos que escolha atualizações azul-verde com escalamento automático para os seus conjuntos de nós.

As atualizações azul-verde com ajuste de escala automático funcionam bem se estes cenários se aplicarem a si:

  • Tem cargas de trabalho em lote (incluindo preparação de IA/ML) que têm de ser executadas até à conclusão.
  • Quer minimizar o custo em comparação com as atualizações azul-verde padrão, minimizando a quantidade de nós inativos ou subutilizados.
  • Não precisa de pods para garantir o reagendamento imediato ou a reversão imediata para a configuração do nó anterior.

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

As atualizações azul-verde com dimensionamento automático, como as atualizações azul-verde padrão, continuam até à conclusão se excederem um período de manutenção. Para mais informações, consulte o artigo Como funcionam as estratégias de atualização de nós com as janelas de manutenção.

Fases das atualizações azul-verde com escalamento automático

Quando o GKE atualiza pools de nós com atualizações azul/verde com escalamento automático, as fases diferem das atualizações azul/verde padrão. Para ver as fases da estratégia de atualização padrão, consulte as fases das atualizações azul-verde.

Quando a política de atualizações azul/verde com dimensionamento automático está ativada, o GKE executa estes passos durante uma operação:

  1. O GKE cria o grupo verde. No entanto, o conjunto verde começa com zero nós. Quando o GKE despeja pods do conjunto azul numa fase posterior, o redimensionador automático de cluster aumenta o conjunto verde para executar esses pods.
  2. O GKE isola o conjunto azul.

  3. O GKE aguarda um período, que pode configurar entre zero e sete dias (com um valor predefinido de três dias). Durante este período, o GKE faz o seguinte:

  4. O GKE esgota o conjunto azul, esgotando os restantes nós do conjunto azul até 20 de cada vez em paralelo. O GKE respeita as definições de PodDisruptionBudget durante um máximo de 1 hora e as definições de terminationGracePeriodSeconds durante um máximo de 24 horas.

  5. O GKE ignora a fase de node pool de teste de resistência.

  6. O GKE elimina o grupo azul.

Práticas recomendadas para atualizações azul/verde com escalonamento automático

As secções seguintes fornecem práticas recomendadas para o cluster, o conjunto de nós e os pods, de modo a minimizar a interrupção da carga de trabalho durante as atualizações azul-verde com escalamento automático.

Configuração do cluster e do node pool

  • O GKE respeita os limites de escala automática ao aumentar a escala do conjunto verde. Defina os parâmetros --max-nodes ou --total-max-nodes suficientemente elevados para que o escalador automático do cluster possa aumentar o pool verde quando o GKE reagenda as cargas de trabalho do pool azul para o pool verde. O GKE não respeita os parâmetros --min-nodes nem --total-min-nodes quando reduz a escala do conjunto azul.
  • Configure o perfil de escala automática optimize-utilization se quiser que o GKE reduza os nós subutilizados no conjunto azul de forma mais agressiva. Para mais informações, consulte o artigo Perfis de dimensionamento automático.
  • Não atualize node pools criados com o aprovisionamento automático de nós para usar atualizações azul-verde com dimensionamento automático. Além disso, não configure o cluster para usar atualizações azul-verde com escala automática para novos node pools com aprovisionamento automático.

Configuração do agrupamento

  • Para garantir que os pods não são removidos durante a pausa antes de esvaziar o conjunto azul, adicione a anotação "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" a esses pods. Esta anotação impede que o escalador automático do cluster despeje o pod se o nó do pod estiver subutilizado.
  • Tal como nas atualizações azul-verde padrão, para garantir que os pods removidos de nós no conjunto azul só são reagendados para nós no conjunto verde, adicione um nodeSelector para a etiqueta cloud.google.com/gke-nodepool:NODE_POOL_NAME à sua carga de trabalho. Se omitir esta etiqueta e tiver outros conjuntos de nós no seu cluster, os pods desalojados podem ser agendados para nós nesses outros conjuntos de nós.

Limitações das atualizações azul/verde com escalamento automático

  • Pode cancelar e retomar as atualizações azul-verde com escalonamento automático. No entanto, não pode reverter a atualização cancelada.
  • Quando o conjunto azul é isolado e esvaziado, os pods podem ficar temporariamente impossíveis de agendar se o escalador automático do cluster não conseguir aumentar a escala do conjunto verde devido a quotas e limites ou disponibilidade de recursos, porque o conjunto verde é criado com zero nós.
  • Só pode atualizar pools de nós com atualizações azul-verde com redimensionamento automático se o painel de controlo do cluster estiver a executar a versão 1.34.0-gke.2201000 ou posterior e o redimensionador automático de clusters estiver ativado.

Quando o GKE usa atualizações azul-verde com escala automática

O GKE usa atualizações azul-verde com dimensionamento automático para os mesmos tipos de alterações que as atualizações azul-verde padrão. Para mais informações sobre os tipos de alterações para os quais o GKE usa a estratégia de atualização azul/verde padrão, consulte Quando o GKE usa atualizações azul/verde.

Como funciona o redimensionador automático de clusters com atualizações azul/verde redimensionadas automaticamente

Para configurar atualizações azul-verde com dimensionamento automático, também tem de configurar o dimensionamento automático do cluster.

Se usar atualizações azul/verde com dimensionamento automático, o dimensionamento automático do cluster faz o seguinte:

  • Durante a fase em que o GKE aguarda a drenagem do conjunto azul, o conjunto azul não é aumentado e só é reduzido pelo escalador automático do cluster quando os nós ficam subutilizados. O redimensionador automático de clusters pode reduzir o tamanho do conjunto azul para zero, sem respeitar os parâmetros --min-nodes ou --total-min-nodes. Em todas as outras fases, o escalador automático do cluster não aumenta nem reduz o conjunto azul.
  • O redimensionador automático de cluster aumenta a escala do pool verde a partir de zero nós ou diminui a escala até à definição --min-nodes, conforme necessário em todas as fases da estratégia de atualização.

Atualizações de curta duração (apenas início flexível e aprovisionamento em fila)

As atualizações de curta duração são uma estratégia de atualização de nós para utilização exclusiva com nós que usam VMs de início flexível e nós que usam aprovisionamento em fila (com 1.32.2-gke.1652000 ou posterior), que são ambos baseados no Dynamic Workload Scheduler. Para mais informações acerca dos nós que usam atualizações de curta duração, consulte o artigo Acerca da obtenção de GPUs com o programador de cargas de trabalho dinâmico.

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

Com esta estratégia, o GKE atualiza estes nós de tempo de execução limitados sem interromper as cargas de trabalho existentes. A estratégia funciona da seguinte forma:

  1. Os nós existentes são executados até serem antecipados.
  2. Os novos nós usam a nova configuração de nós.
  3. Durante um máximo de sete dias, os nós transitam da execução da configuração existente para a execução da nova configuração.

O GKE configura automaticamente esta estratégia para nós que usam VMs de início flexível. Esta estratégia não tem definições de configuração.

Quando o GKE usa atualizações de curta duração

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

Para grupos de nós e pools de nós padrão em clusters do Autopilot que usam atualizações de curta duração, o GKE usa esta estratégia em situações em que, de outra forma, seriam usadas atualizações de picos. Além das atualizações de nós (alterações de versão), o GKE usa atualizações de curta duração para outros tipos de atualizações de nós, de forma semelhante à utilização das atualizações de picos. Para mais informações, consulte o artigo Quando são usadas atualizações por picos.

O que se segue?