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. 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 versões e o suporte atuais na programação de lançamentos do GKE.

Observação: o controle de versão da API Kubernetes é separado do Kubernetes. Consulte a documentação da API Kubernetes para informações sobre o controle de versões dessa API.

Suporte à versão secundária

A compatibilidade do GKE com versões secundárias do Kubernetes é baseada em políticas de código aberto do Kubernetes. Para oferecer suporte às versões secundárias disponíveis durante o ciclo de vida delas, o GKE fornece versões de patch e realiza upgrades automáticos regulares do cluster para aplicar esses patches mais recentes. Para informações sobre como o GKE oferece suporte a versões de patch, consulte Suporte a versões de patch.

Além de oferecer suporte às versões secundárias disponíveis, o GKE também fornece versões de patch Alfa da próxima versão secundária no ciclo de lançamento do Kubernetes até quatro meses antes de essa versão secundária ficar disponível para todos os clusters no canal Rápido. Essas versões Alfa estão disponíveis apenas para clusters Alfa do GKE no Canal rápido e são destinadas a usuários que querem testar recursos futuros.

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

Antes do lançamento de uma nova versão secundária estável, o projeto Kubernetes lança versões de patch experimentais e instáveis dessa versão secundária. O GKE apresenta versões de patch Alfa baseadas nessas versões experimentais no canal Rapid apenas para clusters Alfa do GKE. Assim como outras versões de patch no Canal rápido, as versões Alfa são excluídas do SLA do GKE.

Depois que o Kubernetes lança a nova versão secundária estável, o GKE remove as versões Alfa dessa versão secundária e disponibiliza versões de patch para qualquer cluster no canal Rápido. Como o Canal rápido oferece as versões de patch mais recentes do GKE, elas são excluídas do SLA do GKE e podem conter problemas sem soluções 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:

1. Até quatro meses antes da data de lançamento de uma versão secundária, o GKE disponibiliza versões de patch Alfa para essa versão secundária no canal Rápido apenas para clusters Alfa.
2. O Kubernetes lança a nova versão secundária.
3. O GKE disponibiliza a nova versão secundária no Canal rápido e remove todas as versões de patch Alfa existentes para essa versão secundária.
4. O GKE disponibiliza a nova versão secundária no Canal normal (início do período de suporte padrão).
5. 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.
6. 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.
7. 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 da versão Alfa	Do mês -5 ao mês -1	O GKE lança novas versões de patch Alfa no canal Rapid até o início do período de disponibilidade exclusiva do Rapid. As versões de patch Alfa estão disponíveis apenas para clusters Alfa, não têm suporte técnico nem SLA e provavelmente contêm problemas. Quando a versão secundária fica disponível para todos os clusters no canal Rápido ao final do período de disponibilidade somente Alfa, o GKE remove todas as versões Alfa do canal Rápido.	Somente canal rápido (requer clusters Alfa)
Período de disponibilidade somente rápido	Do mês -1 ao mês 0	O GKE disponibiliza a versão secundária para todos os clusters no canal Rápido, fornecendo 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. O GKE também remove todas as versões Alfa disponíveis para essa versão secundária do canal Rapid.	Somente Canal rápido
Período de suporte padrão	Do mês 1 ao mês 14	O GKE oferece versões de patch com novos recursos, correções de segurança e de bugs.	Rápido, normal, estável, estendido, sem canal (descontinuado)
Período de suporte estendido	Do mês 15 ao mês 24	O GKE oferece versões de patch com correções de segurança.	Somente canal estendido (requer taxa adicional por cluster. Consulte Receber suporte de longo prazo com o Canal estendido)

Período de disponibilidade da versão Alfa

O GKE lança versões de patch Alfa de uma versão secundária futura no canal rápido até quatro meses antes do lançamento dessa versão secundária. As versões Alfa estão disponíveis apenas para clusters Alfa. O GKE lança outras versões de patch Alfa nas semanas seguintes e geralmente mantém de uma a três versões Alfa ativas.

Esse período dura até que o GKE lance a versão secundária estável no Canal rápido. Após o lançamento estável, o GKE remove todas as versões de patch Alfa dessa versão secundária do Canal rápido porque as versões de patch estáveis estão disponíveis para instalação.

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 (descontinuado): 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)

Observação: anteriormente, o GKE usava o termo fim da vida útil para se referir à data de término do suporte padrão. Com a introdução do suporte estendido, atualizamos este termo para refletir os vários períodos de suporte de uma versão secundária do GKE.

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 faz upgrade de clusters que usam 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 exclusões de manutenção no nível do cluster ou escolhendo os tipos de upgrades que o GKE realiza em uma sequência de lançamento. Além disso, o GKE não vai fazer upgrade dos clusters que usam recursos ou APIs 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 secundária 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 secundária indefinidamente, porque a operação de um cluster que usa uma versão secundária 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 secundárias em fim de suporte. O GKE não pode se comprometer a fornecer patches ou atualizações para versões secundárias 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 automático dos nós que estão executando uma versão secundária sem suporte após ela chegar ao fim do suporte para ajudar a garantir a integridade e o alinhamento do cluster com a política de desvio de versão do GKE. Os nós que executam versões secundárias sem suporte são programados para um upgrade automático para uma versão secundária compatível em até um mês após a data de fim do suporte. Os nós que executam versões secundárias sem suporte não podem ser atualizados imediatamente após o fim da vida útil da versão secundária, e o tempo real pode variar a critério do Google.

Da mesma forma, o GKE faz upgrade dos planos de controle do cluster que não foram atualizados para uma nova versão em 90 dias. Para mais informações, consulte Política de patch de 90 dias do plano de controle.

Prevenção temporária e emergencial de upgrades automáticos após o fim do suporte

Como uma medida temporária, a ser usada apenas em emergências em que não há outras opções disponíveis, é possível atrasar os upgrades automáticos após o fim do suporte por até 90 dias depois da data de término. Para isso, configure uma exclusão de manutenção com o escopo padrão "Sem upgrades". Não recomendamos essa prática devido aos riscos associados à execução de uma versão sem suporte. Depois que a exclusão de manutenção expirar, o GKE fará upgrade do cluster.

Identificar clusters que executam uma versão secundária após o fim do suporte padrão

O GKE identifica clusters que atendem às duas 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 que você faça 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 compatível se a versão atual não for compatível com o canal de lançamento do cluster.

O GKE fornece essa orientação com um insight e uma recomendação pelo serviço Recomendador. Esta orientação não se aplica 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 das seguintes maneiras:

• Use o console do Google Cloud .
• Use a CLI gcloud ou a API Recommender especificando o CLUSTER_VERSION_END_OF_LIFE subtipo do Recommender.

Para 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 compatível. Para conferir as versões secundárias compatíveis e as datas de fim do suporte, consulte a programação de lançamentos do GKE. Ou mude o cluster para o canal estendido se 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. Esses upgrades de patch podem incluir atualizações do Container-Optimized OS para o marco do Container-Optimized OS usado pela versão secundária do GKE. As versões secundárias do GKE geralmente usam um marco durante o período de suporte padrão até o início do período de suporte estendido.

No entanto, o marco do Container-Optimized OS usado pela versão secundária do GKE chega ao fim do suporte, geralmente durante o período de suporte estendido de uma versão secundária do GKE. Quando isso acontece, o GKE cria todas as versões de patch subsequentes do GKE com o próximo marco do Container-Optimized OS. Para saber mais sobre os ciclos de vida dos marcos, consulte o esquema de controle de versões do Container-Optimized OS.

Analise o cenário a seguir para entender como os upgrades automáticos são feitos e quais decisões os administradores de cluster precisam tomar quando o GKE não pode mais introduzir atualizações do Container-Optimized OS no mesmo marco para uma versão secundária do GKE.

O marco do Container-Optimized OS chega ao fim do suporte antes do fim do suporte estendido da versão secundária

O marco do Container-Optimized OS chega ao próprio fim do suporte antes do fim do suporte estendido da versão secundária que usa o marco. Nesse cenário, o GKE usa o próximo marco disponível do Container-Optimized OS para upgrades de patches futuros. O GKE executa essa atualização antes que o marco do Container-Optimized OS usado pela versão secundária chegue ao fim do suporte.

Os administradores de cluster precisam avaliar se querem fazer upgrade nos nós de trabalho do cluster, porque o GKE não faz upgrade automático desses nós para a próxima versão de patch com o novo marco. É possível fazer upgrade manual dos nós para a próxima versão de patch do GKE, que contém um novo marco. Ou, mantenha os nós executando a mesma versão de patch do GKE para não usar o novo marco. No entanto, os nós não vão receber patches de segurança até que seja feito upgrade para o próximo patch ou versão secundária.

Upgrades automáticos para o novo marco do Container-Optimized OS

A próxima versão de patch para uma versão secundária do GKE no período de suporte estendido usa um marco mais recente do Container-Optimized OS de versões de patch anteriores. O GKE faz upgrade automático dos clusters das seguintes maneiras quando a nova versão do patch se torna um destino de upgrade automático:

• Upgrades do plano de controle:
  • O GKE faz upgrade do plano de controle para a próxima versão de patch, como de costume.
• Upgrades de nós:
  • O GKE não faz upgrade dos nós para a próxima versão de patch.
  • O GKE faz upgrade dos nós para a próxima versão secundária perto do fim do suporte estendido, como de costume. Para saber mais, consulte Upgrades automáticos no fim do suporte.

Como a nova versão de marco pode introduzir mudanças incompatíveis com suas cargas de trabalho, o GKE pausa os upgrades automáticos de nós para a próxima versão de patch. É possível fazer upgrade manual para a nova versão de patch se você determinar que suas cargas de trabalho são compatíveis com o próximo marco do Container-Optimized OS. Se você fizer upgrade manual dos nós para uma versão de patch que usa o novo marco do Container-Optimized OS, o GKE retoma os upgrades automáticos de patch dos nós porque eles agora executam o novo marco.

Notificação de cluster quando novas versões de patch usam o novo marco

O GKE envia uma notificação de cluster informando quando essa situação ocorre. Essa notificação é enviada quando a primeira versão de patch que usa o novo marco do Container-Optimized OS fica disponível no canal Extended.

Quando você receber essa notificação, avalie se quer fazer upgrade manual dos nós para o próximo patch ou versão secundária ou se não quer receber versões de patch posteriores para essa versão secundária durante o período de suporte estendido. Para saber mais, consulte Novas versões de patch mudam para um novo marco do Container-Optimized OS durante o suporte estendido.

Esquema de controle de versão

As versões do Kubernetes usam o padrão de controle de versões semântico para números de versão (X.Y.Z). O GKE anexa um número de versão de patch do GKE à versão 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 X.Y 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 descontinuadas podem ser removidas com uma nova versão secundária, por exemplo, com a 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)

O Kubernetes lança versões de patch durante o período de 12 meses após o lançamento de uma versão secundária. Uma versão de patch incrementa a versão do Kubernetes de X.Y.Z para X.Y.Z+1. Por exemplo, 1.32.6 é a versão de patch que segue 1.32.5.

Versão de patch do GKE (-gke.N)

O GKE lança versões de patch que correspondem às versões de patch do Kubernetes upstream. As versões de patch do GKE podem incluir atualizações de segurança, mudanças de recursos e correções de bugs para o GKE junto com o software Kubernetes de código aberto. Essas atualizações ou correções são necessárias para compatibilidade e interoperabilidade com Google Cloud.

O GKE pode lançar várias versões de patch do GKE para cada versão de patch do Kubernetes. Por exemplo, a versão de patch do Kubernetes 1.35.6 tem versões de patch do GKE como 1.35.6-gke.1638000, 1.35.6-gke.1641000 e 1.35.6-gke.1250000.

As versões de patch do GKE costumam ser disponibilizadas a cada semana. As versões de patch são lançadas gradualmente para cada zona.

Versão de patch Alfa do GKE (X.Y+1.Z-gke.N+preview) – somente clusters Alfa

O GKE lança versões de patch Alfa para uma próxima versão secundária do Kubernetes até quatro meses antes da data de lançamento dessa versão secundária. Essas versões de patch de pré-lançamento estão disponíveis para experimentação e teste em clusters Alfa do GKE inscritos no canal de lançamento rápido. As versões de patch Alfa sempre têm como destino a próxima versão secundária no ciclo de lançamento do Kubernetes antes do lançamento dessa versão secundária. Por exemplo, se a versão secundária 1.36 for o lançamento estável mais recente e a 1.37 ainda não tiver sido lançada, as versões de patch alfa serão para a versão 1.37.

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.

Para verificar as versões padrão e disponíveis do GKE, selecione uma das seguintes opções:

Console

1. No console do Google Cloud , acesse a página Criar um cluster do Kubernetes:

   Acessar "Criar um cluster do Kubernetes"

2. Na seção Tipo de local, escolha um tipo e a região ou zona do plano de controle do cluster.

3. Na lista Canal de lançamento de destino, selecione um canal.

4. Abra a lista Versão de destino. Essa lista mostra todas as versões de patch do GKE disponíveis para o canal de lançamento. A versão de patch padrão do canal de lançamento é selecionada automaticamente. Se você selecionar o canal de lançamento rápido, também vai ver as versões de patch alfa disponíveis para a próxima versão secundária.

Observação: se você usar o console Google Cloud para criar um cluster antes que o lançamento de uma versão seja concluído, as listas de versões disponíveis poderão não ser precisas para a zona.

gcloud

Para verificar as versões disponíveis e padrão de um canal de lançamento específico, execute um dos seguintes comandos:

• Verifique as versões disponíveis:

  gcloud container get-server-config \
      --flatten="channels" \
      --filter="channels.channel=RELEASE_CHANNEL" \
      --format="yaml(channels.channel,channels.validVersions)" \
      --location=COMPUTE_LOCATION
  

  Substitua:

  • RELEASE_CHANNEL: o nome do canal de lançamento. Especifique um dos seguintes valores:

    • RAPID
    • REGULAR
    • STABLE
    • EXTENDED

  • COMPUTE_LOCATION: o local do Compute Engine que você quer verificar.

  O resultado será o seguinte:

  channels:
    channel: RAPID
    validVersions:
    - 1.36.2-gke.2064000
    - 1.36.2-gke.1498000
    - 1.35.6-gke.1641000
    - 1.35.6-gke.1638000
    - 1.35.6-gke.1258000
    - 1.34.9-gke.1610000
    - 1.34.9-gke.1322000
    - 1.33.13-gke.1269000
    - 1.33.13-gke.1109000
  

  No canal Rápido, o campo previewVersions indica as versões de patch Alfa do GKE para a próxima versão secundária do Kubernetes. Essas versões estão disponíveis apenas para clusters Alfa.

• Verifique a versão padrão:

  gcloud container get-server-config \
      --flatten="channels" \
      --filter="channels.channel=RELEASE_CHANNEL" \
      --format="yaml(channels.channel,channels.defaultVersion)" \
      --location=COMPUTE_LOCATION
  

  O resultado será o seguinte:

  channels:
    channel: RAPID
    defaultVersion: 1.36.2-gke.1498000
  

• Confira as versões de patch alfa disponíveis no canal Rapid:

  gcloud container get-server-config \
      --flatten="channels" \
      --filter="channels.channel=RAPID" \
      --format="yaml(channels.channel,channels.previewVersions)" \
      --location=COMPUTE_LOCATION
  

  O resultado será o seguinte:

  channels:
    channel: RAPID
    previewVersions:
    - 1.37.0-gke.2064000+preview
  

Para verificar as versões disponíveis e padrão para clusters que não usam um canal (descontinuado), execute um dos seguintes comandos:

• Verifique a versão padrão:

  gcloud container get-server-config \
      --format="value(defaultClusterVersion)" \
      --location=COMPUTE_LOCATION
  

  Substitua COMPUTE_LOCATION pelo local do Compute Engine que você quer verificar.

  A saída é semelhante a 1.35.6-gke.1127000.

• Verifique as versões disponíveis do plano de controle:

  gcloud container get-server-config \
    --format="yaml(validMasterVersions)" \
    --location=COMPUTE_LOCATION
  

  O resultado será o seguinte:

  validMasterVersions:
  - 1.36.2-gke.2064000
  - 1.36.2-gke.1498000
  - 1.36.2-gke.1346000
  - 1.36.0-gke.4681000
  - 1.36.0-gke.4447000
  - 1.35.6-gke.1641000
  - 1.35.6-gke.1638000
  - 1.35.6-gke.1258000
  - 1.35.6-gke.1250000
  - 1.35.6-gke.1127000
  - 1.35.6-gke.1049000
  

• Verifique as versões de nós disponíveis:

  gcloud container get-server-config \
    --format="yaml(validNodeVersions)" \
    --location=COMPUTE_LOCATION
  

  O resultado será o seguinte:

  validNodeVersions:
  - 1.36.2-gke.2064000
  - 1.36.2-gke.1498000
  - 1.36.2-gke.1346000
  - 1.36.0-gke.4681000
  - 1.36.0-gke.4447000
  - 1.35.6-gke.1641000
  - 1.35.6-gke.1638000
  - 1.35.6-gke.1258000
  - 1.35.6-gke.1250000
  - 1.35.6-gke.1127000
  - 1.35.6-gke.1049000
  # Multiple lines are omitted here
  

Observação: para manipulação avançada de saída get-server-config, consulte a documentação da CLI gcloud sobre filtragem e formatação.

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 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.

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 patch de 90 dias do plano de controle

Para garantir que um cluster do GKE receba patches de segurança críticos e outras correções de maneira oportuna, o GKE exige que o plano de controle de um cluster seja atualizado para uma nova versão de patch (ou secundária) pelo menos a cada 90 dias. Por padrão, o GKE faz upgrade automático do plano de controle dos clusters com mais frequência do que a cada 90 dias. No entanto, é possível atrasar esses upgrades do plano de controle configurando exclusões de manutenção ou escolhendo quais tipos de upgrades o GKE realiza em uma sequência de lançamento. No entanto, semelhante aos upgrades automáticos no fim do suporte, se você tiver um cluster do GKE que não foi atualizado conforme necessário, o GKE vai atualizar automaticamente o cluster para uma versão de patch mais recente, independente das políticas configuradas.

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, oferecendo 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 Recomendador, consulte Otimizar o uso do GKE com insights e recomendações.

Para encontrar clusters com uma versão incompatível, use uma das seguintes maneiras:

• Use o console do Google Cloud .
• Use a CLI gcloud ou a API Recommender especificando o CLUSTER_VERSION_SKEW_UNSUPPORTED subtipo do Recommender.

Para 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.

Suporte à versão de patch

Primeiro, o GKE apresenta uma versão de patch ao canal rápido e depois promove gradualmente essa versão de patch em outros canais de lançamento. Quando o GKE disponibiliza uma versão de patch em um canal de lançamento, é possível criar, fazer upgrade ou, em casos específicos, downgrade do cluster para essa versão. Enquanto uma versão secundária é compatível, o GKE continua lançando novas versões de patch da versão secundária em um canal de lançamento.

As versões de patch anteriores permanecem disponíveis no canal de lançamento para nós até o fim do suporte da versão secundária, mas são removidas e ficam indisponíveis para uso com o plano de controle antes dessa data. Quando o GKE remove uma versão de patch para uso com o plano de controle, não é possível criar, fazer upgrade ou downgrade do plano de controle do cluster para a versão de patch removida. Se o plano de controle do cluster executar uma versão de patch removida, recomendamos que você faça upgrade para o destino de upgrade automático mais recente.

Descontinuação de versões de patch para o plano de controle

As informações a seguir se aplicam a qualquer versão de patch em que a versão secundária já foi introduzida no Canal normal.

Antes de remover as versões de patch de um canal de lançamento para uso com um plano de controle de cluster, o GKE descontinua a versão de patch. Embora as versões de patch descontinuadas não sejam mais listadas como disponíveis para o plano de controle, ainda é possível usá-las para criar, fazer upgrade ou downgrade do plano de controle.

Recomendamos fazer upgrade para uma versão de patch mais recente assim que possível. Use versões descontinuadas apenas se o processo de lançamento do seu ambiente impedir estritamente que você faça upgrade antes. O GKE descontinua uma versão de patch por 90 dias ou até que a versão secundária chegue ao fim do suporte padrão (Regular, Stable, No channel) ou do suporte estendido (Extended channel).

Suporte à versão Alfa

Atenção: as versões Alfa são instáveis do Kubernetes e destinadas a testes. Essas versões têm as mesmas expectativas de suporte técnico e estabilidade da fase de lançamento Prévia.

As versões Alfa são versões de patch do GKE de uma versão secundária futura do Kubernetes que o GKE lança até quatro meses antes de a versão secundária ficar disponível para todos os clusters no canal rápido. Essas versões Alfa estão disponíveis apenas em clusters Alfa do GKE e são destinadas a usuários que querem testar recursos futuros sem expectativa de estabilidade ou suporte.

O canal rápido tem entre uma e três versões de patch alfa disponíveis para a próxima versão secundária. Nos meses anteriores à disponibilização da versão secundária para todos os clusters no canal rápido, o GKE lança novas versões de patch Alfa e remove as versões atuais. Como as versões de patch Alfa estão disponíveis apenas em clusters Alfa, as seguintes considerações se aplicam:

• Não é possível fazer upgrade dos clusters Alfa para novas versões. Para testar uma nova versão Alfa, crie um cluster Alfa que execute essa versão.
• Os clusters Alfa que executam uma versão Alfa removida continuam existindo até que os clusters expirem 30 dias após a criação ou até que você os exclua.
• As correções de CVEs e bugs em componentes específicos do sistema não são aplicadas retroativamente às versões de patch alfa atuais. Para receber essas correções, crie um cluster Alfa que execute uma versão de patch Alfa mais recente.

Depois que o GKE lança uma versão secundária estável no Canal rápido, ele remove as versões de patch alfa dessa versão secundária. As versões Alfa da próxima versão secundária no ciclo de lançamento ficam disponíveis no canal Rápido até quatro meses antes da data de lançamento dessa versão secundária.

Ciclo de vida da versão Alfa

O ciclo de vida da versão Alfa tem os seguintes marcos:

1. O Kubernetes lança a primeira versão de desenvolvimento para a próxima versão secundária (X.Y+1.0-alpha.0).
2. Até quatro meses antes da data de lançamento da próxima versão secundária, o GKE apresenta versões de patch Alfa para essa versão secundária no Canal rápido (X.Y+1.0-gke.N+preview).
3. O Kubernetes lança a versão secundária estável (X.Y.0).
4. O GKE disponibiliza a versão secundária estável no canal Rapid (X.Y.0-gke.N) e remove as versões Alfa dessa versão secundária do Canal rápido.

O ciclo de vida de uma versão Alfa não afeta o ciclo de vida da versão secundária do GKE.