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

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

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

  • 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.

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 da página de atualizações de clusters do Autopilot.
  • Para nós de início flexível, com tecnologia do programador de cargas de trabalho dinâmico, 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.

Ao escolher uma estratégia de atualização para o conjunto de nós do cluster padrão, pode escolher o processo com o equilíbrio certo de velocidade, interrupção da carga de trabalho, mitigação de riscos e otimização de custos. Para saber mais sobre a estratégia de atualização de nós adequada para o seu ambiente, consulte os artigos Escolha atualizações rápidas e Escolha atualizações azul-verde.

Com ambas as estratégias, pode configurar as definições de atualização para otimizar o processo com base nas necessidades do seu ambiente. Para saber mais, 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 seus 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.

Escolha 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 de picos

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 adicionais de picos 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 pico, 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é os recursos estarem disponíveis. Para saber mais, 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 saber mais, consulte o artigo Atualize num ambiente com recursos limitados.

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 por picos: maxSurge=2;maxUnavailable=1.

Durante uma atualização de picos 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 só é possível despejar um pod dessas cargas de trabalho 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 o 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, o conjunto de nós pode ser agendado novamente 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 de node pool.

Reverta uma atualização de aumento

Se um conjunto de nós for deixado parcialmente atualizado, pode reverter o conjunto de nós para revertê-lo para o estado anterior. Não pode 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 estabilidade 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.

Escolha 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.

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 funcionalidades que exijam a recriação dos nós. Para saber mais, consulte o artigo Quando são usadas atualizações por picos de procura.

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 ecológicos.

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 de cordon bleu

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 grupo azul e eliminar o grupo verde.

Fase 3: esvazie a piscina 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, os pedidos de despejo são enviados a todos os pods em execução no nó. Os Podcasts são reagendados. Os pods que tenham violações do PodDisruptionBudget ou um terminationGracePeriodSeconds longo durante a drenagem são eliminados na fase Delete blue pool 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 a predefinição 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 conjunto 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 diminuir 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 eliminação dos restantes pods, os nós do conjunto azul 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.

Reverta 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 de node pool, consulte o artigo Reverta uma atualização de 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 grupo 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 carga, pode concluir uma atualização se tiver determinado que a carga de trabalho não precisa de validação adicional na nova configuração de nós 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 saber como usar o comando complete, consulte o artigo Conclua uma atualização do conjunto de nós azul/verde.

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 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 saber mais acerca dos nós que usam atualizações de curta duração, consulte o artigo Acerca da disponibilidade de GPUs com o Dynamic Workload Scheduler.

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 fazem a transição 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 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 de início flexível para usar 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 de procura.

O que se segue?