Sobre upgrades de cluster com sequenciamento de lançamento

É possível gerenciar a ordem dos upgrades automáticos nos clusters do Google Kubernetes Engine (GKE) em vários ambientes usando o sequenciamento de lançamento. Por exemplo, é possível qualificar uma nova versão em clusters de pré-produção antes de fazer upgrade dos clusters de produção. O GKE também oferece uma versão do sequenciamento de lançamento que usa estágios personalizados (pré-lançamento) para oferecer um controle mais granular sobre os upgrades de cluster.

Este documento pressupõe que você conheça o seguinte:

Para configurar uma sequência de lançamento, consulte Sequência do lançamento de upgrades de cluster.

Visão geral

Com o sequenciamento de lançamento do GKE, é possível definir uma sequência específica e ordenada para upgrades de cluster em vários ambientes, como primeiro fazer upgrade dos clusters no ambiente de desenvolvimento, depois no ambiente de teste e, por fim, no ambiente de produção. Essa estratégia progressiva oferece um período de espera integrado, permitindo que você descubra e mitigue possíveis problemas antes que o upgrade chegue aos seus sistemas mais críticos.

O sequenciamento de lançamento é baseado no conceito de frotas, que são agrupamentos lógicos de clusters do GKE mapeados para um ambiente (por exemplo, teste). Para usar esse recurso, defina uma sequência de frotas e o tempo de imersão entre cada grupo. Quando o GKE seleciona uma nova versão, seus clusters são atualizados na ordem definida, permitindo que você valide as cargas de trabalho antes que a versão seja totalmente implantada no ambiente de produção.

As frotas oferecem suporte a associações leves, que permitem agrupar clusters de forma lógica para o sequenciamento de lançamento sem ativar todas as configurações e recursos no nível da frota. A assinatura simplificada é uma boa opção se você quiser usar o sequenciamento de lançamento sem algumas das outras implicações do gerenciamento completo da frota, como a semelhança de namespace no nível da frota. Para mais informações, consulte Assinaturas leves.

Escolher uma estratégia de sequenciamento de lançamento

O GKE oferece duas versões de sequenciamento de lançamento. As duas versões são criadas com base nos mesmos princípios de upgrades progressivos e baseados em frota, mas oferecem diferentes níveis de flexibilidade. Esta seção ajuda você a decidir qual versão é melhor para seu caso de uso.

  • Sequenciamento de lançamento com base na frota (GA):essa versão é a estratégia recomendada para a maioria dos casos de uso de produção. O sequenciamento de lançamento com base na frota oferece um método estável e compatível para lançar upgrades progressivamente em ambientes (como teste, preparação e produção) e usa uma sequência linear de frotas.

  • Sequenciamento de lançamento com etapas personalizadas (pré-lançamento):essa versão é uma evolução do modelo baseado em frota, oferecendo mais controle e flexibilidade granulares. Com os estágios personalizados, é possível definir estágios específicos em uma frota usando rótulos. Isso é uma boa opção para estratégias de lançamento mais complexas, como implantar uma nova versão em um pequeno subconjunto de clusters de produção antes de um lançamento mais amplo. Escolha essa opção se precisar de mais flexibilidade ou quiser conferir as funcionalidades mais recentes de sequenciamento de lançamento.

Sequência de lançamento baseado em frota

Para fazer upgrade automático dos clusters com o sequenciamento de lançamento, use frotas em que você agrupou seus clusters com o mesmo canal de lançamento e versão secundária em etapas de implantação. Defina a sequência de frotas e o tempo de imersão que você quer entre cada grupo de clusters. Em seguida, quando o GKE seleciona uma nova versão para upgrades automáticos no canal de lançamento, seus grupos de clusters são atualizados na sequência definida por você. é possível validar se as cargas de trabalho são executadas conforme o esperado com uma nova versão antes que os upgrades comecem com os clusters de produção.

O diagrama a seguir ilustra como o GKE atualiza automaticamente os clusters em uma sequência de lançamento organizada com frotas:

Sequência de lançamento baseada em frota, em que você agrupa clusters em frotas.
Figura : uma sequência de lançamento com base na frota

Com uma sequência baseada em frota, quando o GKE disponibiliza um novo destino de upgrade no canal de lançamento em que todos os clusters nessa sequência estão inscritos, o GKE faz upgrade dessas frotas de clusters nessa sequência, com os clusters da frota upstream qualificando a nova versão para clusters na frota downstream, para até cinco frotas. Upstream, na sequência de lançamento, refere-se ao grupo anterior e downstream, ao próximo.

Durante o tempo de imersão configurado entre as frotas, é possível confirmar se as cargas de trabalho estão sendo executadas conforme o esperado nos clusters atualizados.

Sequenciamento de lançamento com etapas personalizadas

Ao usar o sequenciamento de lançamento com estágios personalizados, você define a ordem dos upgrades da frota e define os tempos de absorção. Além disso, você também pode:

  • Defina uma sequência com etapas granulares que podem segmentar subconjuntos específicos de clusters em uma frota usando rótulos, o que a torna uma boa opção para estratégias como implantações graduais.
  • Tenha mais controle e observabilidade com os novos objetos de API RolloutSequence e Rollout.

Esse método oferece mais flexibilidade e controle granular sobre as atualizações do cluster. Para segmentar subconjuntos específicos de clusters em uma frota, use um label-selector para segmentar apenas os clusters com rótulos específicos do Kubernetes.

O diagrama a seguir ilustra como o GKE atualiza automaticamente os clusters em uma sequência de lançamento que usa estágios personalizados. A etapa tem como destino clusters com um label-selector chamado canary na frota prod:

Sequência de lançamento com etapas personalizadas no GKE.
Figura : uma sequência de lançamento com estágios personalizados

Quando um novo destino de upgrade fica disponível no canal de lançamento em que todos os clusters dessa sequência estão registrados, o GKE faz upgrade primeiro dos clusters na frota de teste e depois dos clusters na frota de pré-produção. Em seguida, na frota Production, o GKE prioriza clusters que correspondem ao label-selector. Como prod-cluster-1 está rotulado com canary: true, o GKE faz upgrade desse cluster em seguida. O GKE faz upgrade de todos os clusters restantes na frota de Production (na etapa principal) no final do processo, porque essa etapa não tem um seletor de rótulos.

Durante o tempo de imersão configurado entre as etapas, é possível confirmar se as cargas de trabalho estão sendo executadas conforme o esperado nos clusters atualizados. O exemplo anterior mostra uma etapa personalizada na frota de Production, mas é possível adicionar várias etapas a qualquer frota ou usar apenas uma frota com várias etapas.

Para mais informações sobre o sequenciamento de lançamento com etapas personalizadas, consulte Sobre o sequenciamento de lançamento com etapas personalizadas.

O restante deste documento se refere apenas ao sequenciamento de lançamento baseado em frota.

Como o GKE faz upgrade dos clusters em uma sequência de lançamento

Quando o GKE faz upgrade de um cluster, primeiro o plano de controle é atualizado. Em seguida, os nós são atualizados. Em uma sequência de lançamento, os clusters ainda recebem upgrade usando esse processo, mas você também controla a ordem em que os grupos (frotas) de clusters são atualizados. Você também especifica um tempo de imersão que define por quanto tempo o GKE faz uma pausa antes que os upgrades continuem de um grupo para o próximo.

Os upgrades de cluster em uma sequência de lançamento seguem estas etapas:

  1. O GKE define uma nova meta de upgrade automático para clusters em uma versão secundária em um canal de lançamento específico, com uma nota de lançamento semelhante à seguinte mensagem: "Os planos de controle e nós com upgrade automático ativado no Canal normal serão atualizados da versão 1.29 para a versão 1.30.14-gke.1150000 com esta versão".

  2. O GKE começa a fazer upgrade dos planos de controle do cluster para a nova versão no primeiro grupo de clusters. Depois que o GKE faz upgrade do plano de controle de um cluster, o GKE começa a fazer upgrade dos nós do cluster. O GKE respeita a disponibilidade de manutenção ao fazer upgrade dos clusters em uma sequência de lançamento.

  3. O GKE realiza as seguintes etapas para upgrades do plano de controle:

    1. Depois que todos os upgrades do plano de controle do cluster no primeiro grupo forem concluídos, o GKE vai iniciar o período de imersão para upgrades do plano de controle. O GKE também inicia o período de imersão se mais de 30 dias se passaram desde o início dos upgrades do plano de controle.

    2. Após a conclusão do período de imersão para os upgrades do plano de controle do cluster do primeiro grupo, o GKE começa a fazer upgrade dos planos de controle do segundo grupo para a nova versão. No entanto, observe as seguintes considerações:

      • Em alguns casos, o GKE pode fazer upgrade dos planos de controle do cluster do primeiro grupo várias vezes antes de fazer upgrade dos planos de controle do cluster do segundo grupo. Quando isso acontece, o GKE escolhe a versão mais recente que também tem os seguintes atributos:
        • A versão é qualificada pelo primeiro grupo.
        • A versão é no máximo uma versão secundária posterior à versão do plano de controle dos clusters do segundo grupo.
      • O GKE não faz upgrade do plano de controle de clusters no segundo grupo que têm uma versão mais recente do que o destino de upgrade automático qualificado pelo primeiro grupo.

  4. Em paralelo aos upgrades do plano de controle, o GKE realiza as seguintes etapas para upgrades de nós:

    1. Depois que todos os upgrades de nós dos clusters no primeiro grupo forem concluídos, o GKE vai iniciar o período de imersão para upgrades de nós. O GKE também inicia o período de imersão se mais de 30 dias se passaram desde o início dos upgrades de nós.
    2. Após a conclusão do período de imersão para os upgrades de nós do primeiro grupo, o GKE começa a fazer upgrade dos nós do segundo grupo para a nova versão. No entanto, observe as seguintes considerações:
      • Em alguns casos, o GKE pode fazer upgrade dos nós do cluster do primeiro grupo várias vezes antes de fazer upgrade dos nós do cluster do segundo grupo. Quando isso acontece, o GKE escolhe a versão mais recente que também tem os seguintes atributos:
        • A versão é qualificada pelo primeiro grupo.
        • A versão não é posterior à versão do plano de controle do cluster do segundo grupo.
      • O GKE não faz upgrade dos nós de clusters no segundo grupo que têm uma versão mais recente do que o destino de upgrade automático qualificado pelo primeiro grupo.

  5. O GKE repete essas etapas do segundo grupo para o terceiro, até que os clusters em todos os grupos na sequência de lançamento tenham sido atualizados para o novo destino de upgrade.

Enquanto os clusters são atualizados em cada grupo, durante o tempo de imersão, verifique se as cargas de trabalho com clusters executando a nova versão do GKE funcionam conforme o esperado .

Os clusters também podem ser impedidos de fazer upgrade devido a exclusões ou janelas de manutenção, uso de API descontinuado ou outros motivos.

Como controlar upgrades em uma sequência de lançamento

Com os upgrades de cluster em uma sequência de lançamento, os grupos de clusters são atualizados na ordem definida e mergulhados em cada grupo pelo tempo que você escolheu. Enquanto os upgrades estão em andamento, é possível verificar o status e gerenciar a sequência de lançamento conforme necessário. Também é possível controlar o processo das seguintes maneiras:

  • Para upgrades de cluster individuais, continue usando as seguintes ferramentas:
    • Controlar manualmente upgrades tomando medidas como cancelar, retomar, reverter ou concluir upgrades de pool de nós.
    • Use janelas e exclusões de manutenção para decidir quando um cluster pode ou não ser atualizado.
    • Configure as estratégias de upgrade de nós para equilibrar velocidade e tolerância ao risco, dependendo das cargas de trabalho em execução nesses nós.

Exemplo: o banco comunitário lança gradualmente as alterações de teste para produção

Por exemplo, o administrador da plataforma em um banco da comunidade gerencia três ambientes principais de implantação: teste, preparo e Production. Cada ambiente tem um grupo de clusters organizado em uma frota. Conforme necessário para o sequenciamento de implementação, o administrador inscreveu cada cluster em todas as três frotas no mesmo canal de lançamento. Nessas frotas, o canal normal, com todos clusters executando a mesma versão secundária

O administrador usa o sequenciamento de lançamento para definir a ordem em que o GKE faz upgrade dos clusters nesses ambientes. Pedir o lançamento dá ao administrador a oportunidade de verificar se as cargas de trabalho são executadas conforme o esperado com clusters em uma nova versão do GKE antes que o ambiente de produção seja atualizado para a nova versão. Essa sequência é ilustrada pelo diagrama de sequência de lançamento baseado em frota.

O administrador usa o tempo de imersão entre as frotas para verificar se as cargas de trabalho são executadas conforme o esperado na nova versão do GKE. Para a frota de testes, o administrador define o tempo de imersão como 14 dias para que tenha duas semanas completas para testar como as cargas de trabalho são executadas. Para o preparo, eles definem o tempo de imersão como sete dias, já que não precisam de tanto tempo adicional depois da execução das cargas de trabalho nos testes.

O administrador também pode modificar o tempo de imersão padrão para upgrades para versões específicas, o que pode ser feito em uma das seguintes situações:

  • O administrador termina de qualificar a versão antes que o tempo de imersão seja concluído e quer que os upgrades prossigam para a próxima frota. Portanto, ele define o tempo de imersão como zero.
  • O administrador precisa de mais tempo para qualificar a nova versão antes que os upgrades continuem para a próxima frota, já que eles perceberam um problema com algumas das cargas de trabalho e, portanto, definiram o tempo máximo para o máximo de 30 dias.

O administrador usa janelas de manutenção e exclusões para permitir que o GKE atualize os clusters quando for menos disruptivo para o banco. O GKE respeita a disponibilidade de manutenção para clusters atualizados em uma sequência de lançamento.

  • O administrador configurou as janelas de manutenção dos clusters para que o GKE atualize os clusters somente após o horário de funcionamento.
  • O administrador também usa exclusões de manutenção para impedir temporariamente que os clusters sejam atualizados se detectarem problemas nas cargas de trabalho do cluster.

O administrador usa uma combinação de upgrades súbitos e azuis-verdes para seus nós, equilibrando entre velocidade e tolerância de risco, dependendo nas cargas de trabalho em execução nesses nós.

Qualificação para o lançamento com base na frota

Para que os clusters sejam atualizados automaticamente com o sequenciamento de lançamento, todos os clusters em todas as frotas em uma sequência de lançamento precisam receber a mesma meta de upgrade. Os clusters precisam estar inscritos no mesmo canal de lançamento. Recomendamos que os clusters executem a mesma versão secundária que os destinos de upgrade são definidos por versão secundária. No entanto, para algumas versões, como a versão no exemplo a seguir, os clusters de várias versões secundárias receberam o mesmo destino, o que significa que os clusters puderam ser atualizados com sucesso na sequência de várias versões secundárias.

É possível verificar o status do lançamento de versões em sequência para ver mais informações sobre o status e se problemas de qualificação de versão estão impedindo que os upgrades continuem. Dependendo das discrepâncias da versão, talvez seja necessário realizar ações, como fazer upgrade manual de um cluster ou removê-lo de um grupo para que os upgrades de clusters continuem. Se um cluster em uma sequência de lançamento não tiver um destino de upgrade qualificado, o GKE não fará o upgrade automático do cluster até que a versão secundária atual do cluster chegue ao fim do suporte.

Para resolver problemas de qualificação para o lançamento, consulte Resolver problemas de qualificação para lançamento.

Exemplo de versão do GKE

Por exemplo, a versão de 2025-R45 definiu um destino de upgrade para várias versões secundárias em clusters inscritos no canal normal. Um destino de upgrade pode ser uma nova versão secundária (1.30 para 1.31) ou apenas uma nova versão de patch (1.31.x-gke.x para 1.31.13-gke.1023000). Nesta versão, no Canal normal, as seguintes versões novas foram disponibilizadas para clusters em versões secundárias específicas:

  • Os clusters na versão 1.30 foram atualizados para 1.31.13-gke.1023000.
  • Os clusters na versão 1.31 foram atualizados para 1.32.9-gke.1108000.
  • Os clusters na versão 1.32 foram atualizados para 1.33.5-gke.1162000.

O grupo mais ascendente recebe todos os destinos de upgrade

Para clusters no primeiro grupo em uma sequência, que não tem um grupo upstream para qualificar novas versões, o GKE faz upgrade de todos os clusters com destinos de upgrade qualificados, independentemente de esses destinos serem diferentes de cada um. outro. Por exemplo, no primeiro grupo de uma sequência, se alguns clusters estiverem executando a versão 1.30, eles poderão ser atualizados para 1.31.13-gke.1023000, e os clusters que executam a versão 1.32 poderão ser atualizados para 1.33.5-gke.1162000. Isso ocorre porque, para o primeiro grupo em uma sequência, o GKE considera todos os destinos de upgrade qualificados para esses clusters, já que não há um grupo upstream para qualificar uma nova versão.

Um grupo upstream precisa qualificar apenas uma versão

Para que os clusters em qualquer grupo downstream comecem a ser atualizados, o grupo upstream precisa ter qualificado um único destino de upgrade comum para o qual todos os clusters no grupo downstream estão qualificados. Se o grupo upstream tiver clusters que foram atualizados para duas versões diferentes (como pode acontecer quando o grupo upstream é o primeiro em uma sequência), ele vai qualificar a versão mais baixa como o destino de upgrade comum para o grupo downstream. Por exemplo, se o grupo upstream tiver alguns clusters atualizados para 1.31.13-gke.1023000 e outros atualizados para 1.33.5-gke.1162000, o grupo qualificará 1.31.13-gke.1023000 como o destino de upgrade comum para o grupo downstream.

Clusters que executam versões mais recentes que o destino do upgrade não impedem upgrades

Se um grupo downstream tiver clusters que executam uma versão mais recente do que o destino de upgrade qualificado por um grupo upstream, o GKE fará upgrade dos clusters qualificados para o destino de upgrade e vai ignorar os clusters que já estão em uma versão mais recente. Esse comportamento não impede o progresso da sequência de lançamento, desde que pelo menos um cluster no grupo downstream esteja qualificado para o destino de upgrade.

Por exemplo, se o grupo upstream qualificou o upgrade para 1.32 e o grupo downstream tem clusters executando 1.31 e 1.33, o GKE faz upgrade dos clusters que executam 1.31 para 1.32 e ignora os clusters que executam 1.33.

Um grupo upstream precisa qualificar uma versão correspondente aos clusters do próximo grupo

Se os clusters em um grupo upstream tiverem qualificado uma versão diferente daquela para a qual os clusters no grupo seguinte estão qualificados, o GKE também não poderá fazer upgrade automaticamente dos clusters em nenhum grupo downstream.

Por exemplo, se todos os clusters no primeiro grupo forem atualizados para 1.31.13-gke.1023000, mas os clusters no segundo grupo estiverem executando uma versão mais recente, como 1.32.9-gke.1108000, os clusters do segundo grupo não serão atualizados automaticamente. O primeiro grupo se qualificou para 1.31.13-gke.1023000, mas os clusters no segundo grupo (atualmente em 1.32) só estão qualificados para o upgrade 1.33.5-gke.1162000, portanto, o GKE não pode automaticamente fazer upgrade desses clusters. Para avançar upgrades nessa situação, consulte Corrigir qualificação entre grupos.

O grupo upstream qualificou vários destinos de upgrade para o grupo downstream

Se o GKE fizer upgrade dos clusters no grupo upstream várias vezes antes de fazer upgrade dos clusters no grupo downstream, o GKE fará upgrade dos clusters no grupo downstream para a versão mais recente qualificada pelo grupo upstream, para a qual os clusters no grupo downstream estão qualificados. Para upgrades do plano de controle, essa versão pode ser no máximo uma versão secundária mais recente que a versão do plano de controle dos clusters no grupo downstream. Para upgrades de nós, essa versão pode ser igual, mas não posterior à versão do plano de controle dos clusters no grupo downstream.

Por exemplo, esse cenário é relevante se você configurou exclusões de manutenção para impedir temporariamente upgrades no seu grupo downstream, que inclui seus clusters de produção. No entanto, seu grupo upstream, que inclui clusters em pré-produção, não usou exclusões de manutenção para evitar upgrades. Assim, seu grupo upstream foi atualizado várias vezes, qualificando vários destinos de upgrade em potencial, enquanto o grupo downstream não foi atualizado.

Os upgrades não concluídos em 30 dias serão forçados a entrar em imersão para desbloquear a sequência.

Para garantir que uma sequência de lançamento termine de fazer upgrade dos clusters, o GKE inicia o período de imersão de um grupo se os upgrades do plano de controle ou do nó, respectivamente, não forem concluídos em todos os clusters dentro do tempo máximo de upgrade (30 dias). Os upgrades dos clusters restantes no grupo ainda podem continuar durante o período de absorção. Para mais informações, consulte a linha de FORCED_SOAKING na Tabela de informações de status para uma sequência de lançamento.

Como o sequenciamento de lançamentos com base em frota funciona com outros recursos de upgrade

O sequenciamento de lançamento é um recurso em uma coleção de recursos que fornece controle sobre o aspecto de upgrade do ciclo de vida do cluster. Nesta seção, explicamos como esse recurso funciona com alguns dos outros recursos disponíveis relacionados a upgrades de cluster.

Como o sequenciamento de lançamentos baseado em frota funciona com janelas e exclusões de manutenção

O GKE respeita janelas de manutenção e exclusões de manutenção ao fazer upgrade dos clusters com o sequenciamento de lançamento. O GKE só inicia um upgrade de cluster dentro da janela de manutenção de um cluster. É possível usar uma exclusão de manutenção para impedir temporariamente o upgrade de um cluster. Se o GKE não puder fazer upgrade de um cluster devido a uma janela de manutenção ou exclusão, isso poderá impedir que os upgrades do cluster sejam concluídos em um grupo. Se um upgrade de cluster não puder ser concluído em 30 dias devido a janelas de manutenção ou exclusões, o grupo vai entrar na fase de imersão, mesmo que todos os clusters tenham concluído o upgrade.

É possível usar exclusões de manutenção como uma medida temporária para evitar que uma sequência conclua um lançamento em um grupo e passe para o próximo grupo. Para mais informações, consulte Atrasar a conclusão do lançamento da versão do grupo.

Como o sequenciamento de lançamentos baseado em frota funciona com a detecção de uso descontinuado

O GKE pausa os upgrades do cluster quando detecta o uso de determinados recursos e APIs descontinuados. Os upgrades automáticos também são pausados para clusters em um grupo em uma sequência de lançamento. Para mais informações, consulte Como as descontinuações do Kubernetes funcionam com o GKE.

Como o sequenciamento de lançamentos funciona com estratégias de upgrade de nós

Os upgrades de nós usarão a estratégia de upgrade de nó configurada quando forem atualizados em uma sequência de lançamento. Assim como nos upgrades de cluster sem o sequenciamento de lançamentos, o GKE usa os upgrades súbitos para os nós do Autopilot. Para mais informações, consulte Upgrades automáticos de nós.

Se os upgrades de nó não forem concluídos em 30 dias, o grupo entrará na fase de imersão, independentemente de todos os clusters terem concluído o upgrade. Isso pode acontecer se a estratégia de upgrade de nós fizer com que o upgrade de nós de um cluster padrão demore mais para ser concluído, especialmente se for um pool de nós grande. Ela também pode ser exacerbada por janelas de manutenção que não são grandes o suficiente para a conclusão de um upgrade de nós.

Como o sequenciamento de lançamentos funciona com canais de lançamento

Os canais de lançamento são obrigatórios para usar o sequenciamento de lançamento. Todos os clusters em todos os grupos em uma sequência de lançamento precisam estar no mesmo canal de lançamento.

Como receber vários upgrades em uma sequência

Se uma nova versão se tornar um destino de upgrade no canal de lançamento enquanto os upgrades do cluster para um destino anterior ainda estiverem ocorrendo na sequência de lançamento, um grupo upstream poderá iniciar o lançamento de uma nova versão enquanto um grupo downstream ainda está recebendo o upgrade anterior. Por exemplo, se o terceiro grupo em uma sequência estiver lançando 1.31.12-gke.1265000, o primeiro grupo na sequência poderá ser lançado simultaneamente.

Considerações ao escolher o sequenciamento de lançamento baseado em frota

Use o sequenciamento de lançamento se quiser gerenciar upgrades de cluster ao qualificar novas versões em um ambiente antes de lançá-lo para outro.

No entanto, essa estratégia pode não ser a escolha certa para seu ambiente se alguma das afirmações a seguir for verdadeira:

  • Você tem clusters que não estão no mesmo canal de lançamento ou versão secundária no mesmo ambiente de produção.
  • Você precisa automatizar os upgrades que não podem ser mapeados para apenas cinco estágios de implantação, já que só é possível criar uma sequência de lançamento com até cinco grupos de clusters. Não é possível vincular grupos em várias sequências de lançamento para criar uma sequência com mais de cinco grupos. As sequências baseadas em frota podem incluir até cinco frotas.
  • Você faz upgrades manuais com frequência, o que faz com que os clusters de um grupo tenham versões de destino de upgrade automático diferentes.

Limitações do sequenciamento de lançamento com base na frota

Para fazer upgrade dos clusters com o sequenciamento de lançamento, você precisa aderir a estas limitações:

  • Verifique se todos os clusters em uma sequência de lançamento estão inscritos no mesmo canal de lançamento. Também recomendamos que todos os clusters executem a mesma versão secundária para qualificar um destino de upgrade. Para mais informações, consulte Qualificação para o lançamento.
  • Crie uma sequência de lançamento linear sem ciclos (um grupo tem um grupo downstream como seu grupo upstream) ou ramificações (um grupo tem mais de um grupo downstream).
  • Crie uma sequência de lançamento entre clusters na mesma organização. Não é possível criar sequências com clusters em várias organizações.

Problemas conhecidos com o sequenciamento de lançamento baseado em frota

  • Se um grupo contiver clusters de diferentes locais, um upgrade de cluster poderá ficar temporariamente disponível apenas para alguns dos clusters devido ao lançamento gradual da nova versão. É mais provável que isso aconteça com o primeiro grupo de clusters e deve ser resolvido em uma semana.
  • Se houver um grupo vazio em uma sequência de lançamento, a forma como isso afetará a qualificação da versão depende das seguintes condições:
    • Se o grupo vazio não tiver um grupo upstream, os upgrades de cluster não prosseguirão para o grupo downstream, já que o grupo vazio não pode qualificar versões.
    • Se o grupo vazio tiver um grupo upstream, todos os upgrades de cluster pendentes entrarão no status COMPLETE e serão propagados para o grupo downstream.

A seguir