Upgrades de cluster

Nesta página, você verá como upgrades automáticos e manuais funcionam em clusters do GKE, incluindo links para mais informações sobre tarefas e configurações relacionadas. Use essas informações para manter seus clusters atualizados e ter estabilidade e segurança com interrupções mínimas nas cargas de trabalho.

Como funcionam os upgrades de pools de nós e de cluster

Nesta seção, você verá o que acontece no cluster durante upgrades automáticos ou manuais. Os upgrades automáticos são iniciados pelo Google. O Google observa os upgrades automáticos e manuais em todos os clusters do GKE e intervém em caso de problemas.

Um cluster é atualizado antes dos nós.

Upgrades de cluster

Nesta seção, você verá o que esperar quando o Google fizer o upgrade automático do cluster ou quando você iniciar um upgrade manual.

  • Os clusters zonais e de várias zonas têm apenas um único plano de controle (mestre). Durante o upgrade, as cargas de trabalho continuarão em execução, mas não será possível implantar novas cargas de trabalho, modificar as atuais nem fazer outras alterações na configuração do cluster até que o upgrade seja concluído.

  • Os clusters regionais têm várias réplicas do plano de controle e apenas uma é atualizada por vez, em uma ordem indefinida. Durante o upgrade, o cluster permanece altamente disponível, e cada réplica do plano de controle fica indisponível apenas durante a atualização.

Se você configurar uma janela ou exclusão de manutenção, ela será respeitada, se possível.

Upgrades de pool de nós

Seu cluster e os respectivos pools de nós não executam necessariamente a mesma versão do GKE. Nesta seção, você verá o que esperar quando o Google fizer o upgrade automático ou iniciar um upgrade manual do pool de nós.

Os pools de nós são atualizados um de cada vez. Em um pool de nós, os nós são atualizados individualmente, em uma ordem indefinida. É possível alterar o número de nós atualizados por vez.

Se você configurar uma janela ou exclusão de manutenção, ela será respeitada, se possível.

Ao fazer upgrade de um nó, as seguintes situações acontecem:

  1. Se os upgrades de sobretensão estiverem ativados, o GKE criará um novo nó de sobretensão com a versão atualizada e aguardará até que ele seja registrado no mestre.
  2. O GKE seleciona um nó atual (que chamaremos de nó de destino) para fazer o upgrade. Ele estabelece um limite e começa a drenar o nó de destino. Neste ponto, o GKE não pode programar novos pods no nó de destino.
  3. Os pods no nó de destino são reprogramados para outros nós. Se não for possível reprogramar um pod, ele permanecerá PENDING até ser reprogramado.
  4. Se um nó de sobretensão tiver sido criado na etapa 1, o nó de destino será excluído. Se um nó de sobretensão não tiver sido criado, o GKE atualizará o nó de destino e aguardará o registro dele.
  5. Se um número significativo de upgrades automáticos de nó para uma determinada versão resultar em nós não íntegros na frota do GKE, esses upgrades serão interrompidos durante a investigação do problema.

Como fazer upgrades automaticamente

Ao criar um cluster usando o Console do Google Cloud, o upgrade automático estará ativado nele e nos pools de nós por padrão, e o Google atualizará os clusters quando uma nova versão do GKE for selecionada para upgrade automático.

Ao criar um cluster usando o comando gcloud ou a API GKE, o upgrade automático de nós estará ativado por padrão. Para desativá-lo manualmente, consulte Como atualizar os nós automaticamente.

Para ter mais controle sobre o momento em que um upgrade automático poderá, ou não, ocorrer, configure janelas e exclusões de manutenção.

Os pools de nós de um cluster não podem estar mais de duas versões secundárias atrás da versão do plano de controle para manter a compatibilidade com a API do cluster. A versão do pool de nós também determina as versões dos pacotes de software instalados em cada nó. É recomendável manter os pools de nós atualizados com a versão do cluster.

Se você registrar o cluster em um canal de lançamento, os nós sempre executarão a mesma versão do GKE, exceto durante um breve período entre a conclusão do upgrade do plano de controle do cluster e o início do upgrade de um determinado pool de nós.

Como as versões são selecionadas para o upgrade automático

Novas versões do GKE são lançadas regularmente, mas uma versão não é selecionada para upgrade automático de imediato. Quando uma versão do GKE acumular uso de cluster suficiente para comprovar a estabilidade, o Google a selecionará como destino do upgrade automático para clusters que executam um subconjunto de versões mais antigas.

Novos destinos de upgrade automático são anunciados nas notas da versão. Até que uma versão disponível seja selecionada para o upgrade automático, será possível fazer upgrade para ela manualmente. Às vezes uma versão é selecionada para upgrade automático de cluster e de nó durante semanas diferentes.

Logo depois que uma nova versão secundária for disponibilizada, a versão secundária mais antiga disponível não será mais compatível. Os clusters que executam versões secundárias que se tornam incompatíveis são automaticamente atualizados para a próxima versão secundária.

Em uma versão secundária (como v1.14.x), os clusters podem ser atualizados automaticamente para uma nova versão de patch.

Graças aos canais de lançamento, é possível controlar a versão do cluster e do pool de nós com base na estabilidade de uma versão, em vez de gerenciá-la diretamente.

Como configurar o momento em que os upgrades automáticos podem ocorrer

Por padrão, os upgrades automáticos podem ocorrer a qualquer momento. Eles são minimamente disruptivos, especialmente para clusters regionais. Porém, algumas cargas de trabalho podem exigir um controle mais preciso. É possível configurar janelas e exclusões de manutenção para gerenciar o momento em que os upgrades automáticos podem, ou não, ocorrer.

Como fazer upgrade manualmente

É possível solicitar o upgrade manual do cluster ou dos respectivos pools de nós para uma versão compatível e disponível a qualquer momento. Os upgrades manuais ignoram as janelas e exclusões de manutenção configuradas.

Ao fazer upgrade de um cluster manualmente, a disponibilidade dele varia se ele for regional ou não:

  • Para clusters zonais e de várias zonas, o plano de controle fica disponível durante o upgrade. Na maioria das vezes, as cargas de trabalho são executadas normalmente, mas não podem ser modificadas durante o upgrade.

  • Para clusters regionais, durante o upgrade, uma réplica do plano de controle fica indisponível por vez, mas ele permanece altamente disponível.

É possível iniciar um upgrade de nó manualmente para uma versão compatível com o plano de controle.

Upgrades de sobretensão

Os upgrades de sobretensão permitem controlar o número de nós que o GKE pode atualizar por vez e controlar os upgrades que causam interrupções nas suas cargas de trabalho.

Como alterar as configurações de upgrade para equilibrar a velocidade e a interrupção

Para controlar quantos nós o GKE tenta atualizar ao mesmo tempo, altere os parâmetros do upgrade de sobretensão em um pool de nós. Upgrades de sobretensão reduzem as interrupções nas cargas de trabalho durante a manutenção do cluster e também permitem controlar o número de nós atualizados em paralelo. Os upgrades de sobretensão também funcionam com o escalonador automático de cluster para impedir alterações nos nós que estão sendo atualizados.

Os upgrades de sobretensão são determinados por duas configurações:

max-surge-upgrade

O número de nós que podem ser adicionados ao pool de nós durante um upgrade. Aumentar max-surge-upgrade eleva o número de nós que podem ser atualizados simultaneamente. O padrão é 1. Ele pode ser definido como 0 ou maior.

max-unavailable-upgrade

O número de nós que podem estar indisponíveis simultaneamente durante um upgrade. O padrão é 0. Aumentar max-unavailable-upgrade eleva o número de nós que podem ser atualizados em paralelo.

O número de nós atualizados simultaneamente é a soma de max-surge-upgrade e max-unavailable-upgrade. O número máximo de nós atualizados simultaneamente é 20.

Por exemplo, um pool de cinco nós é criado com max-surge-upgrade definido como 2 e max-unavailable-upgrade definido como 1. Durante um upgrade do pool de nós, o GKE cria dois nós atualizados. Ele reduzirá, no máximo, três (a soma de max-surge-upgrade e max-unavailable-upgrade) nós atuais depois que os nós atualizados estiverem prontos. O GKE tornará, no máximo, um nó indisponível (max-unavailable-upgrade) por vez. Durante o processo de upgrade, o pool de nós incluirá entre quatro e sete nós.

É possível configurar os parâmetros de upgrade de sobretensão para pools de nós que usam os upgrades automáticos e os upgrades manuais. Aprenda e teste o Upgrade de sobretensão concluindo o tutorial "Usar upgrades de sobretensão para diminuir as interrupções de upgrades de nós do GKE" (em inglês).

Como determinar a configuração ideal de sobretensão

Na tabela a seguir, descreve três configurações de upgrade diferentes como uma demonstração para ajudar você a entender configurações distintas:

Descrição Configuração
Balanceado, mais lento, mas menos prejudicial maxSurge=1 maxUnavailable=0
Rápido, sem recursos de sobretensão, mais interruptivo maxSurge=0 maxUnavailable=20
Rápido, a maioria dos recursos é de sobretensão e é menos interruptivo maxSurge=20 maxUnavailable=0

Balanceado

A maneira mais simples de aproveitar o upgrade de sobretensão é configurar maxSurge=1 maxUnavailable=0.. Isso significa que apenas um nó de sobretensão pode ser adicionado ao pool de nós durante um upgrade para que apenas um nó seja atualizado por vez. Essa configuração é superior à configuração de atualização atual (maxSurge=0 maxUnavailable=1), porque acelera os reinícios do pod durante os upgrades e progride de maneira conservadora.

Rápido e sem recursos de sobretensão

Se a carga de trabalho não for sensível a interrupções, como a maioria dos jobs em lote, será possível enfatizar a velocidade usando maxSurge=0 maxUnavailable=20. Essa configuração não exibe nós de sobretensão adicionais e permite que 20 nós sejam atualizados ao mesmo tempo.

Rápido e menos interruptivo

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.

Relação com a cota

Ainda que a recriação de nós não exija recursos extras do Compute Engine, o upgrade de nós exige. A alocação de recursos está sujeita à cota do Compute Engine. Dependendo da configuração, essa cota pode limitar o número de upgrades paralelos ou causar falha no upgrade.

Para mais informações sobre cotas, acesse Upgrades de nós e cotas

A seguir