Sobre os upgrades de cluster do GKE

Nesta página, apresentamos o conceito de upgrades de cluster para clusters do Google Kubernetes Engine (GKE). Se você já conhece o funcionamento dos upgrades de cluster, consulte implementar as práticas recomendadas para fazer upgrade de clusters.

O que são upgrades de cluster?

Um cluster do Kubernetes no GKE é composto por um plano de controle e nós de trabalho, que executam cargas de trabalho do usuário. O plano de controle e os nós de trabalho executam uma versão do Kubernetes. O GKE faz upgrade automático da versão do plano de controle e dos nós para garantir que o cluster receba novos recursos, correções de bugs e patches de segurança. Para saber mais sobre como o GKE escolhe a versão do seu cluster, consulte Controle de versões e suporte do GKE.

O GKE realiza os seguintes tipos de upgrades de cluster, que incluem upgrades do plano de controle e upgrades de nós:

  • Upgrades de versão de patch: o GKE faz upgrade automático dos clusters para um novo patch com frequência semanal, dependendo do canal de lançamento.
  • Upgrades de versão secundária: ocorrem aproximadamente três vezes por ano. Para clusters do canal estendido, os upgrades secundários ocorrem somente quando a versão secundária se aproxima do fim do suporte estendido.

Para clusters não inscritos em um canal de lançamento, o GKE também faz upgrade automático do plano de controle e dos nós. Para saber como o GKE escolhe os destinos de upgrade automático para esses clusters, consulte a linha Tempo de upgrade em uma tabela que compara clusters inscritos e não inscritos em um canal de lançamento.

Também é possível fazer upgrade manual do plano de controle e dos nós de um cluster para uma versão disponível, em vez de o GKE realizar um upgrade automático. Use os recursos do GKE para escolher quando e como o GKE faz upgrade dos clusters. Para saber mais, consulte Controlar upgrades do cluster.

Receber informações sobre upgrades de cluster

Use os seguintes recursos para saber detalhes sobre os upgrades atuais:

Controlar upgrades de cluster

Como administrador de plataforma, você quer minimizar a interrupção das cargas de trabalho, mantendo o desempenho, a confiabilidade e a segurança delas. A responsabilidade do GKE como parte do modelo de responsabilidade compartilhada do GKE é fazer upgrade do cluster para mantê-lo em execução e atender às suas cargas de trabalho.

Como parte da responsabilidade compartilhada com o GKE, você precisa preparar suas cargas de trabalho para upgrades de cluster. Não é possível desativar completamente os upgrades automáticos, mas é possível controlar quando e como o GKE realiza os upgrades.

Para gerenciar upgrades de cluster do GKE otimizados para suas cargas de trabalho, use os seguintes recursos:

Depois de aprender sobre os recursos anteriores, você poderá implementar as Práticas recomendadas para upgrade de clusters.

Para maximizar a disponibilidade da carga de trabalho, use também as recomendações e técnicas descritas em gerenciar e monitorar seu cluster e preparar suas cargas de trabalho.

O que são upgrades automáticos do plano de controle de cluster?

Regularmente, o GKE faz upgrade automático do plano de controle de um cluster para versões secundárias e patches estáveis mais recentes do Kubernetes. O GKE escolhe novas versões para seu cluster com base no registro do canal de lançamento.

Em toda a frota de clusters do GKE, os upgrades automáticos costumam ser realizados em etapas ao longo de várias semanas. Como a segurança da infraestrutura é uma alta prioridade para o GKE, os upgrades do plano de controle acontecem regularmente e não podem ser desativados.

Embora não seja possível desativar os upgrades do plano de controle, é possível usar exclusões de manutenção para impedir temporariamente todos os upgrades do plano de controle, incluindo upgrades secundários e de patch, por até 30 dias, independentemente de o cluster estar inscrito em um canal de lançamento. Para clusters inscritos em um canal de lançamento, é possível impedir upgrades de versão secundária até que a versão secundária chegue ao fim do suporte.

É possível usar janelas de manutenção para definir um período recorrente em que o GKE pode fazer upgrade do plano de controle.

O que são upgrades automáticos de nós de cluster?

Nos clusters do Autopilot, os nós são sempre atualizados automaticamente para a versão do plano de controle. Nos clusters Standard, por padrão, os nós são atualizados automaticamente para a versão do plano de controle.

Nos dois modos de clusters, é possível usar janelas de manutenção e exclusões para controlar o tempo e o escopo dos upgrades de nós, da seguinte forma:

  • Para clusters inscritos em um canal de lançamento, é possível usar exclusões de manutenção para impedir upgrades automáticos de nós até que a versão secundária dos nós chegue ao fim do suporte.
  • Para clusters padrão não inscritos em um canal de lançamento, no nível do cluster, é possível impedir upgrades automáticos de nós por até 30 dias. No nível do pool de nós, é possível desativar os upgrades automáticos até que a versão secundária do pool de nós chegue ao fim do suporte padrão.

Ao planejar o adiamento dos upgrades automáticos de nós, considere as seguintes restrições para os nós de um cluster do GKE:

  • Os nós não podem estar mais de duas versões secundárias atrás da versão do plano de controle.
  • Os nós não podem executar uma versão mais recente que a do plano de controle atual do cluster.
  • Os nós não podem executar uma versão secundária que chegou ao fim do suporte. Para clusters na maioria dos canais de lançamento, isso significa o fim do suporte padrão. Para clusters inscritos no canal estendido, isso significa o fim do suporte estendido. Para verificar se uma versão secundária ainda tem suporte no canal do cluster, consulte a Programação estimada para canais de lançamento.

Para mais detalhes sobre essas restrições, consulte a política de distorção de versão do GKE.

Upgrades automáticos de cluster para segurança e compatibilidade

Se você estiver impedindo upgrades de cluster com janelas e exclusões de manutenção ou tiver desativado os upgrades automáticos de nós para um pool de nós específico quando o cluster não estiver inscrito em um canal de lançamento, o GKE poderá fazer upgrade automático do cluster para fins de segurança e compatibilidade em determinados casos. Alguns motivos para o GKE fazer upgrade do cluster, mesmo com esses bloqueios, incluem:

  • Planos de controle de cluster que executam uma versão de fim de suporte.
  • Nós do cluster que executam versões de fim de suporte.
  • Clusters em estado de looping, definidos como clusters com estados de looping de execução para degradado, em reparação ou suspensos e de volta à execução.

Para mais detalhes, consulte Upgrades automáticos no fim do suporte e Uma plataforma gerenciada e responsabilidade compartilhada.

Upgrades e atualizações com o gerenciamento do ciclo de vida do cluster do GKE

No GKE, os upgrades e as atualizações de cluster têm significados relacionados.

No GKE, o termo upgrades de cluster, ou apenas upgrades, se refere à atualização da versão do Kubernetes do plano de controle (upgrades do plano de controle) ou dos nós (upgrades de nós), ou ambos. Ao usar clusters Standard, os upgrades de nós também podem ser chamados de upgrades de pool de nós porque o GKE usa uma única operação para fazer upgrade de um pool de nós.

O termo atualizações de cluster, ou apenas atualizações, é mais geral e se refere a qualquer tipo de mudança no plano de controle ou nos nós, incluindo a atualização das versões. O GKE gerencia ativamente seu ambiente de cluster realizando upgrades, outros tipos de atualizações e operações de manutenção necessárias. Essas ações garantem que o cluster permaneça com bom desempenho, seguro e atualizado com os recursos e correções de bugs mais recentes. O GKE usa ferramentas como estratégias de upgrade de nós e políticas de manutenção para minimizar a interrupção durante esses processos.

Para saber mais sobre como gerenciar todas as mudanças no ciclo de vida do cluster, incluindo upgrades, consulte Gerenciar mudanças no ciclo de vida do cluster para minimizar interrupções.

A seguir