Acerca dos canais de lançamento

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

O GKE atualiza automaticamente todos os clusters ao longo do tempo, incluindo os que não estão inscritos num canal de lançamento, para garantir que recebem atualizações de segurança, correções de problemas conhecidos, novas funcionalidades e executam uma versão suportada do Kubernetes. Pode controlar a calendarização das atualizações com períodos de manutenção e exclusões.

Recomendamos que inscreva o cluster num canal de lançamento, uma vez que isto lhe dá o maior controlo no que diz respeito ao âmbito das exclusões de manutenção, impedindo tipos específicos de atualizações em vez de todas as atualizações, e sequenciando a implementação de atualizações do cluster. Só é possível inscrever clusters do Autopilot num canal de lançamento.

Se não inscrever o seu cluster Standard num canal de lançamento, pode desativar as atualizações automáticas de nós para determinados node pools e gerir manualmente as atualizações dos nós nestes node pools. No entanto, os painéis de controlo de todos os clusters são atualizados automaticamente e, quando uma versão atinge o fim do apoio técnico, os painéis de controlo e os nós do cluster são atualizados automaticamente, independentemente da inscrição no canal de lançamento. Para saber mais, consulte a comparação entre clusters inscritos e não inscritos num canal de lançamento.

Que canais estão disponíveis

A tabela seguinte explica as propriedades dos canais de lançamento disponíveis, cada um oferecendo uma compensação entre a disponibilidade e a estabilidade das funcionalidades. Todos os canais oferecem versões suportadas do GKE e são considerados geralmente disponíveis (DG), embora as funcionalidades individuais nem sempre sejam DG, conforme indicado. Os lançamentos do Kubernetes nestes canais são lançamentos oficiais do Kubernetes e incluem APIs do Kubernetes GA e beta.

Canal Nova disponibilidade de lançamentos do Kubernetes Quando usar este canal
Inovação Várias semanas após o GA de código aberto a montante Receba a versão mais recente do Kubernetes o mais cedo possível e possa usar as novas funcionalidades do GKE no momento em que entram em disponibilidade geral. O GKE atualiza o seu cluster com frequência para se manter na versão de patch mais recente disponível e oferecer capacidades mais recentes do Kubernetes. Os clusters subscritos no canal rápido usam versões do GA. No entanto, recomendamos que use o canal rápido para testar versões e APIs mais recentes do Kubernetes em ambientes de pré-produção.
Normal (predefinição) 2 a 3 meses após o lançamento na versão rápida Aceder às funcionalidades do GKE e do Kubernetes pouco depois de serem lançadas em DG, mas numa versão que foi qualificada durante um período mais longo. Oferece um equilíbrio entre a disponibilidade de funcionalidades e a estabilidade do lançamento, e é o que recomendamos para a maioria dos utilizadores.
Estável 2 a 3 meses após o lançamento no modo Regular Priorizar a estabilidade em detrimento das novas funcionalidades. O GKE implementa alterações e novas versões neste canal por último, após a validação nos canais Rápido e Regular, o que permite ainda mais tempo para validação.
Vista expandida Alinhado com o canal normal Use este canal para receber apoio técnico a longo prazo, mantendo um cluster a executar uma versão secundária durante o maior tempo possível. Para saber mais, consulte o artigo Obtenha apoio técnico a longo prazo com o canal Extended.
Sem canal (não recomendado) Alinhado com o canal normal Esta opção não é recomendada. O painel de controlo e os nós são atualizados automaticamente de acordo com os canais Regular e Estável. Quando precisa de desativar as atualizações automáticas de nós ao nível de um conjunto de nós, pode usar esta opção de configuração. Em alternativa, com os canais de lançamento, pode desativar as atualizações automáticas de nós ao nível do cluster. Para mais detalhes, consulte a comparação entre clusters inscritos e não inscritos num canal de lançamento.

Quando inscreve um cluster num canal de lançamento, esse cluster é atualizado automaticamente na data especificada na coluna Atualização automática do cronograma de lançamentos do GKE ou após essa data.

Quando uma versão acumula utilização e demonstra estabilidade em todos os clusters no canal Rápido, é promovida para o canal Normal. Eventualmente, a versão é promovida para o canal estável, que só recebe atualizações de alta prioridade. Cada promoção indica um nível de estabilidade e disponibilidade para produção crescente, com base no desempenho observado dos clusters que executam essa versão.

Os patches de segurança críticos são fornecidos a todos os canais de lançamento para proteger os seus clusters e a infraestrutura da Google. Em situações de emergência raras, o GKE pode atualizar automaticamente os clusters para versões que ainda não estão disponíveis no respetivo canal de lançamento.

Que versões estão disponíveis num canal

Cada canal de lançamento oferece várias versões secundárias. Estas versões cumpriram as normas de qualificação para esse canal específico. Este conjunto de versões disponíveis inclui uma versão predefinida para a criação de clusters, que é selecionada a partir de um conjunto de versões disponíveis desse canal. Para ver que versões estão disponíveis num canal de lançamento, siga as instruções para ver as versões predefinidas e disponíveis para os canais de lançamento.

  • As novas versões de patches ficam disponíveis pelo menos uma semana antes de se tornarem um destino de atualização automática para todos os canais.
  • Novos lançamentos secundários ficam disponíveis:
    • Pelo menos duas semanas antes de se tornar um alvo de atualização automática para o canal Rápido.
    • pelo menos, quatro semanas antes de se tornar um alvo de atualização automática para os canais Regular e Stable.

Pode testar uma versão do GKE recentemente disponível antes de atualizar o seu ambiente de produção. Por exemplo, pode subscrever notificações de atualização para ser informado das versões recentemente disponíveis e, em seguida, atualizar proativamente um ambiente de pré-produção para a nova versão antes de esta se tornar o destino de atualização automática para clusters no seu ambiente de produção.

Se precisar de manter um cluster numa versão específica, por exemplo, para validar ou testar versões mais recentes antes da atualização, recomendamos que use exclusões de manutenção.

Depois de uma versão secundária ser disponibilizada num canal de lançamento, esta permanece disponível nesse canal de lançamento para clusters novos ou existentes até atingir a respetiva data de fim do apoio técnico.

O que acontece quando uma versão se torna um destino de atualização automática num canal de lançamento

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

Pode encontrar alvos de atualização automática para os seus clusters das seguintes formas:

Se tiverem passado 10 dias desde que uma nova versão se tornou um destino de atualização automática para a versão secundária do cluster no canal de lançamento e as atualizações automáticas não tiverem sido iniciadas para o cluster, o atraso pode dever-se a um dos seguintes motivos:

  • O seu cluster não é temporariamente elegível para atualizações automáticas. Isto 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.
    • As atualizações automáticas estão em pausa porque o seu cluster usa funcionalidades do Kubernetes descontinuadas que são removidas 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 da atualização automática é uma nova versão secundária.
  • O GKE pausou a implementação do novo destino de atualização automática por motivos técnicos ou empresariais:
    • Foram descobertos problemas técnicos com a nova versão.
    • Existe uma suspensão da produção devido a uma época comercial crítica, como a Black Friday.

O destino de atualização automática recomendado é a versão para a qual o GKE atualiza gradualmente os seus clusters ao longo do tempo. De todos os destinos de atualização automática num canal de lançamento, o GKE move os seus clusters para mais perto desta versão quando faz atualizações automáticas.

Ao longo de várias atualizações automáticas, exceto se existirem restrições que impeçam as atualizações automáticas, o GKE atualiza os seus clusters progressivamente até atingirem o destino de atualização automática recomendado do canal de lançamento, até que o cluster atinja o destino. Depois de atingir o destino, o cluster usa continuamente o destino de atualização automática recomendado existente, passando para o novo destino recomendado quando for lançado.

Qual é a versão predefinida?

Quando cria um cluster num canal de lançamento, por predefinição, o cluster usa a versão de patch predefinida para a criação de clusters no canal de lançamento selecionado. No entanto, pode especificar uma versão disponível diferente quando cria um cluster no canal de lançamento.

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

Acerca da obtenção de versões de patches mais cedo

Pode obter versões de patch mais cedo com atualizações automáticas ou manuais através dos métodos descritos nesta secção.

Atualizações automáticas aceleradas de patches

O GKE introduz primeiro uma nova versão de patch num canal de lançamento tornando a versão disponível para a criação de novos clusters e atualizações manuais. Depois de o GKE determinar que a versão de patch está qualificada, o GKE define a nova versão de patch como um destino de atualização automática, o que significa que o GKE começa a atualizar automaticamente os clusters para esta nova versão de patch. Normalmente, o período entre a disponibilidade da versão e as atualizações automáticas é 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 quiser receber atualizações de patches assim que a versão estiver disponível e antes de o GKE definir a versão como um alvo de atualização automática no canal, pode usar atualizações automáticas de patches aceleradas. Esta definição pode ser útil se quiser receber patches de segurança o mais rapidamente possível através de atualizações automáticas.

Tem de compreender os riscos associados à atualização automática do cluster num cronograma acelerado antes de o GKE determinar que os clusters no canal devem ser atualizados automaticamente para a nova versão de patch. Esta programação acelerada ignora um passo no processo de qualificação para versões de patches em canais de lançamento. Todas as versões de patch, e não apenas as versões de patch com patches de segurança, são atualizadas com este cronograma acelerado. Esta definição não afeta as atualizações de versões secundárias e só está disponível para clusters inscritos num canal de lançamento.

Esta definição afeta apenas o momento em que o GKE atualiza automaticamente um cluster para uma nova versão de patch. O GKE continua a cumprir as janelas de manutenção e as exclusões, segue a ordem de uma sequência de implementação e aplica quaisquer outras práticas padrão que são normalmente usadas para atualizações automáticas.

Para mais informações sobre a definição desta funcionalidade, consulte o artigo Use atualizações automáticas de patches aceleradas.

Em alternativa, pode atualizar manualmente os seus clusters se quiser atualizar para uma versão de patch específica assim que a versão estiver disponível e antes de ser definida como um destino de atualização automática.

Execute versões de patch a partir de um canal mais recente

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

Por exemplo, se as seguintes versões estivessem disponíveis nos canais Rapid e Regular:

  • Rápida: 1.23.2-gke.700, 1.22.4-gke.1500
  • Normal: 1.21.4-gke.400, 1.22.1-gke.400

Um cluster inscrito no canal Regular que esteja a executar o GKE versão 1.22.1-gke.400 pode ser atualizado manualmente para a versão 1.22.4-gke.1500, mas não para a versão 1.23.2-gke.700, uma vez que se trata de uma versão secundária diferente.

Para atualizar manualmente para uma versão de patch num canal mais recente, o plano de controlo do cluster tem de executar um lançamento de patch com a mesma versão secundária. Por exemplo, se o cluster estiver a executar a versão 1.21.3-gke.200, primeiro tem de atualizar manualmente o cluster para uma versão de patch disponível no respetivo canal de lançamento atual, 1.22.1-gke.400. Em seguida, pode atualizar o cluster para a versão 1.22.4-gke.1500.

Também pode criar um novo cluster que execute a versão 1.22.4-gke.1500 e esteja inscrito no canal Regular.

O GKE mantém o cluster na versão de patch do canal mais recente até que um destino de atualização automática mais recente fique disponível no canal inscrito para o cluster.

Conheça as novidades de um canal

Para saber as novidades de um canal de lançamento, consulte as notas de lançamento. Existem notas de lançamento 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 feed Atom.
Canal normal HTML ou feed Atom.
Canal estável HTML ou feed Atom.

Escolha o melhor canal de lançamento para o seu cluster

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

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

Como mostra este diagrama, os canais de lançamento disponíveis usam versões a meio do ciclo de adoção, incluindo utilizadores pioneiros (canal rápido), maioria inicial (canal normal) e maioria (canal estável). A parte mais antiga do ciclo de adoção é a dos inovadores, que testam as funcionalidades mais recentes através da versão upstream do Kubernetes. A última parte do ciclo de adoção é a maioria tardia, em que está a usar uma versão que está a aproximar-se da descontinuação e tem de fazer a transição para uma versão suportada.

Nos seus ambientes de pré-produção, use o canal Rápido para versões mais recentes onde pode testar funcionalidades assim que estiverem geralmente disponíveis.

Para cargas de trabalho de produção que requerem maturidade em relação às funcionalidades mais recentes, recomendamos que use o canal normal (predefinição) ou o canal estável.

  • Se precisar de acompanhar de perto as novas funcionalidades, pondere usar o canal Regular, que oferece um equilíbrio entre a estabilidade e a atualidade da versão OSS do Kubernetes.
  • Se o seu requisito for maturidade, especialmente para clusters de produção, use o canal estável.

O GKE atualiza os clusters para uma versão mais recente que cumpre os padrões de qualidade do canal. No entanto, recomendamos que atualize os seus clusters com antecedência, uma vez que isto lhe oferece:

  • Melhor controlo das suas atualizações e alinhamento com o seu horário de trabalho.
  • Melhor previsibilidade, uma vez que o GKE ignora a atualização automática de clusters que cumprem o objetivo de lançamento (ou seja, clusters que foram atualizados manualmente para a versão de destino seguinte). Os nós são atualizados automaticamente para a versão recomendada no respetivo canal selecionado para se alinharem com a versão do painel de controlo e para se protegerem contra vulnerabilidades e desvio de versão não suportado.

Receba apoio técnico a longo prazo com o canal alargado

O GKE oferece apoio técnico a longo prazo para versões secundárias do Kubernetes através do canal Extended. Com este canal, pode manter-se numa versão secundária durante um período máximo de 24 meses. Após o período de apoio técnico padrão de 14 meses, o seu cluster recebe patches de segurança durante aproximadamente mais 10 meses durante o período de apoio técnico alargado.

Como o GKE atualiza automaticamente os clusters no canal alargado

Para clusters inscritos no canal alargado, o GKE atualiza automaticamente os clusters da seguinte forma:

  • Durante o período de apoio técnico padrão: o GKE atualiza os clusters para versões de patch mais recentes da mesma versão secundária, seguindo a mesma cadência que o canal Regular.
  • Durante o período de apoio técnico alargado: o GKE continua a fornecer atualizações de patches de segurança para a versão secundária. Cerca de 2 meses antes do fim do apoio técnico alargado, o GKE começa a atualizar os clusters para a versão secundária seguinte, a menos que o cluster esteja a usar funcionalidades ou APIs descontinuadas. Pode usar exclusões de manutenção para impedir atualizações de versões secundárias até ao final do apoio técnico alargado.
  • No final do suporte alargado: o GKE atualiza todos os clusters que ainda executam a versão secundária agora não suportada, independentemente dos problemas de bloqueio. Não pode configurar exclusões de manutenção após esta data.

Para saber mais sobre os diferentes períodos de disponibilidade e as atualizações que o GKE oferece durante o período de apoio técnico alargado, consulte o ciclo de vida da versão secundária do GKE.

Limitações para inscrever um cluster no canal alargado

Reveja as seguintes limitações para clusters inscritos no canal expandido:

Preços do apoio técnico alargado

Se quiser inscrever um cluster no canal alargado, certifique-se de que revê os preços do apoio técnico alargado. Os custos de pagamento por utilização aplicam-se quando o cluster está inscrito no canal alargado e a versão secundária do cluster entra no período de apoio técnico alargado.

Práticas recomendadas para o canal expandido

Reveja os seguintes cenários para compreender como pode usar o canal Extended para minimizar a interrupção causada por atualizações de versões secundárias.

Os cenários suportados requerem alguma ação manual ao longo do tempo para tirar o máximo partido do canal. Não recomendamos que inscreva um cluster no canal sem planos de mudar para a versão secundária seguinte, uma vez que o GKE vai eventualmente atualizar o cluster para versões secundárias mais recentes com a mesma frequência que outros canais, e o seu cluster vai potencialmente incorrer num custo maior e receber as novas funcionalidades por último.

Cenários suportados e não suportados

Para saber mais sobre cenários suportados e não suportados, reveja a tabela seguinte e consulte o artigo Use o canal alargado quando precisar de apoio técnico a longo prazo para ver mais detalhes. Uma marca de verificação () indica um cenário suportado:

Cenário de atualização Suportado Resumo Tempo entre alterações de versões secundárias É necessária uma ação manual
Manter temporariamente a versão secundária durante mais tempo Manter uma versão secundária para mitigar um problema que impede as atualizações. Mesma frequência média, com interrupção para tempo adicional numa versão secundária.
  • Mova temporariamente um cluster para o canal Extended e vice-versa.
  • Atualize manualmente o cluster para a nova versão secundária quando estiver pronto.
Atualize manualmente a versão secundária 1 a 2 vezes por ano Aceda a novas funcionalidades, mas com atualizações secundárias menos frequentes, quando for ideal para as cargas de trabalho no cluster. 1 a 2 vezes por ano.
  • Atualize manualmente o cluster para uma versão secundária mais recente.
Não fazer nada e receber atualizações menores com a mesma frequência Receba atualizações de versões secundárias com a mesma frequência que outros canais e novas funcionalidades o mais tarde possível. A cada 4 meses, em média.
  • Monitorização de atualizações automáticas de versões secundárias a partir de versões não suportadas.

Clusters não inscritos num canal de lançamento

Não recomendamos esta opção de configuração devido às limitações com os clusters não inscritos em canais de lançamento, mas pode optar por não inscrever um cluster padrão num canal de lançamento (conhecido como sem canal e anteriormente como estático). Não use esta opção, a menos que não seja possível atualizar automaticamente os conjuntos de nós individuais e tenha de atualizar esses nós manualmente. Se o seu cluster não estiver inscrito num canal de lançamento, pode desativar a atualização automática de nós para node pools selecionados. Com os canais de lançamento, pode alcançar o mesmo resultado ao nível do cluster em todos os conjuntos de nós. No entanto, independentemente da inscrição no canal de lançamento, os painéis de controlo de todos os clusters são atualizados automaticamente e, quando uma versão atinge o fim do apoio técnico, os painéis de controlo e os nós do cluster são atualizados automaticamente.

Recomendamos que, se quiser impedir atualizações automáticas para todo o cluster Standard ou todos os respetivos conjuntos de nós, use uma exclusão de manutenção com o cluster inscrito num canal de lançamento. Com as exclusões de manutenção, pode desativar as atualizações automáticas de nós para todos os conjuntos de nós, enquanto pode desativar as atualizações automáticas de nós ao nível do conjunto de nós se o cluster não estiver inscrito num canal de lançamento.

Comparação entre clusters inscritos e não inscritos num canal de lançamento

Reveja a tabela seguinte para compreender as semelhanças e as diferenças entre inscrever e não inscrever o seu cluster num canal de lançamento:

Funcionalidade Cluster inscrito num canal de lançamento O cluster não está inscrito num canal de lançamento
Comportamento da atualização partilhada
Tempo da atualização Alinhado com o canal de lançamento respetivo
  • Mesma data de início da atualização automática que o canal estável para versões secundárias
  • As mesmas versões secundárias disponíveis, versões de atualização automática de patches e versão predefinida que o canal Regular
  • As mesmas versões de patch disponíveis que o canal Rápido para as versões secundárias disponíveis no canal Regular
Atualizações automáticas de patches aceleradas Disponível Não disponível
Controlo da interrupção do node pool
Períodos de manutenção Disponível Disponível
Exclusões de manutenção Âmbitos de exclusão de manutenção disponíveis:
  • "Nenhuma atualização" (30 dias)
  • "Sem atualizações secundárias" (até ao fim do apoio técnico)
  • "Sem atualizações de nós ou secundárias" (até ao fim do apoio técnico)
 Restrito ao âmbito "Sem atualizações" (30 dias)
Sequência de implementação Disponível com sequências baseadas na frota e no âmbito Não disponível
Apoio técnico a longo prazo Disponível apenas com o canal de lançamento alargado Não disponível
Autopilot Disponível Não disponível

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

Os clusters criados com o canal de lançamento rápido não são clusters alfa. Seguem-se as diferenças:

  • Os clusters que usam canais de lançamento podem ser atualizados, e a atualização automática está ativada e não pode ser desativada. Não é possível atualizar clusters alfa.
  • Os clusters que usam canais de lançamento não expiram. Os clusters alfa expiram após 30 dias.
  • As APIs Kubernetes alfa não estão ativadas em clusters que usam canais de lançamento.

O que se segue?