Nesta página, explicamos o controle de versão no Google Kubernetes Engine (GKE) e as políticas de suporte à versão. É possível ver a programação de versões e o suporte atuais na programação de versões do GKE.
Compatibilidade das versões
Atualmente, a comunidade de software de código aberto (OSS, na sigla em inglês) 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.
A partir do Kubernetes 1.19, o OSS é compatível com cada versão secundária por 12 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. A comunidade do Kubernetes pode revisar a agenda de suporte da versão de vez em quando.
O Google oferece um total de 14 meses de suporte para cada versão secundária do GKE depois que ela é disponibilizada no canal Normal. Os nós e as versões do pool de nós podem ser até duas versões secundárias mais antigas que o plano de controle, mas não podem ser mais recentes do que a versão do plano de controle devido à política de distorção de 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.
Depois de 12 meses, uma versão secundária compatível entra em um período de manutenção de dois meses antes de chegar ao fim da vida útil.
Ciclo de vida da versão secundária do GKE
A primeira fase do ciclo de vida da versão secundária começa com o lançamento de uma versão do GKE compatível. Os clusters que executam uma versão secundária compatível receberão patches regulares para corrigir bugs e problemas de segurança relatados. Com base na atual política de suporte da versão da comunidade OSS do Kubernetes, o GKE planeja manter as versões secundárias compatíveis por 14 meses, incluindo os 12 meses após o lançamento no Canal normal e um período de manutenção de dois meses. Durante o período de manutenção, nenhuma nova criação de pool de nós vai ser permitida para uma versão de manutenção, mas os pools de nós atuais que executam uma versão de manutenção continuarão em operação.
No final do período de manutenção, uma versão secundária atinge o fim da vida útil e fica oficialmente sem suporte e indisponível. As versões secundárias do GKE que atingiram o fim da vida útil não receberão mais patches de segurança e/ou correções de bugs. As versões de patch de uma versão secundária que chegou ao fim da vida útil não são compatíveis e estão indisponíveis.
A partir da versão 1.19, o GKE faz upgrade dos nós que estão executando uma versão sem suporte depois que a versão atinge o fim da vida útil. Isso garante a integridade e o alinhamento do cluster com a política de desvio da versão de código aberto. 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.
O Google não tem o compromisso de fornecer patches ou atualizações para o fim da vida útil.
Em casos raros, pode ser necessário revisar o período de manutenção ou o fim da vida útil das versões do GKE devido às alterações na política na comunidade do Kubernetes OSS ou na descoberta de vulnerabilidades, entre outros problemas técnicos que não podem ser resolvidos razoavelmente. Para acessar as versões mais recentes disponíveis, consulte as notas da versão do GKE.
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.19 é a versão secundária que segue o Kubernetes 1.18.
- Versão de patch do Kubernetes (z)
- Novas versões de patch do Kubernetes (como 1.18.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.18.6-gke.N) inclui atualizações de segurança e/ou correções de bugs do GKE junto com o software Kubernetes de código aberto. 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.
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 (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)"
Versões disponíveis
gcloud container get-server-config --flatten="channels" --filter="channels.channel=RAPID" \
--format="yaml(channels.channel,channels.validVersions)"
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)"
Versões disponíveis
gcloud container get-server-config --flatten="channels" --filter="channels.channel=REGULAR" \
--format="yaml(channels.channel,channels.validVersions)"
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)"
Versões disponíveis
gcloud container get-server-config --flatten="channels" --filter="channels.channel=STABLE" \
--format="yaml(channels.channel,channels.validVersions)"
Nenhum canal
Para ver as versões padrão e disponíveis para nenhum canal (estático), execute os seguintes comandos:
Versão padrão
gcloud container get-server-config --format="yaml(defaultClusterVersion)"
Versões disponíveis do plano de controle
gcloud container get-server-config --format="yaml(validMasterVersions)"
Versões de nós disponíveis
gcloud container get-server-config --format="yaml(validNodeVersions)"
Usar o console do Google Cloud para verificar as versões
Para ver quais versões estão disponíveis e quais são padrão, execute as seguintes 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.
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 no momento.
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.
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.
Perguntas frequentes de suporte à versão
Quando a janela de suporte começa para cada versão secundária?
O suporte para uma versão secundária do Kubernetes começa quando ela é disponibilizada para a criação de um novo cluster no canal de lançamento Normal.
Por quanto tempo uma versão secundária do Kubernetes é compatível com o GKE?
O GKE oferece 14 meses de suporte para cada versão secundária do Kubernetes disponibilizada. As versões vão receber patches para bugs e problemas de segurança durante todo o período de suporte.
Qual é a diferença entre a manutenção e o fim da vida útil de uma versão secundária do GKE?
O período de manutenção significa que uma versão deverá em breve entrar no final do período de vida útil. Durante o período de fim da vida útil, a versão secundária do GKE não receberá patches de segurança, correção de bugs ou novos recursos.
Quando a compatibilidade termina com uma versão do Kubernetes no GKE?
Uma versão secundária do Kubernetes não é compatível com o GKE quando atinge o fim da vida útil, após 14 meses de suporte.
O que acontece na data de início da manutenção?
O GKE notificará os clientes sobre as próximas versões de manutenção e fim da vida útil usando pontos de contato atuais, como: notas da versão, e-mails para contatos do projeto e notificações do GKE, quando aplicável. Os pools de nós existentes que executam uma versão de manutenção continuarão a funcionar, e a criação do novo pool de nós para a versão de manutenção será desativada.
O que acontece no fim da vida útil?
Os clientes que executam uma versão de fim de vida útil serão notificados por e-mail sobre o contato do projeto antes do término de uma versão. O GKE também começará a fazer o upgrade automático de nós (independentemente da ativação do upgrade automático) em versões de fim de vida útil para fins de segurança e compatibilidade, já que não haverá novos patches de segurança ou correções de bugs fornecidos para versões de fim de vida útil. Antes de interagir com o Cloud Customer Care para qualquer problema com um cluster ou nós que executem uma versão de fim da vida útil, primeiro é necessário fazer upgrade do cluster e dos nós para uma versão compatível.
Quando exatamente meu cluster receberá a atualização automática?
Os planos de controle do cluster serão atualizados automaticamente para as 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.
Um upgrade automático para uma versão compatível dos nós executando versões incompatíveis será realizado em até um mês após a data do fim da vida útil.
Posso pular versões do GKE durante um upgrade de cluster?
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.23 para 1.25 ignorando a versão 1.24.
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.23 para 1.25, primeiro faça upgrade da versão 1.23 para 1.24. 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.24 para 1.25.
Fazer upgrade dos nós de trabalho para corresponder às versões ajuda a evitar o desvio de versão. 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.
Posso deixar o cluster em uma versão do Kubernetes por tempo indeterminado?
Não, cada versão do GKE é compatível por 14 meses. Além disso, a operação de um cluster com um fim de vida útil do GKE gera segurança, confiabilidade e risco de compatibilidade significativos, já que nenhum patch de segurança ou correção de bugs será fornecido para versões de fim da vida útil.
Com que frequência devo fazer upgrade de uma versão do Kubernetes para manter o suporte?
Recomendamos que você ative um canal de lançamento e ative os upgrades automáticos de nós para ajudar a reduzir a carga operacional envolvida com o upgrade das versões do GKE. No entanto, ao fazer o upgrade manual, recomendamos fazer o upgrade no máximo a cada seis meses para ter acesso aos novos recursos e permanecer em uma versão compatível.
Qual é a política de lançamento dos planos de controle do GKE?
Os planos de controle de cluster sempre são atualizados regularmente, independentemente de o cluster estar inscrito em um canal de lançamento ou se o upgrade automático de nós estiver desativado. Saiba mais em Upgrades automáticos.