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

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, o GKE fornece versões de patch e realiza regularmente upgrades automáticos de cluster para aplicar esses patches mais recentes. Para informações sobre como o GKE é compatível com 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 que essa versão secundária fique 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 aos primeiros usuários que querem testar os próximos recursos.

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 do 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 Rápido 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 essa versão secundária para qualquer cluster que esteja 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 atuais dessa 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 correções 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:

Períodos de suporte. O GKE aceita uma versão secundária por um total de 24 meses.

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 apresenta novas versões de patch Alfa no canal rápido até o início do período de disponibilidade rápida. As versões de patch Alfa estão disponíveis apenas para clusters Alfa, não têm suporte técnico nem SLA e têm alta probabilidade de conter problemas. Quando a versão secundária fica disponível para todos os clusters no canal rápido no 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 correções 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 do Canal rápido todas as versões Alfa disponíveis para essa versão secundária. 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 correções 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 entre uma e 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 a versão 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 correções 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)

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 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 quais tipos de upgrades 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 as 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 automaticamente dos nós que estão executando uma versão secundária 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 que executam versões secundárias sem suporte geralmente são programados para um upgrade automático para uma versão secundária com suporte 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 de emergência de upgrades automáticos após o fim do suporte

Como 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 no fim do suporte por até 90 dias após a data de fim do suporte configurando uma exclusão de manutenção com o escopo padrão de "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 vai fazer 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 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 por meio do serviço Recomendador. Essa 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 Recomendador, 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 Cloud de Confiance .
  • 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 compatível. Para ver as versões secundárias compatíveis e as datas de término do suporte, consulte o cronograma 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 atual do Container-Optimized OS usado pela versão secundária do GKE. As versões secundárias do GKE normalmente 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, normalmente durante o período de suporte estendido de uma versão secundária do GKE. Quando isso ocorre, 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 ocorrem 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 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 dos nós de trabalho do cluster, porque o GKE não fará 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 é possível manter 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 o upgrade para o próximo patch ou versão secundária seja feito.

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

A próxima versão de patch de 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 dos clusters automaticamente 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 no final do suporte estendido, como de costume. Para saber mais, consulte Upgrades automáticos no fim 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 use o novo marco do Container-Optimized OS, o GKE vai retomar 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 estendido.

Ao receber essa notificação, avalie se você quer fazer upgrade manual dos nós para o próximo patch ou versão secundária ou não 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 o 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ânticas 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 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)
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 upstream do Kubernetes. 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, além do software de código aberto do Kubernetes. Essas atualizações ou correções são necessárias para fins de compatibilidade e interoperabilidade com o Cloud de Confiance by S3NS.

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 1.35.6 do Kubernetes 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 alvo 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 a versão 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 Cloud de Confiance , acesse a página Criar um cluster do Kubernetes:

    Acesse Criar um cluster do Kubernetes

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

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

  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 verá as versões de patch Alfa disponíveis para a próxima versão secundária.

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

  • Verifique as versões de patch Alfa disponíveis no canal Rápido:

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

Como especificar a versão do cluster

Ao criar ou fazer upgrade de um cluster usando a CLI gcloud, é possível usar a flag --cluster-version para especificar uma versão de cluster ou um alias.

Para clusters do Autopilot e Standard, use o seguinte alias ao criar um cluster:

Somente para clusters padrão, é possível especificar uma versão disponível (como 1.30.2-gke.1500) ou usar um dos seguintes aliases:

  • latest: a versão mais recente do Kubernetes disponível na zona ou região do cluster. Especificar latest não fornece upgrades automáticos. Ative os upgrades automáticos de nós para garantir que os nós no cluster estejam atualizados com a versão estável mais recente.
  • 1.X: a versão de patch válida mais recente na versão secundária especificada.
  • 1.X.Y: o patch gke.N válido mais alto na versão de patch especificada.

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

    É possível usar esses aliases para criar e fazer upgrade de clusters.

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.

As versões de patch anteriores permanecem disponíveis para os nós até que a versão secundária chegue ao fim do suporte, mesmo depois que essas versões não estiverem mais disponíveis para o plano de controle. Em casos raros, uma versão de nó pode ficar indisponível antes.

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 em tempo hábil, 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 de 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 upgrade 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 tenha sido atualizado conforme necessário, o GKE fará o upgrade automático do cluster para uma versão de patch mais recente, independentemente 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 incompatível

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 não compatível, fornecendo essa orientação com um insight e uma recomendação por meio do serviço do recomendador. 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 distorção de versão incompatível, use uma das seguintes maneiras:

  • Use o console do Cloud de Confiance .
  • 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 estejam executando uma versão secundária que seja mais de duas versões secundárias anterior à 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, em seguida, promove gradualmente essa versão de patch por 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, fazer downgrade do cluster para essa versão. Enquanto uma versão secundária é compatível, o GKE continua a introduzir 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é que a versão secundária chegue ao fim do suporte, 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 do plano de controle 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á tenha sido 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 as desativa. Embora as versões de patch descontinuadas não estejam 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 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 (canal Regular, Stable, No) ou ao fim do suporte estendido (canal Extended).

Suporte à versão Alfa

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 estar 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 aos usuários iniciais que querem testar os próximos recursos 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 apresenta 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 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, é necessário criar 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, as versões de patch Alfa dessa versão secundária são removidas. 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 rápido (X.Y.0-gke.N). O GKE 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.