Controle de versão e suporte do GKE

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) do Kubernetes lança uma versão secundária com novos recursos e melhorias aproximadamente a cada três meses. 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 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.

Aproximadamente seis meses após uma versão secundária entrar em suporte, ela ficará indisponível para a criação de novos clusters e planos de controle. Os planos de controle que executam a versão secundária serão atualizados gradualmente para a próxima versão secundária compatível. Para clusters que executam uma versão estática, ainda é possível criar novos pools de nós na versão, e os clusters que executam uma versão de manutenção continuarão em operação. Os clusters de canal de lançamento exigem planos de controle e nós para usar a mesma versão secundária.

No final do período de lançamento de 12 meses, o GKE fornece um período de manutenção de dois meses. Durante os dois meses do período de manutenção, nenhuma nova criação de pool de nós 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 de manutenção alcança o fim da vida útil e se torna oficialmente incompatí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.

A partir da versão 1.19 e posteriores, o GKE atualizará os nós que executam uma versão não compatível depois que a versão atingir o fim da vida útil para garantir a integridade e o alinhamento do cluster com a política de distorção de versão de código aberto.

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 (xyz-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 aproximadamente a cada três meses. 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.a)
Uma versão de patch com um sufixo -gke.a (como 1.18.6-gke.a) 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 usando o Console do Google Cloud ou usando a ferramenta de linha de comando gcloud.

Use a ferramenta 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 versões

Para ver quais versões estão disponíveis e quais são padrão, execute as seguintes etapas:

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. Escolha o modo de cluster Padrão e clique em Configurar.

  4. Na seção Tipo de local, escolha um tipo e o local pretendido para seu cluster.

  5. 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 ferramenta 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.X
  • 1.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.

Novos clusters podem ser criados em uma versão secundária por aproximadamente seis meses após o início da versão de suporte. Novos pools de nós podem ser criados em uma versão secundária por aproximadamente 12 meses após o lançamento da versão de suporte. As versões receberão patches críticos para bugs e problemas de segurança durante o período de suporte de 14 meses.

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 provavelmente entrará em breve no fim da vida útil e só poderá receber bugs e patches de segurança críticos. 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 será atualizado automaticamente?

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.

Os nós que executam versões incompatíveis serão programados para um upgrade automatizado para uma versão compatível dentro de um mês após a data de fim da vida útil.

Posso pular várias versões do GKE durante um upgrade de cluster?

O Kubernetes OSS permite ignorar a versão em nós de trabalho. Por exemplo, é possível fazer upgrade de um pool de nós da versão 1.19.x para 1.21.x, enquanto a versão 1.20.x é ignorada. Também é possível ignorar versões de plano de controle ao fazer upgrade do plano de controle usando a ferramenta de linha de comando gcloud ou a API GKE.

A abordagem recomendada é fazer upgrade do plano de controle de uma versão secundária de cada vez e atualizar os nós de trabalho para a mesma versão um de cada vez. Por exemplo, para fazer upgrade do plano de controle da versão 1.19.x para 1.21.x, faça upgrade da versão 1.19.x para 1.20.x primeiro e, em seguida, faça upgrade dos nós de trabalho para que correspondam à versão do plano de controle e repita o processo para fazer upgrade da versão 1.20.x para a 1.21.x.

O upgrade do plano de controle de forma incremental e o upgrade dos nós de trabalho para corresponder a versões evitam o desvio da versão. Recomendamos não ignorar a versão quando possível. Ignorar essas versões geralmente implica um escopo de teste maior que, embora seja gerenciável, exige 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.