Nesta página, explicamos o controle de versão no Google Kubernetes Engine (GKE) e as políticas de suporte à versão. Com o tempo, o GKE faz upgrade dos clusters para versões mais recentes do Kubernetes. Para saber mais sobre como os upgrades funcionam, consulte Sobre upgrades de cluster do GKE.
É possível conferir a programação de lançamentos e o suporte atuais na programação de lançamentos do GKE.
Compatibilidade das versões
A compatibilidade do GKE com versões secundárias do Kubernetes é baseada em políticas de código aberto do Kubernetes. O GKE é compatível com uma versão secundária, fornecendo versões patch do mesmo lançamento secundário e, regularmente, fazendo upgrade automático dos clusters para os patches mais recentes.
Como o Kubernetes oferece suporte a uma versão secundária
Atualmente, a comunidade de software de código aberto (OSS) lança uma versão secundária com novos recursos e melhorias três vezes por ano. Cada ciclo de lançamento tem aproximadamente 15 semanas.
O Kubernetes é compatível com cada versão secundária por 14 meses. Os principais bugs e vulnerabilidades de segurança encontrados em uma versão secundária compatível são corrigidos com o lançamento de uma versão de patch ad hoc. Às vezes, a comunidade do Kubernetes revisa o calendário de compatibilidade com a versão, conforme necessário. Para saber mais, consulte Período de suporte.
Como o GKE oferece suporte a uma versão secundária
Depois que o Kubernetes lança uma nova versão secundária, o GKE apresenta a versão secundária no Canal rápido. O GKE oferece versões de patch durante esse período, mas como o Canal rápido oferece as mais novas versões do GKE, essas versões são excluídas do SLA do GKE e podem conter problemas sem alternativas conhecidas.
Após a disponibilidade inicial no Canal rápido, o GKE promove a nova versão secundária para o Canal normal. O GKE oferece até um total de 24 meses de compatibilidade para uma versão secundária após ela ser disponibilizada para a criação de novos clusters no Canal normal. Esse suporte inclui cerca de 14 meses de suporte padrão e aproximadamente mais 10 meses de suporte estendido disponível no Canal estendido. Para conferir a disponibilidade de versões secundárias específicas, consulte Programação de lançamento do GKE.
Ciclo de vida da versão secundária do GKE
O ciclo de vida de uma versão secundária do GKE inclui as principais etapas:
- O Kubernetes lança uma nova versão secundária.
- O GKE disponibiliza a nova versão secundária no Canal rápido.
- O GKE disponibiliza a nova versão secundária no Canal normal (início do período de suporte padrão).
- Durante o período de suporte padrão, o GKE fornece patches para a versão secundária, que inclui novos recursos, correções de segurança e de bugs.
- A versão secundária chega ao fim do suporte padrão após aproximadamente 14 meses no total, entrando no período de suporte estendido. Depois disso, o GKE fornece patches de segurança para clusters no Canal estendido.
- A versão secundária chega ao fim do suporte estendido, o que significa que a versão secundária não receberá mais patches de segurança.
Ajustes de disponibilidade de versão
O GKE pode revisar o fim do suporte a versões do GKE devido a mudanças na política na comunidade de OSS do Kubernetes, a descoberta de vulnerabilidades ou outros problemas técnicos que não podem ser resolvidos. O GKE também pode estender as datas de fim de suporte relacionadas a períodos comerciais principais, como Black Friday e Cyber Monday.
O GKE oferece pelo menos 14 meses de suporte padrão e até um total de 24 meses de suporte com suporte estendido.
Para acessar as versões mais recentes disponíveis, consulte as notas da versão do GKE. O GKE regularmente atualiza a programação de lançamentos para refletir a data dos upgrades automáticos.
Períodos de disponibilidade no ciclo de vida da versão secundária
O GKE oferece os seguintes períodos de disponibilidade para uma versão secundária do Kubernetes:
Consulte a tabela a seguir, resumindo os períodos de disponibilidade, descritos em detalhe nas próximas seções:
| Período de disponibilidade | Período aproximado da disponibilidade do Canal normal | Que tipo de suporte o GKE oferece? | Acesso a este período de disponibilidade |
|---|---|---|---|
| Período de disponibilidade somente rápido | Do mês -1 ao mês 0 | O GKE fornece versões de patch com novos recursos, correções de segurança e de bugs. No entanto, essas versões são excluídas do SLA do GKE e podem conter problemas sem soluções alternativas conhecidas. | Somente Canal rápido |
| Período de suporte padrão | Do mês 1 ao mês 14 | O GKE fornece versões de patch com novos recursos, correções de segurança e de bugs. | Rápido, normal, estável, estendido, sem canal |
| Período de suporte estendido | Do mês 15 ao mês 24 | O GKE fornece versões de patch com correções de segurança. | Somente canal estendido (requer GKE Enterprise ou taxa adicional por cluster. Consulte Receber suporte de longo prazo com o Canal estendido) |
Período de disponibilidade rápida
Primeiro, o GKE lança uma nova versão secundária no Canal rápido. Primeiro, a versão acumula uso e demonstra estabilidade entre clusters neste canal antes de serem promovidos para o Canal normal. Somente os clusters inscritos no Canal rápido podem executar uma nova versão secundária durante esse período de disponibilidade.
Esse período geralmente dura de um a dois meses, mas o tempo exato depende de cada versão secundária. Para mais detalhes, consulte Programação estimada para canais de lançamento.
Período de suporte padrão
O período de suporte padrão para uma versão secundária do GKE começa quando a versão for lançada para o Canal normal. Todo os clusters do GKE, independentemente do registro do canal de lançamento, podem executar uma versão secundária no suporte padrão. Durante esse período, o GKE faz upgrades automaticamente dos clusters com frequência para novas versões de patch, que incluem novos recursos, correções de segurança e de bugs.
O GKE faz upgrade dos clusters automaticamente da seguinte maneira:
- Rápido, normal, estável, sem canal: upgrades automáticos para outras versões secundárias compatíveis ou versões de patch da mesma versão secundária.
- Estendido: o GKE só faz o upgrade automático para versões de patch mais recentes da mesma versão secundária.
Para clusters não inscritos no canal de lançamento estendido, o GKE eventualmente fará upgrade automático dos clusters para a próxima versão secundária compatível antes do fim do suporte padrão, com base na programação do canal de lançamento do cluster. Para mais detalhes, consulte Programação estimada para canais de lançamento. No entanto, o GKE não faz upgrade dos clusters durante esse período se eles usarem recursos ou APIs descontinuados. Você pode usar uma exclusão de manutenção para impedir temporariamente que o GKE faça upgrade do cluster para a próxima versão secundária.
Fim do suporte padrão (anteriormente fim da vida útil)
Após o período de suporte padrão, a versão secundária chega ao fim do suporte padrão (anteriormente conhecido como fim da vida útil) e se torna incompatível e indisponível para todos os clusters que não estão inscritos no Canal estendido.
Os clientes que executam uma versão de fim de suporte são notificados por e-mail para o contato do projeto antes do fim do suporte de uma versão. O GKE também começa a fazer upgrade automático dos nós gradualmente (independentemente da ativação) executando versões sem suporte para fins de segurança e compatibilidade porque não são fornecidos novos patches de segurança ou correções de bugs para versões em fim de suporte. Antes de interagir com o Cloud Customer Care para qualquer problema com um cluster ou nós que executem uma versão em fim de suporte, primeiro é necessário fazer upgrade do cluster e dos nós para uma versão compatível.
As versões secundárias do GKE que chegaram ao fim do suporte não estão mais disponíveis para receber patches de segurança ou correções de bugs. Versões de patch de uma versão secundária que chegou ao fim do suporte não são compatíveis e estão indisponíveis. O GKE faz upgrade automaticamente de todos os clusters não registrados no Canal estendido. Para saber mais, consulte Upgrades automáticos no fim suporte.
Período de suporte estendido
Após o fim do suporte padrão, a versão secundária atinge o período de suporte estendido (mês 15 até mês 24). Durante esse período, o GKE fornece patches para correções de segurança, incluindo os seguintes tipos de correções:
- Patches de segurança médios, altos e críticos para os principais componentes do Kubernetes sistema operacional de nó e contêineres gerenciados pelo Google com a versão do cluster do GKE.
- Para o Container-Optimized OS, o fim do suporte do sistema operacional do nó pode vir antes do fim do suporte estendido para a versão secundária do GKE ou introduzir alterações incompatíveis. Para saber mais sobre como o GKE continua a oferecer suporte, consulte as Atualizações do Container-Optimized OS durante o período de suporte estendido.
Perto do fim do suporte estendido, o GKE começa a fazer upgrade dos clusters para a próxima versão secundária. O GKE não vai fazer upgrade dos clusters se estiverem usando APIs ou recursos descontinuados. É possível usar uma exclusão de manutenção para impedir temporariamente que o GKE faça upgrade do cluster para a próxima versão secundária.
Fim do suporte estendido
Ao fim do suporte estendido, o GKE não fornece patches para correções de segurança, e a versão secundária é considerada incompatível. Os clusters de upgrade do GKE ainda estão executando a versão secundária não compatível para a próxima versão secundária, seja qual for o uso do cluster de recursos ou APIs descontinuados.
Upgrades automáticos após o fim do suporte
O GKE programa upgrades automáticos para clusters de uma versão secundária para a próxima versão secundária compatível antes que a versão secundária chegue ao fim do suporte. A duração desse upgrade depende da programação do canal de lançamento do cluster. Para mais detalhes, consulte Programação estimada para canais de lançamento. Por exemplo, os clusters registrados no Canal estável recebem upgrade para a próxima versão secundária mais próxima do fim do suporte padrão do que os clusters inscritos no Canal rápido.
Durante o período de suporte padrão e estendido para clusters inscritos no Canal estendido, você pode evitar esse upgrade de versão secundária com uma exclusão de manutenção, e o GKE não vai fazer upgrade de clusters usando APIs ou recursos descontinuados.
No entanto, ao fim do suporte padrão ou ao fim do suporte estendido para clusters registrados no Canal estendido, o GKE faz upgrade automaticamente dos clusters para a próxima versão secundária com suporte, a fim de garantir que o cluster permaneça com bom desempenho, disponível e seguro.
Cada versão do GKE tem 14 meses de suporte padrão e 24 meses de suporte total, incluindo suporte estendido. Não é possível manter o cluster em uma versão indefinidamente, porque a operação dele usando uma versão sem suporte do GKE tem risco de segurança, confiabilidade e compatibilidade significativo, já que o GKE não fornece patches de segurança ou correções de bugs para versões em fim de suporte. O GKE não pode se comprometer a fornecer patches ou atualizações para as versões ao final do suporte.
O GKE faz upgrade do cluster da seguinte maneira:
- Plano de controle: o GKE faz upgrade automaticamente dos planos de controle do cluster para versões compatíveis quando a versão do plano de controle não estiver mais disponível para a criação de novos clusters.
- Nós: o GKE faz upgrade automaticamente dos nós que estão executando uma versão sem suporte após ela chegar ao fim do suporte para garantir a integridade e o alinhamento do cluster com a política de desvio de versão do GKE. Os nós executando versões incompatíveis são programados para um upgrade automático para uma versão compatível no prazo de um mês após a data de fim do suporte. Os nós que executam versões sem suporte não podem ser atualizados imediatamente após o fim da vida útil da versão, e o tempo real pode variar a critério do Google.
Identificar clusters que executam uma versão secundária após o fim do suporte padrão
O GKE identifica clusters que atendem a ambas as condições a seguir:
- O plano de controle executa uma versão secundária que chegou ao fim do suporte padrão.
- O cluster não está registrado no canal Extended.
O GKE recomenda fazer upgrade desses clusters devido aos riscos associados à execução de uma versão secundária sem suporte. O GKE faz upgrade dos clusters para a próxima versão secundária com suporte se a versão atual não tiver suporte no canal de lançamento do cluster.
O GKE oferece essa orientação com um insight e uma recomendação pelo serviço Recommender. Essas orientações não se aplicam a clusters inscritos no canal estendido, que podem continuar executando uma versão secundária até o fim do suporte estendido. Para saber mais sobre como gerenciar insights e recomendações do Recommender, consulte Otimizar o uso do GKE com insights e recomendações.
Para encontrar clusters em que o plano de controle está executando uma versão após o fim do suporte, use uma destas maneiras:
- Use o console do Google Cloud.
- Use a CLI gcloud ou a API Recommender especificando o
subtipo de
recomendador
CLUSTER_VERSION_END_OF_LIFE.
Para mais instruções, consulte como ver insights e recomendações.
Para implementar essa recomendação, faça upgrade do plano de controle do cluster para uma versão secundária com suporte. Para conferir as versões secundárias com suporte e as datas de término do suporte, consulte a programação de lançamentos do GKE. Ou mude o cluster para o canal estendido se você quiser continuar usando a versão secundária atual até o fim do suporte estendido.
Atualizações do Container-Optimized OS durante o período estendido de suporte
Durante o período de suporte estendido de uma versão secundária do GKE, o GKE fornece upgrades de patch para o cluster, que podem incluir atualizações do Container-Optimized OS.
A versão do LTS do Container-Optimized OS chega ao fim do suporte antes da versão secundária
A versão do LTS do Container-Optimized OS pode chegar ao fim do suporte antes do fim do suporte estendido da versão secundária usando a versão. Nesse cenário, o GKE usa a próxima versão do Container-Optimized OS LTS disponível para upgrades de patches, se possível. O GKE executa essa atualização antes que a versão do LTS do Container-Optimized OS usada pela versão secundária dos nós chegue ao fim do suporte. Os administradores do cluster precisam avaliar a atualização para a próxima versão de patch do GKE, que contém uma nova versão do LTS do Container-Optimized OS ou permanecer na mesma versão de patch do GKE para não receber atualizações no sistema operacional do nó e não receber patches de segurança para componentes principais do Kubernetes incluídos na versão do cluster do GKE.
A próxima versão do Container-Optimized OS LTS apresenta alterações incompatíveis com a versão secundária atual
A próxima versão do LTS do Container-Optimized OS pode introduzir mudanças incompatíveis com os componentes do sistema do GKE e o GKE não fornecer uma versão de patch com atualizações do sistema operacional do nó. Os administradores de cluster precisam avaliar se querem fazer o upgrade para a versão secundária ou considerar as compensações descritas no parágrafo anterior.
Esquema de controle de versão
O GKE anexa uma versão de patch do GKE ao padrão do setor com controle de versão semântico do Kubernetes (x.y.z-gke.N):
- Versão principal do Kubernetes (x)
- As versões principais geralmente serão incrementadas se qualquer alteração incompatível com versões anteriores forem introduzidas na API pública. Uma versão principal incrementa a versão do Kubernetes de xy para x+1.y.
- Versão secundária do Kubernetes (y)
- O Kubernetes lança uma nova versão secundária três vezes por ano. Cada ciclo de lançamento tem aproximadamente 15 semanas. As APIs obsoletas podem ser substituídas por uma nova versão secundária. Por exemplo, 1.22. Uma versão secundária incrementa a versão do Kubernetes de 1.y para 1.y+1; Por exemplo, o Kubernetes 1.32 é a versão secundária que segue o Kubernetes 1.31.
- Versão de patch do Kubernetes (z)
- Novas versões de patch do Kubernetes (como 1.32.6) para uso com o GKE costumam ser disponibilizadas a cada semana. Versões de patch são lançadas para cada zona gradualmente.
- Versão de patch do GKE (-gke.N)
- Uma versão de patch com um sufixo -gke.N (como 1.32.6-gke.N) pode incluir atualizações de segurança e correções de bugs para o GKE e o software de código aberto e de upstream do Kubernetes. Essas atualizações ou correções são necessárias para fins de compatibilidade e interoperabilidade com o Google Cloud.
Como verificar versões disponíveis e padrão
Para informações sobre as versões disponíveis, consulte as notas da versão do GKE.
Também é possível verificar quais versões do Kubernetes estão disponíveis e qual é o padrão em uma determinada zona no console do Google Cloud ou usando a Google Cloud CLI.
Usar o console do Google Cloud para verificar as versões
Para acessar as versões padrão e disponíveis, siga estas etapas:
Acesse a página Google Kubernetes Engine no console do Google Cloud.
Clique em add_box Criar.
Escolha o modo de cluster Padrão e clique em Configurar.
Na seção Tipo de local, escolha um tipo e o local pretendido para seu cluster.
Na seção Versão do plano de controle, selecione um canal de lançamento. Todas as versões disponíveis no momento estão listadas para o canal em questão. A versão padrão é selecionada automaticamente.
Use a CLI gcloud para verificar as versões
Para ver quais versões estão disponíveis e qual é a padrão, execute um dos
comandos gcloud a seguir para seu tipo de cluster. Cada guia oferece comandos
para verificar versões de um canal de lançamento
específico ou para nenhum canal (anteriormente estático).
Rápido
Para ver as versões padrão e disponíveis no canal de lançamento Rapid,
execute os seguintes comandos:
Versão padrão
gcloud container get-server-config \
--flatten="channels" \
--filter="channels.channel=RAPID" \
--format="yaml(channels.channel,channels.defaultVersion)" \
--location=COMPUTE_LOCATION
Versões disponíveis
gcloud container get-server-config \
--flatten="channels" \
--filter="channels.channel=RAPID" \
--format="yaml(channels.channel,channels.validVersions)" \
--location=COMPUTE_LOCATION
Substitua:
COMPUTE_LOCATION: um local do Compute Engine.
Normal
Para ver as versões padrão e disponíveis no canal de lançamento Regular,
execute os seguintes comandos:
Versão padrão
gcloud container get-server-config \
--flatten="channels" \
--filter="channels.channel=REGULAR" \
--format="yaml(channels.channel,channels.defaultVersion)" \
--location=COMPUTE_LOCATION
Versões disponíveis
gcloud container get-server-config \
--flatten="channels" \
--filter="channels.channel=REGULAR" \
--format="yaml(channels.channel,channels.validVersions)" \
--location=COMPUTE_LOCATION
Substitua:
COMPUTE_LOCATION: um local do Compute Engine.
Estável
Para ver as versões padrão e disponíveis no canal de lançamento Stable,
execute os seguintes comandos:
Versão padrão
gcloud container get-server-config \
--flatten="channels" \
--filter="channels.channel=STABLE" \
--format="yaml(channels.channel,channels.defaultVersion)" \
--location=COMPUTE_LOCATION
Versões disponíveis
gcloud container get-server-config \
--flatten="channels" \
--filter="channels.channel=STABLE" \
--format="yaml(channels.channel,channels.validVersions)" \
--location=COMPUTE_LOCATION
Substitua:
COMPUTE_LOCATION: um local do Compute Engine.
Estendido
Para ver as versões padrão e disponíveis no canal de lançamento Extended,
execute os seguintes comandos:
Versão padrão
gcloud container get-server-config \
--flatten="channels" \
--filter="channels.channel=EXTENDED" \
--format="yaml(channels.channel,channels.defaultVersion)" \
--location=COMPUTE_LOCATION
Versões disponíveis
gcloud container get-server-config \
--flatten="channels" \
--filter="channels.channel=EXTENDED" \
--format="yaml(channels.channel,channels.validVersions)" \
--location=COMPUTE_LOCATION
Substitua:
COMPUTE_LOCATION: um local do Compute Engine.
Nenhum canal
Para conferir as versões padrão e disponíveis para nenhum canal (anteriormente estático), execute os seguintes comandos:
Versão padrão
gcloud container get-server-config \
--format="yaml(defaultClusterVersion)" \
--location=COMPUTE_LOCATION
Versões disponíveis do plano de controle
gcloud container get-server-config \
--format="yaml(validMasterVersions)" \
--location=COMPUTE_LOCATION
Versões de nós disponíveis
gcloud container get-server-config \
--format="yaml(validNodeVersions)" \
--location=COMPUTE_LOCATION
Substitua:
COMPUTE_LOCATION: um local do Compute Engine.
Como especificar a versão do cluster
Esta seção se aplica somente a clusters criados no modo Standard.
Ao criar ou fazer upgrade de um cluster usando a CLI gcloud, é possível especificar uma versão de cluster usando a sinalização --cluster-version. É possível usar uma versão específica, como 1.9.7-gke.N. Também é possível usar um alias de versão:
latest: especifica a versão compatível mais recente do Kubernetes atualmente disponível no GKE na zona ou região do cluster.1.X: especifica a versão do patch patch+gke.N válido mais recente na versão secundária 1.X1.X.Y: especifica o patch gke.N válido mais recente na versão de patch 1.X.Y.-: para planos de controle do cluster, especifica a versão padrão do Kubernetes para planos de controle. Para upgrades de nó, especifica a versão que o plano de controle do cluster está executando.
Criar ou fazer upgrade de um cluster especificando a versão como latest não fornece upgrades automáticos. Ative upgrades automáticos de nó para garantir que os nós no cluster estejam atualizados com a versão estável mais recente.
Como especificar a versão do nó
Esta seção se aplica somente a clusters criados no modo Standard. Nos clusters do Autopilot, os nós são atualizados automaticamente para a versão do plano de controle e não é possível especificar uma versão.
Quando você criar ou atualizar um pool de nós, especifique a sua versão. Por padrão, os nós executam a mesma versão do GKE que o plano de controle. Os nós não podem estar mais de duas versões secundárias atrás da versão dos planos de controle.
Com raras exceções, as versões de nó permanecem disponíveis mesmo que a versão do cluster não esteja mais disponível.
Política de desvio de versão do GKE
A política de distorção de versão do GKE garante que um cluster do GKE mantenha a compatibilidade entre o plano de controle e os nós. Em um cluster do GKE, os nós podem corresponder à versão do plano de controle ou executar até duas versões secundárias anteriores ao plano de controle.
Os nós não podem executar versões mais recentes que a do plano de controle. Por exemplo, se o plano de controle do cluster executar a versão 1.31, os nós poderão executar as seguintes versões: 1.31, 1.30 ou 1.29, mas não 1.28 ou anteriores. A versão dos nós não podem ser mais recentes do que a versão do plano de controle devido à política de desvio da versão do Kubernetes OSS.
Para garantir a compatibilidade e a confiabilidade, os nós devem usar uma versão compatível, independentemente de um desvio de versão válida.
Identificar clusters com um desvio de versão sem suporte
O GKE identifica clusters em que os nós estão executando uma versão incompatível com o plano de controle devido ao desvio de versão. O GKE recomenda que você faça upgrade dos nós que executam essa versão sem suporte, fornecendo essa orientação com um insight e uma recomendação pelo serviço Recommender. Para saber mais sobre como gerenciar insights e recomendações do Recommender, consulte Otimizar o uso do GKE com insights e recomendações.
Para encontrar clusters com uma discrepância de versão sem suporte, use uma das seguintes maneiras:
- Use o console do Google Cloud.
- Use a CLI gcloud ou a API Recommender especificando o
subtipo de
recomendador
CLUSTER_VERSION_SKEW_UNSUPPORTED.
Para mais instruções, consulte como ver insights e recomendações.
Para implementar essa recomendação, faça upgrade de todos os nós que estão executando uma versão secundária mais de duas versões secundárias anteriores à versão do plano de controle.
Suporte para pular versões secundárias
O GKE não permite pular versões secundárias do plano de controle do cluster. No entanto, é possível pular as versões de patch. Os nós de trabalho podem ignorar versões secundárias. Por exemplo, é possível fazer upgrade de um pool de nós da versão 1.32 para 1.34 ignorando a versão 1.33.
Para fazer upgrade de um cluster em várias versões secundárias, faça upgrade do plano de controle uma versão secundária de cada vez e faça upgrade dos nós de trabalho para a mesma versão toda vez. Por exemplo, para fazer upgrade do plano de controle da versão 1.32 para 1.34, primeiro faça upgrade da versão 1.32 para 1.33. Em seguida, faça upgrade dos nós de trabalho para corresponder à versão do plano de controle e repita o processo de upgrade da versão 1.33 para 1.34.
Fazer upgrade dos nós de trabalho para corresponder às versões ajuda a evitar o desvio de versão incompatível. Recomendamos não ignorar a versão quando possível. Ignorar versões de nós de trabalho geralmente implica um escopo de teste maior, que, embora seja gerenciável, requer mais consideração.
Como alternativa, crie um novo cluster com a versão que quiser e reimplante as cargas de trabalho.