Nesta página, apresentamos o conceito de upgrades de cluster para clusters do Google Kubernetes Engine (GKE). Se você já sabe como os upgrades de cluster funcionam, 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 cluster, consulte Controle de versões e suporte do GKE.
O GKE realiza os seguintes tipos de upgrades de cluster, que incluem tanto upgrades do plano de controle quanto 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: os upgrades secundários ocorrem aproximadamente três vezes por ano. Para clusters do canal Extended, os upgrades secundários ocorrem apenas 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 de cluster.
Receber informações sobre upgrades de cluster
Use os recursos a seguir para detalhes sobre os upgrades atuais:
- Para informações sobre upgrades de clusters específicos, incluindo destinos de upgrade automático atuais, consulte Ter visibilidade dos upgrades de cluster.
- Para recuperar destinos gerais de upgrade automático, consulte a tabela Versões atuais. Para um mapeamento específico para a versão secundária de um cluster, consulte as notas de lançamento de Atualizações de versão.
- Consulte a programação de lançamento do GKE para uma estimativa do melhor cenário de quando as versões secundárias estão disponíveis para upgrades, e atingem o fim do suporte.
- Use notificações de cluster para ficar informado sobre eventos de upgrade, como upgrades de cluster programados (visualização)—para clusters que usam o Cloud Logging ou o Pub/Sub.
Use insights e recomendações para receber as seguintes recomendações específicas do cluster:
Controlar upgrades de cluster
Como administrador da plataforma, você quer minimizar a interrupção das cargas de trabalho, mantendo-as com bom desempenho, confiáveis e seguras. 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 cargas de trabalho.
Como parte da sua responsabilidade compartilhada com o GKE, você precisa preparar as 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:
- Canais de lançamento: escolha um canal de lançamento para receber versões de cluster com o equilíbrio escolhido de disponibilidade e estabilidade de recursos.
- Janelas de manutenção: especifique uma janela de tempo recorrente em que determinados tipos de manutenção de cluster do GKE, como upgrades, podem ocorrer.
- Exclusões de manutenção: impeça que a manutenção do cluster ocorra por um período específico.
- Orçamentos de interrupção de cluster: personalize o intervalo mínimo de tempo entre tipos específicos de upgrades de cluster, incluindo upgrades de patch ou secundários.
- Estratégias de upgrade de nós: se você estiver usando pools de nós padrão, escolha como os nós serão atualizados (upgrade súbito, azul-verde ou azul-verde com escalonamento automático (visualização)) para minimizar a interrupção das cargas de trabalho.
- Sequenciamento de lançamento: qualifique os upgrades em um ambiente de pré-produção antes que o GKE faça upgrade dos clusters de produção.
- Upgrades manuais: faça upgrade manual do cluster e execute ações como cancelar, retomar, reverter e concluir upgrades automáticos ou manuais em andamento.
Depois de aprender sobre os recursos anteriores, você poderá implementar as práticas recomendadas para fazer 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 o cluster, e preparar as cargas de trabalho.
O que são upgrades automáticos do plano de controle de cluster?
Regularmente, o GKE faz upgrade automático do control plane de um cluster para versões secundárias estáveis mais recentes e patches do Kubernetes. O GKE escolhe novas versões para o cluster com base na inscrição do canal de lançamento do cluster.
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 de planos 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 atinja o 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?
O GKE realiza upgrades automáticos de nós de cluster das seguintes maneiras, dependendo do tipo de cluster e nós:
- Para clusters do Autopilot, nós sempre são atualizados automaticamente para a versão do plano de controle.
Para clusters padrão, o GKE faz o seguinte:
- Para pools de nós padrão, por padrão, os nós são atualizados automaticamente para o destino de upgrade automático apropriado, como o plano de controle. Embora não seja recomendado, é possível desativar os upgrades automáticos de nós. Também é possível fazer upgrade manual desse tipo de pool de nós.
- Para pools de nós gerenciados pelo Autopilot , os nós são atualizados automaticamente para a versão do plano de controle ao longo do tempo. Também é possível fazer upgrade manual desse tipo de pool de nós.
Para os 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 maneira:
- 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 atinja o 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 padrão, é possível desativar os upgrades automáticos até que a versão secundária do pool de nós atinja o fim do suporte padrão.
Sempre que planejar adiar 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 atrasadas em relação à versão do plano de controle.
- Os nós não podem executar uma versão mais recente que a versão atual do plano de controle do cluster.
- Os nós não podem executar uma versão secundária que tenha atingido o 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 Extended, isso significa o fim do suporte estendido. Para verificar se uma versão secundária ainda é compatível com o 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 desvio de versão do GKE.
Upgrades automáticos de cluster para segurança e compatibilidade
Se você estiver impedindo upgrades de cluster com janelas de manutenção e exclusões ou tiver desativado upgrades automáticos de nós para um pool de nós padrão 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 dos motivos para o GKE fazer upgrade do cluster, independentemente desses bloqueadores, incluem o seguinte:
- Planos de controle de cluster que executam uma versão de fim de suporte.
- Nós de 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, upgrades e 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 padrão, 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 é um termo mais geral que se refere a qualquer tipo de mudança de plano de controle ou de nó incluindo a atualização das versões. O GKE gerencia ativamente o 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 a interrupção.
A seguir
- Saiba mais sobre os upgrades de cluster do Autopilot.
- Saiba mais sobre os upgrades de cluster Standard.
- Conheça o controle de versões e o suporte do GKE.
- Saiba mais sobre as notas de lançamento do GKE.
- Saiba como configurar upgrades automáticos de nós.