Upgrades de cluster padrão


Nesta página, você verá como upgrades automáticos e manuais funcionam em clusters padrão do Google Kubernetes Engine (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.

Para mais informações sobre como os upgrades de cluster funcionam no Autopilot, consulte esta página.

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. Ele observa upgrades automáticos e manuais em todos os clusters do GKE e intervém se forem apresentados problemas.

Se você inscrever o cluster em um canal de lançamento, os nós sempre executarão a mesma versão do GKE que o cluster. Isso só não ocorre durante um breve período (geralmente alguns dias, dependendo da versão atual) entre a conclusão do upgrade do plano de controle do cluster e o início do upgrade do pool de nós. Veja as notas da versão para mais informações.

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 têm apenas um único plano de controle. 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.

  • 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. Por padrão, os nós em um pool são atualizados um de cada vez, em uma ordem indefinida. É possível alterar o número de nós atualizados por vez.

Durante um upgrade do pool de nós, não é possível fazer alterações na configuração do cluster, a menos que você cancele o upgrade.

Esse processo pode levar várias horas, dependendo do número de nós e das configurações da carga de trabalho. As configurações que podem diminuir a taxa de upgrades de nós incluem:

O GKE cumpre janelas ou exclusões de manutenção durante os upgrades automáticos quando possível Os upgrades manuais ignoram as janelas e exclusões de manutenção configuradas.

Quando o GKE faz upgrade de um nó, acontece o seguinte:

  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 plano de controle.
  2. O GKE seleciona um nó atual (o 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.
    • O PodDisruptionBudget é respeitado por até uma hora. Se o nó de destino não for totalmente drenado após uma hora, o GKE excluirá os pods restantes e o processo de upgrade continuará.
    • O GracefulTerminationPeriod é limitado a uma hora.
  3. O plano de controle reprograma os pods gerenciados por controladores em outros nós. Os pods que não podem ser reprogramados permanecem na fase Pendente até que possam ser programados.
  4. Se um nó de sobretensão tiver sido criado, 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 depois que ele for drenado e aguardará o registro do nó atualizado com o plano de controle.

Como fazer upgrades automaticamente

Quando você cria um cluster padrão, o upgrade automático é ativado no cluster e nos pools de nós dele.

O Google é responsável por proteger o plano de controle do cluster e fazer upgrade dos clusters quando uma nova versão do GKE for selecionada para upgrade automático. A segurança da infraestrutura é alta prioridade para o GKE e, como tal, planos de controle são atualizados regularmente e não pode ser desativada. No entanto, é possível aplicar janelas de manutenção e exclusõespara suspender temporariamente os upgrades de planos de controle e nós.

No modelo de responsabilidade compartilhada, você é responsável pela proteção dos nós, contêineres e pods. O upgrade automático de nós é ativado por padrão. Embora não seja recomendado, é possível desativar o upgrade automático do nós. A desativação dos upgrades automáticos de nós não bloqueia o upgrade do plano de controle do cluster. Ao desativar os upgrades automáticos de nós, você é responsável por garantir que os nós do cluster executem uma versão compatível com a versão do cluster e que ela esteja em conformidade com a versão do Kubernetes e a política de suporte de diferença de versão (em inglês).

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ê inscrever o cluster em um canal de lançamento, os nós sempre executarão a mesma versão do GKE que o cluster, exceto durante um breve período (geralmente alguns dias, dependendo do versão atual) 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. Veja as notas da versão para mais informações.

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 imediatamente. Quando uma versão do GKE acumular uso de cluster suficiente para comprovar a estabilidade, o Google a selecionará como um objetivo de 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 de lançamento. 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 executando 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.

Com os 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 para preservar a segurança da infraestrutura. 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, o plano de controle fica indisponí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 o número de nós que o GKE tenta fazer upgrade ao mesmo tempo, mude os parâmetros de upgrade súbito em um pool de nós. Upgrades súbitos 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 súbitos também funcionam com o escalador automático de cluster para impedir alterações nos nós que estão passando por um upgrade.

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 5 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 diminui, 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. Para aprender e testar o Upgrade de sobretensão , concluia 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 (padrão), 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 (padrão)

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 novos nós de sobretensão 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, consulte Upgrades de nós e cotas.

Como o GKE responde a falhas de upgrade automático

Os upgrades automáticos do pool de nós podem falhar devido a problemas com as instâncias subjacentes do Compute Engine ou por questões com o Kubernetes. Por exemplo, os upgrades automáticos falham nas seguintes situações:

  • A configuração de maxSurge definida excede sua cota de recursos do Compute Engine.
  • Novos nós de sobretensão não foram registrados no plano de controle do cluster.
  • Os nós demoraram muito para serem drenados ou demoraram muito para serem excluídos.

Quando ocorrem problemas com upgrades de nó individuais, o GKE repete o upgrade algumas vezes, com um intervalo crescente entre as novas tentativas. Se os nós no pool de nós não forem atualizados, o GKE não reverterá os nós atualizados. Em vez disso, o GKE tentará o upgrade automático do pool de nós novamente até que todos os nós sejam atualizados com sucesso.

Se os upgrades de nó falharem porque as solicitações de nó de sobretensão excedem a cota do Compute Engine, o GKE reduz o número de nós de sobretensão simultâneos para tentar atingir a cota e continuar o upgrade.

Como receber notificações de upgrade

O GKE publica notificações de upgrade no Pub/Sub, fornecendo um canal para receber informações do GKE sobre seus clusters.

Para mais informações, consulte Como receber notificações de upgrade de cluster.

A seguir