Sobre os canais de lançamento

Use canais de lançamento do Google Kubernetes Engine (GKE) para escolher versões para os clusters com o equilíbrio escolhido entre disponibilidade e estabilidade de recursos.

O GKE faz upgrade de todos os clusters automaticamente ao longo do tempo, incluindo aqueles não inscritos em um canal de lançamento, para garantir que eles recebam atualizações de segurança, correções de problemas conhecidos, novos recursos e executem uma versão compatível do Kubernetes. É possível controlar o tempo dos upgrades com janelas de manutenção e exclusões.

Recomendamos registrar o cluster em um canal de lançamento, porque isso oferece mais controle em relação ao escopo das exclusões de manutenção, impedindo tipos específicos de upgrades em vez de todos os upgrades e sequenciando o lançamento de upgrades de cluster. Os clusters do Autopilot só podem ser registrados em um canal de lançamento.

Se você não registrar o cluster padrão em um canal de lançamento, será possível desativar os upgrades automáticos de nós para os pools de nós selecionados e manualmente gerenciar upgrades dos nós nesses pools. No entanto, os planos de controle de todos os clusters são atualizados automaticamente e, quando uma versão atinge o fim do suporte, os planos de controle do cluster e os nós são atualizados automaticamente, independentemente da inscrição no canal de lançamento. Para saber mais, consulte a comparação entre clusters registrados e não registrados em um canal de lançamento.

Quais canais estão disponíveis?

A tabela a seguir explica as propriedades dos canais de lançamento disponíveis, cada um oferecendo uma compensação entre a disponibilidade de recursos e a estabilidade. Todos os canais oferecem versões compatíveis do GKE e são considerados de disponibilidade geral (embora os recursos individuais nem sempre sejam de disponibilidade geral, conforme marcado). As versões do Kubernetes nesses canais são versões oficiais do Kubernetes e incluem as APIs Kubernetes Beta e de disponibilidade geral (conforme marcado).

Canal Disponibilidade da nova versão do Kubernetes Quando usar esse canal
Rápido Várias semanas após o lançamento do GA de código aberto Instale a versão mais recente do Kubernetes o quanto antes e use os novos recursos do GKE assim que estiverem disponíveis no GA. Seu cluster é frequentemente atualizado para permanecer na versão de patch mais recente disponível e fornece recursos mais recentes do Kubernetes. Os clusters inscritos no Canal rápido usam versões do GA. No entanto, recomendamos o uso do Canal rápido para testar a API e as versões mais recentes do Kubernetes em ambientes em pré-produção.
Normal (padrão) Dois a três meses após o lançamento no formato rápido Acesse os recursos do GKE e do Kubernetes logo após o lançamento em disponibilidade geral, mas em uma versão que foi qualificada por um período mais longo. Ela oferece um equilíbrio de disponibilidade e estabilidade de recurso, e é o que recomendamos para a maioria dos usuários.
Estável Dois a três meses após o lançamento no formato normal Priorize a estabilidade em relação aos novos recursos. O GKE lança alterações e novas versões por último neste canal, depois de ser validado nos canais rápido e regular, o que permite ainda mais tempo para validação.
Estendido Alinhado com o canal normal Use esse canal para receber suporte de longo prazo, mantendo um cluster executando uma versão secundária pelo maior tempo possível. Para saber mais, consulte Receber suporte de longo prazo com o Canal estendido.
Nenhum canal (não recomendado) Alinhado com o canal normal Essa opção não é recomendada. O plano de controle e os nós são atualizados automaticamente de acordo com os canais Regular e Stable. Use essa opção de configuração quando precisar desativar os upgrades automáticos de nós no nível do pool de nós. Como alternativa, com os canais de lançamento, é possível desativar os upgrades automáticos de nós no nível do cluster. Para mais detalhes, consulte a comparação entre clusters registrados e não registrados em um canal de lançamento.

Quando você registra um cluster em um canal de lançamento, ele é atualizado automaticamente na data especificada na coluna Upgrade automático da programação de lançamento do GKE ou após essa data.

Quando uma versão acumula uso e demonstra estabilidade em clusters no canal Rápido, ela é promovida para o canal Normal. Por fim, a versão é promovida para o canal Estável, que recebe apenas atualizações de alta prioridade. Cada promoção sinaliza um nível gradual de estabilidade e preparação para a produção, com base no desempenho observado dos clusters que executam essa versão.

Patches de segurança críticos são entregues a todos os canais de lançamento para proteger seus clusters e a infraestrutura do Google. Em raras situações de emergência, o GKE pode fazer upgrade automático dos clusters para versões que ainda não estão disponíveis no canal de lançamento.

Quais versões estão disponíveis em um canal

Cada canal de lançamento oferece várias versões secundárias. Essas versões atingiram os padrões de qualificação para esse canal específico. Esse conjunto de versões disponíveis inclui uma versão padrão para a criação de clusters, que é selecionada em um conjunto de versões disponíveis desse canal. Para saber quais versões estão disponíveis em um canal de lançamento, siga as instruções para ver as versões padrão e disponíveis para canais de lançamento.

  • Novas versões de patch ficam disponíveis pelo menos uma semana antes de se tornarem um destino de upgrade automático para todos os canais.
  • Novos lançamentos secundários são disponibilizados:
    • pelo menos duas semanas antes de se tornarem um destino de upgrade automático para o canal rápido.
    • pelo menos quatro semanas antes de se tornarem um destino de upgrade automático para os canais Normal e Estável.

É possível testar uma versão recém-disponível do GKE antes de fazer upgrade do ambiente de produção. Por exemplo, é possível se inscrever em notificações de upgrade para ser informado sobre versões recém-disponíveis e, em seguida, fazer upgrade de um ambiente de pré-produção para a nova versão antes que ela se torne o destino de upgrade automático para clusters no ambiente de produção.

Se você precisar manter um cluster em uma versão específica, por exemplo, para validar ou testar versões mais recentes antes do upgrade, recomendamos o uso de exclusões de manutenção.

Depois que uma versão secundária for disponibilizada em um canal de lançamento, ela permanecerá disponível nesse canal para clusters novos ou atuais até atingir a data de fim do suporte.

O que acontece quando uma versão se torna um destino de upgrade automático em um canal de lançamento?

O GKE faz upgrade automático dos clusters ao longo do tempo para novas metas de upgrade automático. Quando novos destinos de upgrade automático estão disponíveis, o GKE avalia se o cluster específico deve ser atualizado para essa nova versão. O GKE considera se o cluster tem políticas de manutenção ou outras restrições que impedem upgrades automáticos e não ignora esses motivos, exceto em situações raras de emergência.

É possível encontrar destinos de upgrade automático para seus clusters das seguintes maneiras:

  • Para receber destinos de upgrade automático de um cluster específico, consulte Receber informações sobre upgrades de um cluster.
  • A tabela de versões atuais fornece uma lista dos destinos de upgrade automático atuais para cada canal de lançamento. A versão específica que se aplica ao seu cluster depende da versão secundária e das restrições específicas dele.
  • As notas da versão do GKE listam novos destinos de upgrade automático para clusters que executam versões secundárias específicas com Atualizações de versão, como a nota 2024-R33.

Se tiverem passado 10 dias após uma nova versão se tornar um destino de upgrade automático para a versão secundária do cluster no canal de lançamento e os upgrades automáticos não tiverem sido iniciados para o cluster, o atraso pode ser causado por um dos seguintes motivos:

  • Seu cluster não está qualificado temporariamente para os upgrades automáticos. Isso pode ocorrer porque:
    • O cluster está fora do período de uma janela de manutenção configurada.
    • O cluster está dentro do período de uma exclusão de manutenção.
    • Os upgrades automáticos são pausados porque o cluster usa recursos descontinuados do Kubernetes que são removidos na próxima versão secundária.
    • O cluster foi atualizado automaticamente para uma versão de patch há menos de 24 horas.
    • O cluster foi atualizado automaticamente para uma versão secundária há menos de 30 dias, e o destino do upgrade automático é uma nova versão secundária.
  • O GKE pausou o lançamento do novo destino de upgrade automático por motivos técnicos ou comerciais:
    • Problemas técnicos foram descobertos na nova versão.
    • Há um congelamento da produção devido a um período crítico de negócios, como a Black Friday.

O destino recomendado do upgrade automático é a versão para a qual o GKE faz upgrade gradual dos clusters ao longo do tempo. De todos os destinos de upgrade automático em um canal de lançamento, o GKE move seus clusters para mais perto dessa versão quando realiza upgrades automáticos.

Em vários upgrades automáticos, exceto restrições que impedem upgrades automáticos, o GKE atualiza seus clusters progressivamente para mais perto do destino de upgrade automático recomendado do canal de lançamento, até que o cluster atinja o destino. Depois de atingir a meta, o cluster usa continuamente a meta de upgrade automático recomendada atual, passando para a nova meta recomendada quando ela for lançada.

Qual é a versão padrão?

Quando você cria um cluster em um canal de lançamento, por padrão, ele usa a versão de patch padrão para criação de cluster no canal de lançamento selecionado. No entanto, é possível especificar uma versão disponível diferente ao criar um cluster no canal de lançamento.

Os canais de lançamento têm várias versões secundárias disponíveis, e a versão padrão às vezes pode ser um dos destinos de atualização automática de um canal de lançamento.

Sobre como receber versões de patch antes

É possível receber versões de patch mais cedo com upgrades automáticos ou manuais usando os métodos descritos nesta seção.

Upgrades automáticos acelerados de patch

Primeiro, o GKE apresenta uma nova versão de patch a um canal de lançamento disponibilizando a versão para criação de novos clusters e upgrades manuais. Depois que o GKE determinar que a versão do patch está qualificada, ele vai definir a nova versão como um destino de upgrade automático, ou seja, o GKE vai começar a fazer upgrade automático dos clusters para essa nova versão. O período entre a disponibilidade da versão e as atualizações automáticas é normalmente de pelo menos uma semana, mas depende do canal de lançamento e das circunstâncias específicas de qualificação da versão.

Para mais informações sobre a disponibilidade da versão atual, faça o seguinte:

Se você quiser receber upgrades de patch assim que a versão estiver disponível e antes que o GKE defina a versão como um destino de upgrade automático no canal, use os upgrades automáticos acelerados de patch. Essa configuração pode ser útil se você quiser receber patches de segurança o mais rápido possível por meio de upgrades automáticos.

É necessário entender os riscos associados ao upgrade automático do cluster em um cronograma acelerado antes que o GKE determine que os clusters no canal precisam ser atualizados automaticamente para a nova versão do patch. Essa programação acelerada pula uma etapa no processo de qualificação para versões de patch em canais de lançamento. Todas as versões de patch, não apenas as que têm patches de segurança, são atualizadas com esse cronograma acelerado. Essa configuração não afeta os upgrades de versão secundária e só está disponível para clusters inscritos em um canal de lançamento.

Essa configuração afeta apenas o momento em que o GKE faz upgrade automático de um cluster para uma nova versão de patch. O GKE ainda segue janelas e exclusões de manutenção, segue a ordem de uma sequência de lançamento e aplica outras práticas padrão normalmente usadas para upgrades automáticos.

Para mais informações sobre como definir esse recurso, consulte Usar upgrades automáticos de patch acelerados.

Como alternativa, é possível fazer upgrade manual dos clusters se quiser fazer upgrade para uma versão de patch específica assim que ela estiver disponível e antes de ser definida como um destino de upgrade automático.

Como executar versões de patch em um canal mais recente

Além das versões de patch disponíveis listadas para um canal de lançamento, é possível executar versões de patch de canais de lançamento mais recentes do que aquele em que seu cluster está inscrito se a versão secundária estiver disponível no canal de lançamento do cluster e você usar a CLI gcloud ou a API GKE.

Por exemplo, se as seguintes versões estavam disponíveis nos canais rápido e regular:

  • Rápido: 1.23.2-gke.700, 1.22.4-gke.1500
  • Regular: 1.21.4-gke.400, 1.22.1-gke.400

Um cluster inscrito no Canal normal que está executando a versão 1.22.1-gke.400 do GKE pode fazer upgrade manual para 1.22.4-gke.1500, mas não para 1.23.2-gke.700 porque é uma versão secundária diferente.

Para fazer upgrade manual para uma versão de patch em um canal mais recente, o plano de controle do cluster precisa executar uma versão de patch com a mesma versão secundária. Por exemplo, se o cluster estiver executando 1.21.3-gke.200, primeiro faça upgrade manual do cluster para uma versão de patch disponível no canal de lançamento atual, 1.22.1-gke.400. É possível fazer upgrade do cluster para 1.22.4-gke.1500.

Também é possível criar um novo cluster que execute a 1.22.4-gke.1500 e esteja inscrito no Canal normal.

O GKE mantém o cluster na versão de patch do canal mais recente até que uma nova versão de destino do upgrade automático fique disponível no canal inscrito para o cluster.

Como ficar por dentro das novidades de um canal

Para saber quais são as novidades de um canal de lançamento, confira As notas de lançamento. Há notas de versão separadas para cada canal de lançamento, além das Notas de lançamento gerais.

Canal de lançamento Notas de lançamento
Canal rápido HTML ou Atom feed.
Canal normal HTML ou Atom feed.
Canal estável HTML ou Atom feed.

Escolha o melhor canal de lançamento para seu cluster

Os canais incluem apenas versões de disponibilidade geral do Kubernetes, e cada canal representa um nível diferente de qualidade e maturidade das versões do Kubernetes e do GKE. O diagrama a seguir ilustra o ciclo de adoção dos canais de lançamento:

Ciclo de adoção dos canais de lançamento

Como mostrado no diagrama, os canais de lançamento disponíveis usam versões no meio do ciclo de adoção, incluindo os Primeiros usuários (canal rápido), Maioria inicial (canal normal) e Maioria (canal estável). A primeira parte do ciclo de adoção é a dos Inovadores, que testam os recursos mais recentes usando a versão upstream do Kubernetes. A última parte do ciclo de adoção é a Maioria atrasada, em que você usa uma versão que está prestes a ser descontinuada e precisa fazer a transição para uma versão suportada.

Nos ambientes de pré-produção, use o Canal rápido para versões mais recentes em que é possível testar os recursos assim que eles estiverem disponíveis para todos.

Para as cargas de trabalho de produção que exigem maturidade em relação aos recursos mais recentes, recomendamos usar o canal Regular (padrão) ou o canal Estável.

  • Para acompanhar atentamente novos recursos, use o canal Regular que oferece equilíbrio entre estabilidade e atualização da versão do Kubernetes OSS.
  • Se o requisito for maturidade, principalmente para clusters de produção, use o canal estável.

O GKE realiza upgrade de clusters para uma versão mais recente que atenda à standards de qualidade do canal. No entanto, recomendamos fazer upgrade dos clusters com antecedência, porque isso oferece:

  • melhor controle dos upgrades e alinhamento com seu horário de trabalho;
  • melhor previsibilidade, já que o GKE pula os clusters de upgrade automático que atendam ao destino da versão, ou seja, clusters que foram atualizados manualmente para a próxima versão de destino. Os nós são atualizados automaticamente para a versão recomendada no canal selecionado para se alinhar à versão do plano de controle e proteger você contra vulnerabilidades e desvio da versão incompatível.

Receber suporte de longo prazo com o Canal estendido

O GKE oferece suporte de longo prazo para versões secundárias do Kubernetes pelo canal estendido. Com esse canal, você pode usar uma versão secundária por até 24 meses. Após o período de suporte padrão de 14 meses, seu cluster recebe patches de segurança por aproximadamente mais 10 meses durante o período de suporte estendido.

Como o GKE faz upgrade automático dos clusters no canal estendido

Para clusters inscritos no canal estendido, o GKE faz upgrade automático da seguinte maneira:

  • Durante o período de suporte padrão: o GKE faz upgrade dos clusters para versões de patch mais recentes da mesma versão secundária seguindo a mesma cadência do Canal normal.
  • Durante o período de suporte estendido: o GKE continua a fornecer atualizações de patch de segurança para a versão secundária. Cerca de dois meses antes do fim do suporte estendido, o GKE começa a fazer upgrade dos clusters para a próxima versão secundária, a menos que o cluster esteja usando recursos ou APIs descontinuados. É possível usar exclusões de manutenção para impedir upgrades de versão secundária até o fim do suporte estendido.
  • Ao fim do suporte estendido: o GKE faz upgrade de todos os clusters que ainda executam a versão secundária sem suporte, independentemente de problemas de bloqueio. Não é possível configurar exclusões de manutenção após essa data.

Para saber mais sobre os diferentes períodos de disponibilidade e quais upgrades o GKE oferece durante o período de suporte estendido, consulte Ciclo de vida da versão secundária do GKE.

Limitações para registrar um cluster no canal Extended

Confira as seguintes limitações para clusters registrados no canal Extended:

Preços do suporte estendido

Se você quiser registrar um cluster no canal Extended, confira os preços do suporte estendido. Os custos de pagamento por uso são aplicados quando o cluster está inscrito no canal estendido e a versão secundária do cluster entra no período de suporte estendido.

Práticas recomendadas para o canal Extended

Confira os cenários a seguir para entender como usar o canal estendido e minimizar a interrupção causada por upgrades de versão secundária.

Os cenários compatíveis exigem alguma ação manual ao longo do tempo para aproveitar ao máximo o canal. Não recomendamos inscrever um cluster no canal sem planos de migrar para a próxima versão secundária, já que o GKE eventualmente fará upgrade do cluster para versões secundárias mais recentes com a mesma frequência que outros canais, e seu cluster poderá incorrer em custos maiores e receber novos recursos por último.

Cenários compatíveis e incompatíveis

Para saber mais sobre cenários compatíveis e não compatíveis, consulte a tabela a seguir e Use o Canal estendido quando precisar de suporte de longo prazo para mais detalhes. Uma marca de seleção () indica um cenário compatível:

Cenário de upgrade Com suporte Resumo Tempo entre mudanças de versão secundária Ação manual necessária
Permanecer temporariamente em uma versão secundária por mais tempo Permanecer em uma versão secundária para atenuar um problema que impede upgrades. Mesma frequência média, com interrupção para tempo extra em uma versão secundária.
  • Mover temporariamente um cluster para e do canal Extended.
  • Faça upgrade manual do cluster para a nova versão secundária quando estiver tudo pronto.
Fazer upgrade manual da versão secundária uma ou duas vezes por ano Receber novos recursos, mas com upgrades secundários menos frequentes, quando for ideal para as cargas de trabalho no cluster. Uma a duas vezes por ano.
  • Faça upgrade manual do cluster para uma versão secundária mais recente.
Não fazer nada e receber upgrades menores com a mesma frequência Receba upgrades de versão secundária com a mesma frequência que outros canais e novos recursos o mais tarde possível. A cada quatro meses, em média.
  • Monitorar upgrades automáticos de versões secundárias de versões sem suporte.

Clusters não registrados em um canal de lançamento

Não recomendamos essa opção de configuração devido às limitações com clusters não inscritos em canais de lançamento, mas é possível optar por não inscrever um cluster padrão em um canal de lançamento (conhecido como sem canal e anteriormente como estático). Não use essa opção a menos que não seja possível fazer upgrade automático de pools de nós individuais e você precise fazer upgrade desses nós manualmente. Se o cluster não estiver inscrito em um canal de lançamento, será possível desativar o upgrade automático de nós para os pools de nós selecionados. Com os canais de lançamento, é possível alcançar o mesmo resultado no nível do cluster em todos os pools de nós. No entanto, independentemente da inscrição no canal de lançamento, os planos de controle de todos os clusters são atualizados automaticamente e, quando uma versão atinge o fim do suporte, os planos de controle e os nós do cluster são atualizados automaticamente.

Recomendamos que, se você quiser impedir upgrades automáticos de todo o cluster padrão ou de todos os pools de nós, use uma exclusão de manutenção com o cluster registrado em um canal de lançamento. Com as exclusões de manutenção, é possível desativar os upgrades automáticos de nós para todos os pools de nós. Já os upgrades automáticos de nós podem ser desativados no nível do pool de nós caso o cluster não esteja inscrito em um canal de lançamento.

Comparação entre clusters registrados e não registrados em um canal de lançamento

Consulte a tabela a seguir para entender as semelhanças e diferenças entre registrar e não registrar o cluster em um canal de lançamento:

Recurso Cluster registrado em um canal de lançamento Cluster não registrado em um canal de lançamento
Comportamento de upgrade compartilhado
Cronograma do upgrade Alinhados com o respectivo canal de lançamento
  • Mesma data de início do upgrade automático que o Canal estável para versões secundárias
  • Mesmas versões secundárias disponíveis, versões de upgrade automático de patch e versão padrão que o canal normal
  • Mesmas versões de patch disponíveis que o Canal rápido para as versões secundárias disponíveis no canal normal
Upgrades automáticos acelerados de patch Disponível Indisponível
Controle da interrupção do pool de nós
Janelas de manutenção Disponível Disponível
Exclusões de manutenção Escopos de exclusão de manutenção disponíveis:
  • "Sem upgrades" (30 dias)
  • "Sem upgrades secundários" (até o fim do suporte)
  • "Nenhum upgrade secundário ou de nó" (até o fim do suporte)
 Restrito ao escopo "Sem upgrades" (30 dias)
Sequenciamento de lançamento Disponível com sequências baseadas em frota e em escopo Indisponível
Suporte de longo prazo Disponível apenas no canal de lançamento estendido Indisponível
Piloto automático Disponível Indisponível

Diferenças entre clusters de canal rápido e clusters alfa

Os clusters criados usando o canal de lançamento rápido não são clusters Alfa. Veja as diferenças:

  • Os clusters que usam canais de lançamento podem ser atualizados, e o upgrade automático é ativado (e não pode ser desativado). Clusters alpha não podem receber upgrade.
  • Os clusters que usam canais de lançamento não expiram. Clusters Alfa expiram após 30 dias.
  • As APIs Alpha Kubernetes não estão ativadas em clusters que usam canais de lançamento.

A seguir