Sobre o sequenciamento de lançamento com etapas personalizadas

Autopilot Standard

Rollout sequencing with custom stages

• Sequenciamento de lançamento com etapas personalizadas (prévia)
• Sequenciamento de lançamento (GA)

Pré-lançamento

Este recurso está sujeito aos "Termos da Oferta Pré-GA" na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis no estado em que se encontram e podem ter assistência limitada. Para mais informações, consulte as descrições das fases 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 com disponibilidade geral do sequenciamento de lançamentos que usa um modelo mais linear sem etapas personalizadas.

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

• Upgrades de cluster
• Visão geral do gerenciamento de frotas
• Canais de lançamento
• Esquema de controle de versão no GKE
• Teste de resistência

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 e disponível 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):esta versão é uma evolução do modelo baseado em frota, oferecendo mais controle e flexibilidade. Com as etapas personalizadas, é possível definir etapas específicas 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 testar os recursos mais recentes de sequenciamento de lançamento.

O restante deste documento se refere apenas ao sequenciamento de lançamento com estágios personalizados.

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:

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.

Principais conceitos

• Tempo de imersão: esse período é um período de espera configurável que ocorre depois que todos os clusters em um estágio são atualizados. Esse período permite validar a nova versão em um ambiente e identificar possíveis problemas antes que o upgrade prossiga para o próximo ambiente. É possível configurar um tempo de imersão de até 30 dias para cada etapa da sua sequência. Um tempo maior de imersão em uma etapa em pré-produção dá mais tempo para validação.
• RolloutSequence: é o recurso principal usado para definir sua sequência de upgrade. RolloutSequence contém uma série ordenada de estágios, que verifica se os clusters em estágios anteriores foram totalmente atualizados e concluíram o período de imersão antes que o upgrade prossiga para a próxima etapa.
• Rollout: esse objeto permite observar o progresso de um único upgrade de versão na sua sequência. Use Rollout para conferir o status do lançamento, acompanhar o progresso e saber se e por que alguns clusters não estão qualificados para upgrade.
• Projeto host dedicado: recomendamos que você use um projeto Google Cloud dedicado para hospedar seus objetos RolloutSequence. Colocar a sequência em um projeto dedicado fornece um ponto de controle neutro e central para as sequências de lançamento, o que é uma prática recomendada semelhante para gerenciar pipelines de CI/CD.

Prática recomendada:

Crie e gerencie seus recursos RolloutSequence em um projeto host dedicado.

• Estágios: um estágio é uma etapa na sequência de lançamento. Cada estágio contém um grupo de clusters que são atualizados juntos.
• Frotas: são a principal maneira de agrupar clusters. Uma etapa em uma sequência de lançamento só pode referenciar uma frota.
• Seletores de rótulo: uma sequência de lançamento é composta por uma ou mais etapas. Cada estágio contém clusters de uma frota, e você pode usar seletores de rótulos em clusters para dividir ainda mais uma frota em vários estágios. Essa abordagem permite estratégias como lançamentos graduais, em que um pequeno subconjunto de clusters de produção é atualizado primeiro.

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 .

Aviso :o GKE talvez não consiga realizar upgrades automáticos em uma sequência de lançamento se houver discrepâncias de versão entre clusters nos grupos na sequência. Para mais informações, consulte Qualificação para o lançamento.

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:

• É possível modificar o tempo de imersão padrão de um grupo em uma sequência de lançamento, o que é útil se o teste revelar que uma versão específica precisa de mais ou menos imersão. Essa mudança no tempo de imersão atualiza o tempo padrão para todos os lançamentos atuais e futuros (para qualquer versão) criados após a modificação.

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

Atenção: se você modificar uma sequência durante um lançamento, principalmente mudanças que afetam os clusters participantes, o GKE cancela imediatamente todos os lançamentos em andamento. Se você modificar apenas o tempo de imersão de uma sequência, o GKE não vai cancelar o lançamento.

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

Um administrador de plataforma em um banco comunitário gerencia três ambientes principais de implantação: teste, preparo e Production. Os clusters de produção são distribuídos em várias regiões, com diferentes níveis de criticidade. Para gerenciar upgrades de maneira eficaz, o administrador agrupa os clusters em cada ambiente em frotas. Como é necessário para o sequenciamento de implementação, cada cluster em todas as três frotas está inscrito no mesmo canal de lançamento (neste caso, o Canal normal) e todos os clusters executam a mesma versão secundária.

O objetivo principal do administrador é garantir que as novas versões do GKE sejam testadas antes de chegar ao ambiente de produção crítico do banco. Eles também querem fazer upgrade progressivo dos clusters primeiro em uma região de tráfego menor, depois em uma região de tráfego maior e, por fim, na região mais crítica. Para isso, eles usam o sequenciamento de lançamento com etapas personalizadas para definir uma estratégia de upgrade progressivo que inclui a rotulagem dos clusters de produção de acordo com a região. Essa abordagem permite validar uma nova versão em um pequeno subconjunto de tráfego de produção antes de um lançamento completo.

Para implementar esse plano, o administrador aplica os seguintes rótulos aos clusters na frota de Production:

• Os clusters em us-west1 (tráfego menor) são rotulados com prod-region: us-west1.
• Os clusters em europe-west1 (tráfego mais alto) são rotulados com prod-region: europe-west1.
• Os clusters em us-east1 (tráfego mais crítico) não são rotulados. A etapa final de uma frota em uma sequência precisa funcionar como um "catch-all" para todos os clusters restantes. Portanto, o administrador não precisa adicionar rótulos a esses clusters restantes.

Em seguida, em um projeto host dedicado usado para gerenciar configurações de CI/CD, eles definem um objeto RolloutSequence. Essa nova sequência tem cinco etapas distintas:

1. Teste: esta etapa inclui todos os clusters na frota testing. O administrador define um tempo de imersão de três dias para permitir uma validação completa.
2. Staging: esta etapa inclui todos os clusters na frota staging, com um tempo de imersão de três dias.
3. Produção na região us-west1: esta etapa tem como destino a frota de produção, mas usa um label-selector para incluir apenas os clusters com o rótulo prod-region: us-west1. Nessa etapa, o administrador monitora problemas em um pequeno subconjunto de clusters de produção com um período de teste de três dias.
4. Produção na região europe-west1: esta etapa inclui os clusters na frota production que têm o rótulo prod-region: europe-west1. O administrador define um tempo de imersão mais longo de quatro dias para uma validação mais completa.
5. Produção na região us-east1: esta etapa final inclui os clusters restantes na frota production, ou seja, todos os clusters em us-east1.

Essa abordagem oferece ao administrador controle granular sobre os upgrades de produção, melhorando significativamente a segurança e a confiabilidade do processo de upgrade ao detectar possíveis problemas antes que eles afetem todo o ambiente de produção.

Durante uma atualização de patch de rotina, os testes automatizados do banco são concluídos com êxito no ambiente de teste muito mais rápido do que o previsto. O administrador observa que a nova versão está estável e decide que o tempo de imersão de três dias após o upgrade da frota de teste é desnecessariamente longo para esse tipo de atualização de rotina.

Para acelerar esse lançamento, o administrador modifica a definição de RolloutSequence e reduz a duração do período de teste para a fase us-west1 da frota de Production. Como essa mudança na definição de RolloutSequence atualiza o tempo de imersão padrão para todos os lançamentos atuais e futuros, o administrador anota para reverter o tempo de imersão para o período original de três dias após a conclusão desse lançamento de patch específico. Essa abordagem ajuda a garantir que o tempo de imersão padrão e mais cauteloso esteja em vigor para futuros upgrades de versão secundária.

O administrador usa janelas e exclusões de manutenção para 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 janelas de manutenção para os clusters para que o GKE faça upgrade dos 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 azul-verde para os nós, equilibrando velocidade e tolerância ao risco, dependendo das cargas de trabalho em execução nesses nós.

Qualificação para o lançamento

Para que uma versão seja lançada em uma sequência usando estágios personalizados, os clusters precisam estar qualificados para um destino de upgrade do canal de lançamento. Quando uma nova versão do GKE fica disponível, o sistema cria um objeto Rollout se os clusters na sequência forem qualificados para a nova versão. Embora recomendemos que todos os clusters sejam registrados no mesmo canal de lançamento, se não forem, o GKE selecionará uma versão do canal mais conservador na sequência. Por exemplo, se os clusters forem misturados entre os canais Stable e Regular, o GKE vai escolher a versão do Canal estável.

O Rollout passa pelos estágios definidos no seu RolloutSequence. Em uma determinada etapa, o lançamento do plano de controle e o lançamento do pool de nós podem ser executados em paralelo. Uma regra fundamental que rege essa progressão é que, enquanto um estágio está em um estado SOAKING com uma versão específica, ele não está qualificado para iniciar um novo Rollout para uma versão mais recente. Essa prática ajuda a garantir que uma versão seja totalmente validada antes do início do próximo upgrade. É possível acompanhar o progresso e a qualificação de cada cluster monitorando o objeto Rollout. Se você encontrar discrepâncias de versão que tornem um cluster inelegível, talvez seja necessário realizar uma ação, como fazer upgrade manual do cluster, para permitir que a sequência continue. Se um cluster não estiver qualificado para nenhum lançamento, o GKE não fará upgrade automático até que a versão atual chegue ao fim do suporte.

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

Se uma etapa na sequência tiver clusters que executam uma versão mais recente do que a versão de destino de um lançamento, o GKE fará upgrade dos clusters qualificados para a versão de destino e vai ignorar os clusters que já estão em uma versão mais recente. Esse comportamento não impede que a sequência de lançamento avance para a próxima etapa.

Por exemplo, se a versão de destino de um lançamento para uma etapa for 1.32 e essa etapa tiver clusters que executam 1.31 e 1.33, o GKE fará upgrade dos clusters na versão 1.31 para 1.32 e vai ignorar os clusters que já estão na versão 1.33.

A etapa anterior qualificou vários destinos de upgrade para a etapa seguinte.

Um estágio anterior em uma sequência pode concluir lançamentos para várias versões novas enquanto um estágio posterior está pausado (por exemplo, por uma exclusão de manutenção) ou ainda está processando um upgrade anterior. Nesse caso, quando a próxima etapa estiver pronta para aceitar um novo upgrade, o GKE vai atualizar a etapa para a versão mais recente qualificada. 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 na próxima etapa. Para upgrades de nós, essa versão pode ser igual, mas não posterior, à versão do plano de controle dos clusters na próxima etapa.

Por exemplo, esse cenário é relevante se você configurou exclusões de manutenção para impedir temporariamente upgrades nos clusters de produção. Se os clusters em pré-produção não tiverem as mesmas exclusões de manutenção, eles poderão ser atualizados várias vezes, qualificando várias versões novas, mas os estágios de produção não serão atualizados.

Imersão forçada após 30 dias

Para ajudar a garantir que uma sequência de lançamento termine de fazer upgrade dos clusters, o GKE inicia o período de imersão para 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 adaptação.

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

O sequenciamento de lançamento funciona com outros recursos de upgrade do GKE:

• Janelas e exclusões de manutenção: ainda é possível usar janelas e exclusões de manutenção para controlar quando os upgrades podem ou não ocorrer nos clusters. O GKE inicia um upgrade de cluster somente 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 uma etapa. Se um upgrade de cluster não puder ser concluído em 30 dias devido a janelas de manutenção ou exclusões, o estágio vai entrar na fase de imersão, mesmo que todos os clusters tenham concluído o upgrade. Os rollouts do plano de controle e do pool de nós podem ser executados em paralelo em uma determinada etapa.

• Estratégias de upgrade de nós: o sequenciamento de lançamentos não afeta as estratégias de upgrade de nós configuradas (por exemplo, upgrades azul-verde). Assim como nos upgrades de cluster sem sequenciamento de lançamentos, o GKE usa 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. A situação 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.

• Canais de lançamento: recomendamos que você registre todos os clusters em uma sequência de lançamento no mesmo canal de lançamento.

• Detecção de uso de suspensão de uso: a detecção de uso de suspensão de uso do GKE ainda funciona como esperado, podendo pausar upgrades em clusters que usam uma API descontinuada.

• Upgrades manuais: fazer upgrade manual dos clusters na primeira etapa de uma sequência não qualifica essa versão nem aciona um lançamento para prosseguir. O processo de lançamento automático é impulsionado pelos destinos oficiais de upgrade automático definidos para o canal de lançamento. Um upgrade manual atualiza os clusters, mas a sequência começa a avançar para essa versão somente depois que ela se torna o destino designado do upgrade automático.

Como receber vários upgrades em uma sequência

Um canal de lançamento seleciona uma meta de upgrade para o cluster. Se uma nova versão ficar disponível enquanto os upgrades para um destino anterior ainda estiverem em andamento, a primeira etapa poderá iniciar o lançamento de uma nova versão mesmo quando as etapas posteriores ainda receberem o upgrade anterior. Por exemplo, se o terceiro grupo em uma sequência estiver lançando a versão 1.31.12-gke.1265000, o primeiro grupo na sequência poderá lançar simultaneamente a versão 1.31.13-gke.1008000.

Considerações ao escolher o sequenciamento do lançamento

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

As seguintes limitações se aplicam ao fazer upgrade dos clusters usando o sequenciamento de lançamento com estágios personalizados:

• Não é possível usar o console do Google Cloud para criar ou visualizar sequências de lançamento com etapas personalizadas.
• Quando uma sequência de lançamento faz referência a uma frota, é necessário incluir a frota inteira. Essa restrição significa que, se você definir uma etapa para segmentar apenas um subconjunto de clusters de uma frota com um label-selector (por exemplo, para uma implantação gradual), também será necessário definir uma etapa "catch-all" subsequente que inclua todos os clusters restantes da mesma frota. Essa etapa de abrangência geral tem como destino a mesma frota, mas não inclui um label-selector, o que inclui automaticamente todos os clusters que não foram selecionados por etapas anteriores na sequência.
• Se você modificar uma sequência durante um lançamento, principalmente mudanças que afetam os clusters participantes, o GKE cancela imediatamente todos os lançamentos em andamento. Se você modificar apenas o tempo de imersão de uma sequência, o GKE não vai cancelar o lançamento.
• Não é possível acelerar manualmente um lançamento ativo para uma versão específica. Quando você modifica a duração do tempo de imersão na definição da sequência de lançamento, a mudança atualiza o tempo de imersão padrão para todos os lançamentos atuais e futuros criados após a modificação.
• O GKE faz upgrade automático dos clusters que atingiram o fim do suporte para uma versão compatível, e esse upgrade pode não seguir a sequência de lançamento definida.
• Uma etapa pode referenciar no máximo uma frota. Não é possível ter várias frotas em uma única etapa.
• Uma única frota só pode ser referenciada em uma sequência de lançamento. Duas sequências de lançamento não podem fazer referência à mesma frota.

Problemas conhecidos

Esta seção descreve os problemas conhecidos da sequência de lançamento com etapas personalizadas.

• Se uma etapa na sua sequência de lançamento não tiver clusters, ela será ignorada, mas o tempo de imersão definido para essa etapa ainda vai passar antes que o lançamento prossiga para a próxima etapa.

A seguir

• Sequenciar o lançamento de upgrades de cluster com etapas personalizadas