Versões e apoio técnico do GKE

Esta página explica o controlo de versões no Google Kubernetes Engine (GKE) e as políticas de suporte de versões. Ao longo do tempo, o GKE atualiza os clusters para versões mais recentes do Kubernetes. Para saber mais sobre como funcionam as atualizações, consulte o artigo Acerca das atualizações de clusters do GKE.

Pode ver a implementação das versões atuais e o calendário de apoio técnico no calendário de lançamentos do GKE.

Suporte de versões

O suporte do GKE para versões secundárias do Kubernetes baseia-se nas políticas de código aberto do Kubernetes. O GKE suporta uma versão secundária através da disponibilização de versões de patch da mesma versão secundária e, de forma regular, atualiza automaticamente os clusters para esses patches mais recentes.

Como o Kubernetes suporta uma versão secundária

A comunidade de software de código aberto (OSS) do Kubernetes lança uma versão secundária com novas funcionalidades e melhoramentos três vezes por ano. Cada ciclo de lançamento tem uma duração de aproximadamente 15 semanas.

O Kubernetes suporta cada versão secundária durante 14 meses. Os principais erros e vulnerabilidades de segurança encontrados numa versão secundária suportada são corrigidos com o lançamento de uma versão de patch ad hoc. Por vezes, a comunidade Kubernetes revê o respetivo calendário de suporte de versões, conforme necessário. Para saber mais, consulte o artigo Período de apoio técnico.

Como o GKE suporta uma versão secundária

Após o lançamento de uma nova versão secundária do Kubernetes, o GKE introduz primeiro a versão secundária no canal Rápido. O GKE fornece versões de patches durante esse período, mas, como o canal Rápido fornece as versões mais recentes do GKE, estas versões 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 Regular. O GKE oferece um total de 24 meses de apoio técnico para uma versão secundária após a versão ter sido disponibilizada para a criação de novos clusters no canal Regular. Este apoio técnico inclui cerca de 14 meses de apoio técnico padrão e, aproximadamente, mais 10 meses de apoio técnico alargado disponíveis com o canal Extended. Para ver a disponibilidade de versões secundárias específicas, reveja a agenda de lançamentos 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 os seguintes passos principais:

  1. O Kubernetes lança uma nova versão secundária.
  2. O GKE disponibiliza a nova versão secundária no canal Rapid.
  3. O GKE disponibiliza a nova versão secundária no canal Regular (início do período de apoio técnico padrão).
  4. Durante o período de apoio técnico padrão, o GKE fornece patches para a versão secundária que incluem novas funcionalidades, correções de segurança e correções de erros.
  5. A versão secundária atinge o fim do apoio técnico padrão após aproximadamente 14 meses no total, entrando no período de apoio técnico alargado. Após este período, o GKE fornece patches de segurança para clusters no canal alargado.
  6. A versão secundária atinge o fim do apoio técnico alargado, o que significa que a versão secundária não vai receber mais patches de segurança.

Ajustes da disponibilidade da versão

O GKE pode rever o fim do apoio técnico para versões do GKE devido a alterações na política na comunidade de software de código aberto do Kubernetes, à deteção de vulnerabilidades ou a outros problemas técnicos que não possam ser resolvidos de forma razoável. O GKE também pode prolongar as datas de fim do apoio técnico em torno de períodos empresariais importantes, como a Black Friday e a Cyber Monday.

O GKE oferece, pelo menos, 14 meses de apoio técnico padrão e até um total de 24 meses de apoio técnico com apoio técnico alargado.

Para obter as versões disponíveis mais recentes, consulte as notas de lançamento do GKE. O GKE atualiza regularmente o cronograma de lançamentos para refletir o momento das atualizações automáticas.

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 apoio técnico. O GKE suporta uma versão secundária durante um total de 24 meses.

Consulte a seguinte tabela que resume os períodos de disponibilidade, descritos em detalhe nas secções seguintes:

Período de disponibilidade Intervalo de tempo aproximado desde a disponibilidade do canal normal Que apoio técnico oferece o GKE Acesso a este período de disponibilidade
Período de disponibilidade apenas do modelo Rápido Mês -1 a mês 0 O GKE fornece versões de patches com novas funcionalidades, correções de segurança e correções de erros. No entanto, estas versões são excluídas do ANS do GKE e podem conter problemas sem soluções alternativas conhecidas. Apenas canal rápido
Período de apoio técnico padrão Mês 1 a mês 14 O GKE fornece versões de patches com novas funcionalidades, correções de segurança e correções de erros. Rápido, normal, estável, alargado, sem canal
Período de apoio técnico alargado Do 15.º ao 24.º mês O GKE fornece versões de patches com correções de segurança. Apenas canal alargado (requer uma taxa adicional por cluster. Consulte o artigo Receba apoio técnico a longo prazo com o canal alargado)

Período de disponibilidade apenas do modelo Rápido

O GKE lança primeiro uma nova versão secundária no canal Rapid. A versão acumula primeiro a utilização e demonstra estabilidade nos clusters neste canal antes de ser promovida para o canal normal. Apenas os clusters inscritos no canal rápido podem executar uma nova versão secundária durante este período de disponibilidade.

Normalmente, este período dura cerca de 1 a 2 meses. No entanto, o momento exato depende de cada versão secundária. Para ver detalhes, consulte o cronograma estimado para canais de lançamento.

Período de apoio técnico padrão

O período de apoio técnico padrão para uma versão secundária do GKE começa quando a versão é lançada no canal Regular. Todos os clusters do GKE, independentemente da inscrição no canal de lançamento, podem executar uma versão secundária no suporte padrão. Durante este período, o GKE atualiza automaticamente os clusters de forma regular para novas versões de patches, que incluem novas funcionalidades, correções de segurança e correções de erros.

O GKE atualiza automaticamente os clusters da seguinte forma:

  • Rápido, Regular, Estável, Sem canal: atualizações automáticas para outras versões secundárias suportadas ou versões de patch da mesma versão secundária.
  • Alargada: o GKE só atualiza automaticamente para versões de patch mais recentes da mesma versão secundária.

Para clusters não inscritos no canal de lançamento alargado, o GKE atualiza automaticamente os clusters para a próxima versão secundária suportada antes do fim do apoio técnico padrão, com base na programação do canal de lançamento do cluster. Para ver detalhes, consulte o cronograma estimado para canais de lançamento. No entanto, o GKE não atualiza os clusters durante este período se usarem funcionalidades ou APIs descontinuadas. Pode usar uma exclusão de manutenção para impedir temporariamente que o GKE atualize o cluster para a versão secundária seguinte.

Fim do apoio técnico padrão (anteriormente fim de vida)

Após o período de apoio técnico padrão, a versão secundária atinge o fim do apoio técnico padrão (anteriormente conhecido como fim de vida) e fica sem apoio técnico e indisponível para todos os clusters não inscritos no canal alargado.

Os clientes que executam uma versão em fim de suporte são notificados através de um email enviado ao contacto do projeto antes do fim do suporte de uma versão. O GKE também começa a atualizar automaticamente os nós gradualmente (independentemente da ativação da atualização automática) que executam versões não suportadas por motivos de segurança e compatibilidade, porque não são fornecidos novos patches de segurança nem correções de erros para versões em fim de suporte. Antes de contactar o Cloud Customer Care para resolver problemas com um cluster ou nós que executam uma versão não suportada, tem de atualizar primeiro o cluster e os nós para uma versão suportada.

As versões secundárias do GKE que atingiram o fim do suporte técnico já não recebem patches de segurança nem correções de erros. As versões de patch de uma versão secundária que atingiu o fim do suporte não são suportadas nem estão disponíveis. O GKE atualiza automaticamente todos os clusters não inscritos no canal Extended. Para saber mais, consulte o artigo Atualizações automáticas no final do apoio técnico.

Período de apoio técnico alargado

Após o fim do apoio técnico padrão, a versão secundária atinge o período de apoio técnico alargado (do mês 15 ao mês 24). Durante este 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, elevados e críticos para componentes principais do Kubernetes, sistema operativo do nó e contentores geridos pela Google incluídos na versão do cluster do GKE.
  • Para o SO otimizado para contentores, o fim do suporte do sistema operativo do nó pode ocorrer antes do fim do suporte alargado da versão secundária do GKE ou introduzir alterações incompatíveis. Para saber como o GKE continua a oferecer apoio técnico, consulte o artigo Atualizações do SO otimizado para contentores durante o período de apoio técnico alargado.

Perto do fim do apoio técnico alargado, o GKE começa a atualizar os clusters para a versão secundária seguinte. O GKE não atualiza os clusters se estes estiverem a usar funcionalidades ou APIs descontinuadas. Pode usar uma exclusão de manutenção para impedir temporariamente que o GKE atualize o cluster para a versão secundária seguinte.

Fim do apoio técnico alargado

No final do apoio técnico alargado, o GKE não fornece patches para correções de segurança, e a versão secundária é considerada não suportada. As atualizações do GKE atualizam os clusters que ainda executam a versão secundária não suportada para a versão secundária seguinte, independentemente da utilização de funcionalidades ou APIs descontinuadas do cluster.

Upgrades automáticos no final do suporte

O GKE agenda atualizações automáticas para clusters de uma versão secundária para a versão secundária suportada seguinte antes de a versão secundária atingir o fim do apoio técnico. O tempo desta atualização depende da agenda do canal de lançamento do cluster. Para ver detalhes, consulte o cronograma estimado para canais de lançamento. Por exemplo, os clusters inscritos no canal estável são atualizados para a versão secundária seguinte mais perto do fim do apoio técnico padrão do que os clusters inscritos no canal rápido.

Durante o período de apoio técnico padrão e o período de apoio técnico alargado para clusters inscritos no canal alargado, pode impedir esta atualização da versão secundária com uma exclusão de manutenção, e o GKE não atualiza os clusters que usam funcionalidades ou APIs descontinuadas.

No entanto, no final do apoio técnico padrão ou no final do apoio técnico alargado para clusters inscritos no canal alargado, o GKE atualiza automaticamente os clusters para a próxima versão secundária suportada para garantir que o cluster permanece com bom desempenho, disponível e seguro.

Cada versão do GKE é suportada durante 14 meses de apoio técnico padrão e 24 meses de apoio técnico total, incluindo apoio técnico alargado. Não pode manter o cluster numa versão indefinidamente, porque a utilização de um cluster com uma versão do GKE não suportada acarreta riscos significativos de segurança, fiabilidade e compatibilidade, uma vez que o GKE não fornece patches de segurança nem correções de erros para versões em fim de suporte. O GKE não pode comprometer-se a fornecer patches ou atualizações para versões no fim do suporte.

O GKE atualiza o cluster da seguinte forma:

  • Painel de controlo: o GKE atualiza automaticamente os painéis de controlo do cluster para versões suportadas quando a versão do painel de controlo deixa de estar disponível para a criação de novos clusters.
  • Nós: o GKE atualiza automaticamente os nós que estão a executar uma versão não suportada depois de a versão ter atingido o fim do suporte técnico para garantir o bom funcionamento do cluster e o alinhamento com a política de variação da versão do GKE. Normalmente, os nós que executam versões não suportadas são agendados para uma atualização automática para uma versão suportada no prazo de um mês após a data de fim do suporte. Os nós que executam versões não suportadas podem não ser atualizados imediatamente após o fim do ciclo de vida da versão, e o tempo real pode variar à discrição da Google.

Identifique clusters que executam uma versão secundária após o fim do apoio técnico padrão

O GKE identifica clusters que cumprem ambas as seguintes condições:

O GKE recomenda que atualize estes clusters devido aos riscos associados à execução de uma versão secundária não suportada. O GKE atualiza os clusters para a próxima versão secundária suportada se a versão existente não for suportada no canal de lançamento do cluster.

O GKE fornece estas orientações com uma estatística e uma recomendação através do serviço Recommender. Estas orientações não se aplicam a clusters inscritos no canal alargado, que podem continuar a executar uma versão secundária até ao fim do apoio técnico alargado. Para saber mais sobre como gerir estatísticas e recomendações do Recomendador, consulte o artigo Otimize a sua utilização do GKE com estatísticas e recomendações.

Para encontrar clusters onde o plano de controlo está a executar uma versão após o fim do apoio técnico, pode usar uma das seguintes formas:

  • Use a Google Cloud consola.
  • Use a CLI gcloud ou a API Recommender, especificando o CLUSTER_VERSION_END_OF_LIFE subtipo de recomendador.

Para ver instruções, saiba como ver estatísticas e recomendações.

Para implementar esta recomendação, atualize o plano de controlo do cluster para uma versão secundária suportada. Para ver as versões secundárias suportadas e as datas de fim do suporte técnico, consulte o cronograma de lançamentos do GKE. Em alternativa, altere o cluster para o canal Extended se quiser continuar a usar a versão secundária existente até ao fim do apoio técnico extendido.

Atualizações do SO otimizado para contentores durante o período de apoio técnico alargado

Durante o período de apoio técnico alargado para uma versão secundária do GKE, o GKE fornece atualizações de patches para o cluster. Estas atualizações de patches podem incluir atualizações do SO otimizado para contentores para o marco do SO otimizado para contentores existente usado pela versão secundária do GKE. Normalmente, as versões secundárias do GKE usam um marco durante o período de apoio técnico padrão até ao início do período de apoio técnico alargado.

No entanto, a etapa do SO otimizado para contentores usada pela versão secundária do GKE atinge o seu próprio fim do suporte técnico, normalmente, durante o período de suporte técnico alargado de uma versão secundária do GKE. Quando isto ocorre, o GKE cria todas as versões de patch do GKE subsequentes com o marco do SO otimizado para contentores seguinte. Para saber mais acerca dos ciclos de vida das referências, consulte o esquema de controlo de versões do SO otimizado para contentores.

Reveja o seguinte cenário para compreender como os upgrades automáticos prosseguem e que decisões os administradores de clusters têm de tomar quando o GKE já não pode introduzir atualizações do SO otimizado para contentores na mesma etapa para uma versão secundária do GKE.

O marco do SO otimizado para contentores atinge o fim do apoio técnico antes do fim do apoio técnico alargado da versão secundária

O marco do SO otimizado para contentores atinge o seu próprio fim do apoio técnico antes do fim do apoio técnico alargado para a versão secundária que usa o marco. Neste cenário, o GKE usa o marco do SO otimizado para contentores seguinte disponível para futuras atualizações de patches. O GKE realiza esta atualização antes de o marco do SO otimizado para contentores usado pela versão secundária atingir o fim do apoio técnico.

Os administradores do cluster têm de avaliar se devem atualizar os nós de trabalho do cluster, porque o GKE não atualiza automaticamente estes nós para a versão de patch seguinte com o novo marco. Pode atualizar manualmente os nós para a versão de patch do GKE seguinte, que contém um novo marco. Em alternativa, pode manter os nós a executar a mesma versão de patch do GKE para não usar o novo marco. No entanto, os nós não recebem patches de segurança até serem atualizados para o patch ou a versão secundária seguinte.

Atualizações automáticas para o novo marco do SO otimizado para contentores

A versão de patch seguinte para uma versão secundária do GKE no período de apoio técnico alargado usa um marco do SO otimizado para contentores mais recente do que as versões de patch anteriores. O GKE atualiza automaticamente os clusters das seguintes formas quando a nova versão de patch se torna um destino de atualização automática:

  • Atualizações do plano de controlo:
    • O GKE atualiza o plano de controlo para a versão de patch seguinte, como habitualmente.
  • Atualizações de nós:
    • O GKE não atualiza os nós para a versão de patch seguinte.
    • O GKE atualiza os nós para a versão secundária seguinte no sentido do fim do apoio técnico alargado, como habitualmente. Para saber mais, consulte o artigo Atualizações automáticas no final do apoio técnico.

Uma vez que a nova versão de marcos pode introduzir alterações incompatíveis com as suas cargas de trabalho, o GKE pausa as atualizações automáticas de nós para a versão de patch seguinte. Pode atualizar manualmente para a nova versão de patch se tiver determinado que as suas cargas de trabalho são compatíveis com a próxima etapa do SO otimizado para contentores. Se atualizar manualmente os nós para uma versão de patch que use o novo marco do SO otimizado para contentores, o GKE retoma as atualizações automáticas de patches dos nós porque os nós executam agora o novo marco.

Agrupamento de notificações quando as novas versões de patches usam o novo marco

O GKE envia uma notificação do cluster a informar quando esta situação ocorre. Esta notificação é enviada quando a primeira versão de patch que usa o novo marco do SO otimizado para contentores fica disponível no canal Extended.

Quando receber esta notificação, avalie se quer atualizar manualmente os nós para a versão de patch ou secundária seguinte ou não receber versões de patch posteriores para esta versão secundária durante o período de apoio técnico alargado. Para saber mais, consulte o artigo As novas versões de patches mudam para um novo marco do SO otimizado para contentores durante o apoio técnico alargado.

Esquema de controlo de versões

O GKE anexa uma versão de patch do GKE à norma da indústria com versões semânticas do Kubernetes(x.y.z-gke.N):

Versão principal do Kubernetes (x)
Normalmente, as versões principais são incrementadas se forem introduzidas alterações incompatíveis com versões anteriores 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 uma duração de aproximadamente 15 semanas. As APIs descontinuadas podem ser removidas com uma nova versão secundária, por exemplo, com a versão 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 é o lançamento secundário que se segue ao Kubernetes 1.31.
Versão do patch do Kubernetes (z)
As novas versões de patches do Kubernetes (como a 1.32.6) para utilização com o GKE ficam normalmente disponíveis todas as semanas. As versões de patches são implementadas em cada zona de forma incremental.
Versão do patch do GKE (-gke.N)
Uma versão de patch com um sufixo -gke.N (como 1.32.6-gke.N) pode incluir atualizações de segurança e correções de erros para o GKE juntamente com o software Kubernetes upstream de código aberto. Estas atualizações ou correções são necessárias para a compatibilidade e a interoperabilidade com o Google Cloud.

Verificar versões disponíveis e predefinidas

Para ver informações sobre as versões disponíveis, consulte as notas de lançamento do GKE.

Também pode verificar que versões do Kubernetes estão disponíveis e são predefinidas numa determinada zona a partir da consola ou através da CLI do Google Cloud. Google Cloud

Use a Google Cloud consola para verificar as versões

Para ver as versões predefinidas e disponíveis, siga estes passos:

  1. Aceda à página do Google Kubernetes Engine na Google Cloud consola.

    Aceda ao Google Kubernetes Engine

  2. Clique em Criar.

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

  4. Na secção Tipo de localização, escolha um tipo de localização e a localização pretendida para o seu cluster.

  5. Na secção Versão do plano de controlo, selecione um canal de lançamento. Todas as versões atualmente disponíveis são apresentadas para esse canal. A versão predefinida é selecionada automaticamente.

Use a CLI gcloud para verificar as versões

Para ver que versões estão disponíveis e quais são as predefinições, execute um dos seguintes comandos gcloud para o seu tipo de cluster. Cada separador fornece comandos para verificar as versões de um canal de lançamento específico ou de nenhum canal (anteriormente estático).

Inovação

Para ver as versões predefinidas e disponíveis no Rapidcanal de lançamento, execute os seguintes comandos:

Versão predefinida

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

Versões disponíveis

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

Substitua o seguinte:

Normal

Para ver as versões predefinidas e disponíveis no Regularcanal de lançamento, execute os seguintes comandos:

Versão predefinida

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

Versões disponíveis

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

Substitua o seguinte:

Estável

Para ver as versões predefinidas e disponíveis no Stablecanal de lançamento, execute os seguintes comandos:

Versão predefinida

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

Versões disponíveis

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

Substitua o seguinte:

Vista expandida

Para ver as versões predefinidas e disponíveis no Extendedcanal de lançamento, execute os seguintes comandos:

Versão predefinida

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

Versões disponíveis

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

Substitua o seguinte:

Sem canal

Para ver as versões predefinidas e disponíveis para nenhum canal (anteriormente estático), execute os seguintes comandos:

Versão predefinida

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

Versões do plano de controlo disponíveis

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

Versões do nó disponíveis

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

Substitua o seguinte:

Especificar a versão do cluster

Esta secção aplica-se apenas a clusters criados no modo padrão.

Quando cria ou atualiza um cluster através da CLI gcloud, pode especificar uma versão do cluster através da flag --cluster-version. Pode usar uma versão específica, como 1.9.7-gke.N. Também pode usar um alias de versão:

  • latest: especifica a versão do Kubernetes mais elevada suportada atualmente no GKE na zona ou na região do cluster.
  • 1.X: especifica a versão de patch+gke.N válida mais elevada na versão secundária 1.X
  • 1.X.Y: especifica o patch gke.N válido mais elevado no lançamento do patch 1.X.Y.
  • -: para planos de controlo de clusters, especifica a versão predefinida do Kubernetes para planos de controlo. Para atualizações de nós, especifica a versão em que o plano de controlo do cluster está a ser executado.

A criação ou a atualização de um cluster especificando a versão como latest não oferece atualizações automáticas. Ative as atualizações automáticas de nós para garantir que os nós no seu cluster estão atualizados com a versão estável mais recente.

Especificar a versão do nó

Esta secção aplica-se apenas a clusters criados no modo padrão. Nos clusters do Autopilot, os nós são atualizados automaticamente para a versão do plano de controlo e não pode especificar uma versão.

Quando cria ou atualiza um conjunto de nós, pode especificar a respetiva versão. Por predefinição, os nós executam a mesma versão do GKE que o plano de controlo. Os nós não podem ter mais de duas versões secundárias anteriores aos planos de controlo.

Com raras exceções, as versões dos nós permanecem disponíveis, mesmo que a versão do cluster já não esteja disponível.

Política de incompatibilidade de versões do GKE

A política de variação da versão do GKE garante que um cluster do GKE mantém a compatibilidade entre o plano de controlo e os nós. Num cluster do GKE, os nós podem corresponder à versão do plano de controlo ou executar até duas versões secundárias anteriores à do plano de controlo.

Os nós não podem executar versões mais recentes do que a versão do plano de controlo. Por exemplo, se o plano de controlo do cluster executar a versão 1.31, os nós podem executar as seguintes versões: 1.31, 1.30 ou 1.29, mas não 1.28 ou anterior. A versão dos nós não pode ser mais recente do que a versão do plano de controlo devido à política de desvio de versão do OSS do Kubernetes.

Para garantir a capacidade de suporte e a fiabilidade, os nós devem usar uma versão suportada, independentemente de seguirem uma variação de versão válida.

Identifique clusters com uma variação de versão não suportada

O GKE identifica clusters nos quais os nós estão a executar uma versão incompatível com o plano de controlo devido à diferença de versões. O GKE recomenda que atualize os nós que executam esta versão não suportada, fornecendo estas orientações com uma estatística e uma recomendação através do serviço Recommender. Para saber mais sobre como gerir estatísticas e recomendações do Recomendador, consulte o artigo Otimize a sua utilização do GKE com estatísticas e recomendações.

Para encontrar clusters com uma variação de versão não suportada, pode usar um dos seguintes métodos:

  • Use a Google Cloud consola.
  • Use a CLI gcloud ou a API Recommender, especificando o CLUSTER_VERSION_SKEW_UNSUPPORTED subtipo de recomendador.

Para ver instruções, saiba como ver estatísticas e recomendações.

Para implementar esta recomendação, atualize todos os nós que estejam a executar uma versão secundária mais de duas versões secundárias anterior à versão do plano de controlo.

Suporte para ignorar versões secundárias

O GKE não permite ignorar versões secundárias para o plano de controlo do cluster. No entanto, pode ignorar versões de patch. Os nós de trabalho podem ignorar versões secundárias. Por exemplo, pode atualizar um node pool da versão 1.32 para a 1.34, ignorando a versão 1.33.

Para atualizar um cluster em várias versões secundárias, atualize o painel de controlo uma versão secundária de cada vez e atualize os nós de trabalho para a mesma versão de cada vez. Por exemplo, para atualizar o plano de controlo da versão 1.32 para a versão 1.34, atualize-o primeiro da versão 1.32 para a versão 1.33. Em seguida, atualize os nós de trabalho para corresponderem à versão do plano de controlo e, depois, repita o processo para atualizar da versão 1.33 para a versão 1.34.

A atualização dos nós de trabalho para corresponder às versões ajuda a evitar a divergência de versões não suportada. Recomendamos que evite ignorar versões sempre que possível. Normalmente, ignorar as versões dos nós de trabalho implica um âmbito de testes maior que, embora seja gerível, requer mais consideração.

Em alternativa, pode criar um novo cluster com a versão pretendida e implementar novamente as suas cargas de trabalho.