Acerca da sequenciação da implementação com fases personalizadas

Autopilot Padrão

Rollout sequencing with custom stages

• Sequenciação da implementação com fases personalizadas (pré-visualização)
• Sequenciação da implementação (GA)

Pré-visualização

Esta funcionalidade está sujeita aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. As funcionalidades de pré-DG estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Pode gerir a ordem das atualizações automáticas de clusters em clusters do Google Kubernetes Engine (GKE) em vários ambientes através da sequenciação da implementação. Por exemplo, pode validar uma nova versão em clusters de pré-produção antes de atualizar os clusters de produção. O GKE também oferece uma versão geralmente disponível da sequenciação de implementações que usa um modelo mais linear sem fases personalizadas.

Este documento pressupõe que tem conhecimentos sobre o seguinte:

• Atualizações de clusters
• Vista geral da gestão de frotas
• Canais de lançamento
• Esquema de controlo de versões no GKE
• Testes de resistência

Para configurar uma sequência de implementação, consulte o artigo Sequencie a implementação de atualizações de clusters.

Vista geral

A sequenciação da implementação do GKE permite-lhe definir uma sequência específica e ordenada para atualizações de clusters em vários ambientes, como atualizar primeiro os clusters no ambiente de desenvolvimento, depois no ambiente de teste e, finalmente, no ambiente de produção. Esta estratégia progressiva oferece um período de preparação incorporado, o que lhe permite descobrir e mitigar potenciais problemas antes de a atualização atingir os seus sistemas mais críticos.

A sequenciação da implementação baseia-se no conceito de frotas, que são agrupamentos lógicos de clusters do GKE mapeados para um ambiente (por exemplo, testes). Para usar esta funcionalidade, define uma sequência composta por frotas e define o tempo de imersão entre cada grupo. Quando o GKE seleciona uma nova versão, os seus clusters são atualizados na ordem definida, o que lhe permite validar as cargas de trabalho antes de a versão ser totalmente implementada no seu ambiente de produção.

As frotas suportam associações simples, que lhe permitem agrupar clusters de forma lógica para sequenciar a implementação sem ativar todas as configurações e funcionalidades ao nível da frota. A associação simples é uma boa escolha se quiser usar a sequenciação da implementação sem algumas das outras implicações da gestão total da frota, como a igualdade do espaço de nomes ao nível da frota. Para mais informações, consulte o artigo Subscrições simples.

Escolha uma estratégia de sequenciação da implementação

O GKE oferece duas versões da sequenciação de implementações. Ambas as versões são criadas com base nos mesmos princípios fundamentais de atualizações progressivas baseadas em frotas, mas oferecem diferentes níveis de flexibilidade. Esta secção ajuda a decidir que versão é mais adequada para o seu exemplo de utilização.

• Sequência de implementação baseada em frotas (GA): esta versão é a estratégia geralmente disponível e recomendada para a maioria dos exemplos de utilização de produção. A sequenciação da implementação baseada na frota oferece um método estável e suportado para implementar progressivamente atualizações em vários ambientes (como testes, preparação e produção) e usa uma sequência linear de frotas.

• Sequenciação da implementação com fases personalizadas (pré-visualização): esta versão é uma evolução do modelo baseado na frota, que oferece um controlo e uma flexibilidade mais detalhados. Com as fases personalizadas, pode definir fases específicas numa frota através de etiquetas, o que as torna uma boa opção para estratégias de implementação mais complexas, como a implementação de uma nova versão num pequeno subconjunto de clusters de produção antes de uma implementação mais ampla. Escolha esta opção se precisar de mais flexibilidade ou quiser pré-visualizar as capacidades de sequenciação de implementação mais recentes.

O resto deste documento refere-se apenas à sequenciação da implementação com fases personalizadas.

Implementação sequencial com fases personalizadas

Quando usa a sequenciação de implementações com fases personalizadas, define a ordem das atualizações da frota e define os tempos de teste de estabilidade. Além disso, também pode fazer o seguinte:

• Defina uma sequência com fases detalhadas que podem segmentar subconjuntos específicos de clusters numa frota através de etiquetas, o que a torna uma boa escolha para estratégias como implementações faseadas.
• Obtenha mais controlo e observabilidade através dos novos objetos da API RolloutSequence e Rollout.

Este método oferece a maior flexibilidade e controlo detalhado sobre as atualizações do cluster. Para segmentar subconjuntos específicos de clusters numa frota, usa um label-selector para segmentar apenas os clusters que têm etiquetas Kubernetes específicas.

O diagrama seguinte ilustra como o GKE atualiza automaticamente os clusters numa sequência de implementação que usa fases personalizadas. A fase segmenta clusters com um label-selector denominado canary na frota prod:

Figura: uma sequência de implementação com fases personalizadas

Quando um novo destino de atualização fica disponível no canal de lançamento onde todos os clusters nesta sequência estão inscritos, o GKE atualiza primeiro os clusters na frota de testes e, em seguida, os clusters na frota de preparação. Em seguida, na frota de produção, o GKE dá prioridade aos clusters que correspondem ao label-selector. Uma vez que prod-cluster-1 está etiquetado com canary: true, o GKE atualiza este cluster em seguida. O GKE atualiza todos os clusters restantes na frota de produção (na fase principal) no final do processo, porque esta fase não tem nenhum seletor de etiquetas.

Durante o tempo de preparação configurado entre as fases, pode confirmar que as suas cargas de trabalho estão a ser executadas conforme esperado nos clusters atualizados. O exemplo anterior mostra uma fase personalizada na frota de produção, mas pode adicionar várias fases a qualquer frota ou usar apenas uma frota com várias fases.

Conceitos-chave

• Tempo de preparação: este período é um período de espera configurável que ocorre após a atualização de todos os clusters numa fase. Este tempo de processamento permite-lhe validar a nova versão num ambiente e detetar potenciais problemas antes de a atualização avançar para o ambiente seguinte. Pode configurar um tempo de espera de até 30 dias para cada fase na sua sequência. Um período de teste mais longo numa fase de pré-produção dá-lhe mais tempo para a validação.
• RolloutSequence: este é o recurso principal que usa para definir a sequência de atualização. RolloutSequence contém uma série ordenada de fases, que verifica se os clusters nas fases anteriores estão totalmente atualizados e concluíram o respetivo período de teste antes de a atualização avançar para a fase seguinte.
• Rollout: este objeto permite-lhe observar o progresso de uma única atualização de versão através da sua sequência. Pode usar Rollout para ver o estado da implementação, acompanhar o progresso e ver se existem clusters inelegíveis para atualização e porquê.
• Projeto anfitrião dedicado: recomendamos que use um projeto Google Cloud dedicado para alojar os seus objetos RolloutSequence. Colocar a sequência num projeto dedicado oferece um ponto de controlo central e neutro para as sequências de implementação, o que é uma prática recomendada semelhante para gerir pipelines de CI/CD.

Prática recomendada:

Crie e faça a gestão dos seus recursos do RolloutSequence num projeto de anfitrião dedicado.

• Fases: uma fase é um passo na sequência de implementação. Cada fase contém um grupo de clusters que são atualizados em conjunto.
• Frotas: as frotas são a principal forma de agrupar clusters. Uma fase numa sequência de implementação pode referenciar apenas uma frota.
• Seletores de etiquetas: uma sequência de implementação é composta por uma ou mais fases. Cada fase contém clusters de uma frota e pode usar seletores de etiquetas em clusters para dividir ainda mais uma frota em várias fases. Esta abordagem permite estratégias como implementações faseadas, em que um pequeno subconjunto de clusters de produção é atualizado primeiro.

Como o GKE atualiza os clusters numa sequência de implementação

Quando o GKE atualiza um cluster, primeiro atualiza o painel de controlo e, de seguida, os nós. Numa sequência de implementação, os clusters continuam a ser atualizados através deste processo, mas também controla a ordem pela qual os grupos (frotas) de clusters são atualizados. Também especifica um tempo de saturação que define o tempo durante o qual o GKE pausa antes de as atualizações avançarem de um grupo para o seguinte.

As atualizações de clusters numa sequência de implementação são realizadas com os seguintes passos:

1. O GKE define um novo destino de atualização automática para clusters numa versão secundária num canal de lançamento específico, com uma nota de lançamento semelhante à seguinte mensagem: "Os planos de controlo e os nós com a atualização automática ativada no canal Regular vão ser atualizados da versão 1.29 para a versão 1.30.14-gke.1150000 com este lançamento."

2. O GKE começa a atualizar os painéis de controlo do cluster para a nova versão no primeiro grupo de clusters. Depois de o GKE atualizar o painel de controlo de um cluster, o GKE começa a atualizar os nós do cluster. O GKE respeita a disponibilidade de manutenção ao atualizar clusters numa sequência de implementação.

3. O GKE segue os passos abaixo para atualizações do plano de controlo:

   1. Depois de todas as atualizações do painel de controlo do cluster no primeiro grupo terminarem, o GKE inicia o período de imersão para as atualizações do painel de controlo. O GKE também inicia o período de teste de esforço se tiverem passado mais de 30 dias desde o início das atualizações do plano de controlo.

   2. Após a conclusão do período de saturação das atualizações do painel de controlo do cluster do primeiro grupo, o GKE começa a atualizar os painéis de controlo do segundo grupo para a nova versão. No entanto, tenha em atenção as seguintes considerações:

      • Em alguns casos, o GKE pode atualizar os painéis de controlo do cluster do primeiro grupo várias vezes antes de atualizar os painéis de controlo do cluster do segundo grupo. Quando esta situação ocorre, 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 controlo dos clusters do segundo grupo.
      • O GKE não atualiza o painel de controlo dos clusters no segundo grupo que tenham uma versão posterior à versão de destino da atualização automática qualificada pelo primeiro grupo.

4. Paralelamente às atualizações do plano de controlo, o GKE executa os seguintes passos para as atualizações de nós:

   1. Depois de as atualizações de nós de todos os clusters no primeiro grupo terminarem, o GKE inicia o período de saturação para as atualizações de nós. O GKE também inicia o período de saturação se tiverem decorrido mais de 30 dias desde o início das atualizações de nós.
   2. Após a conclusão do período de saturação das atualizações dos nós do primeiro grupo, o GKE começa a atualizar os nós do segundo grupo para a nova versão. No entanto, tenha em atenção as seguintes considerações:
      • Em alguns casos, o GKE pode atualizar os nós do cluster do primeiro grupo várias vezes antes de atualizar os nós do cluster do segundo grupo. Quando esta situação ocorre, 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 controlo do cluster do segundo grupo.
      • O GKE não atualiza os nós de clusters no segundo grupo que tenham uma versão mais recente do que o destino de atualização automática qualificado pelo primeiro grupo.

5. O GKE repete estes passos do segundo grupo para o terceiro grupo, até que os clusters em todos os grupos na sequência de implementação tenham sido atualizados para o novo destino de atualização.

Enquanto os clusters são atualizados em cada grupo, durante o período de teste de estabilidade, verifique se as cargas de trabalho com clusters que executam a nova versão do GKE funcionam como esperado .

Aviso: o GKE pode não conseguir avançar com as atualizações automáticas numa sequência de implementação se existirem discrepâncias de versões entre clusters nos grupos na sequência. Para mais informações, consulte o artigo Elegibilidade para a implementação.

Também é possível impedir a atualização dos clusters devido a janelas de manutenção ou exclusões, utilização de APIs descontinuadas ou outros motivos.

Como controlar as atualizações numa sequência de implementação

Com as atualizações de clusters numa sequência de implementação, os grupos de clusters são atualizados pela ordem que definiu e são testados em cada grupo durante o período que escolheu. Enquanto as atualizações estão em curso, pode verificar o estado e gerir a sequência de implementação conforme necessário. Também pode controlar o processo das seguintes formas:

• Pode modificar o tempo de teste de estabilidade predefinido para um grupo numa sequência de implementação, o que é útil se os testes revelarem que uma versão específica requer mais ou menos tempo de teste de estabilidade. Esta alteração ao tempo de permanência atualiza o tempo de permanência predefinido para todas as implementações atuais e futuras (para qualquer versão) criadas após a modificação.

• Para atualizações de clusters individuais, pode continuar a usar as seguintes ferramentas:
  • Controlar manualmente as atualizações através de ações como cancelar, retomar, reverter ou concluir atualizações do conjunto de nós.
  • Use janelas de manutenção e exclusões para decidir quando um cluster pode e não pode ser atualizado.
  • Configure estratégias de atualização de nós para equilibrar a velocidade e a tolerância ao risco, consoante as cargas de trabalho em execução nesses nós.

Aviso: se modificar uma sequência durante uma implementação, especificamente alterações que afetem os clusters participantes, o GKE cancela imediatamente todas as implementações existentes. Se modificar apenas o tempo de preparação de uma sequência, o GKE não cancela a implementação.

Exemplo: o banco comunitário implementa gradualmente alterações do teste para a produção

Um administrador de plataforma num banco comunitário gere três ambientes de implementação principais: testes, preparação e produção. Os clusters de produção estão distribuídos por várias regiões, com diferentes níveis de criticidade. Para gerir as atualizações de forma eficaz, o administrador agrupa os clusters em cada ambiente em frotas. Conforme necessário para a sequenciação da implementação, cada cluster nas três frotas está inscrito no mesmo canal de lançamento, neste caso, o canal Regular, e todos os clusters executam a mesma versão secundária.

O objetivo principal do administrador é garantir que as novas versões do GKE são exaustivamente avaliadas antes de chegarem ao ambiente de produção crítico do banco. Também querem atualizar progressivamente os clusters numa região com menor tráfego primeiro, depois passar para uma região com maior tráfego e, finalmente, para a região mais crítica. Para o conseguir, usam a sequenciação da implementação com fases personalizadas para definir uma estratégia de atualização progressiva que inclui a etiquetagem dos clusters de produção de acordo com a respetiva região. Esta abordagem permite-lhes validar uma nova versão num pequeno subconjunto de tráfego de produção antes de uma implementação completa.

Para implementar este plano, o administrador aplica as seguintes etiquetas aos clusters na frota de produção:

• Os clusters em us-west1 (tráfego mais baixo) estão etiquetados com prod-region: us-west1.
• Os clusters em europe-west1 (tráfego mais elevado) estão etiquetados com prod-region: europe-west1.
• Os clusters em us-east1 (tráfego mais crítico) não estão etiquetados. A fase final de uma frota numa sequência tem de funcionar como um "catch-all" para todos os clusters restantes. Por conseguinte, o administrador não precisa de adicionar etiquetas a estes clusters restantes.

Em seguida, num projeto de anfitrião dedicado usado para gerir configurações de CI/CD, definem um objeto RolloutSequence. Esta nova sequência tem cinco fases distintas:

1. Testes: esta fase inclui todos os clusters na frota testing. O administrador define um período de teste de três dias para permitir uma validação completa.
2. Preparação: esta fase inclui todos os clusters na frota staging, com um período de teste de três dias.
3. Produção na região us-west1: esta fase segmenta a frota de produção, mas usa um label-selector para incluir apenas os clusters com a etiqueta prod-region: us-west1. Esta fase permite ao administrador monitorizar eventuais problemas num 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 fase inclui os clusters na frota production que têm a etiqueta prod-region: europe-west1. O administrador define um tempo de teste de 4 dias mais longo para uma validação mais exaustiva.
5. Produção na região us-east1: esta fase final inclui os clusters restantes na frota production, ou seja, todos os clusters em us-east1.

Esta abordagem dá ao administrador um controlo detalhado sobre as atualizações de produção, o que melhora significativamente a segurança e a fiabilidade do processo de atualização, ao detetar potenciais problemas antes que possam afetar 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 preparação muito mais rapidamente do que o previsto. O administrador observa que a nova versão é estável e decide que o período de teste de três dias após a atualização da frota de preparação é desnecessariamente longo para este tipo de atualização de rotina.

Para acelerar esta implementação, o administrador modifica a RolloutSequencedefinição e reduz a duração do teste de esforço para a fase us-west1da frota de produção. Uma vez que esta alteração à definição de RolloutSequence atualiza o tempo de teste de esforço predefinido para todas as implementações atuais e futuras, o administrador toma nota para reverter o tempo de teste de esforço para o período original de três dias após a conclusão desta implementação de patch específica. Esta abordagem ajuda a garantir que o tempo de teste de estabilidade padrão e mais cauteloso está em vigor para futuras atualizações de versões secundárias.

O administrador usa janelas de manutenção e exclusões 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 numa sequência de implementação.

• O administrador configurou janelas de manutenção para os respetivos clusters, de modo que o GKE atualiza os clusters apenas após o horário de funcionamento.
• O administrador também usa exclusões de manutenção para impedir temporariamente a atualização dos clusters se detetar problemas com as cargas de trabalho do cluster.

O administrador usa uma combinação de atualizações rápidas e atualizações azul-verde para os respetivos nós, equilibrando a velocidade e a tolerância ao risco consoante as cargas de trabalho executadas nesses nós.

Elegibilidade para implementação

Para que uma versão seja implementada através de uma sequência com fases personalizadas, os clusters têm de ser elegíveis para um destino de atualização a partir do respetivo 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 elegíveis para a nova versão. Embora recomendemos que todos os clusters estejam inscritos no mesmo canal de lançamento, se não estiverem, o GKE seleciona uma versão do canal mais conservador na sequência. Por exemplo, se os clusters estiverem misturados entre os canais estável e normal, o GKE escolhe a versão do canal estável.

Em seguida, o Rollout avança pelas fases definidas no RolloutSequence. Num determinado estágio, a implementação do painel de controlo e a implementação do conjunto de nós podem ser executadas em paralelo. Uma regra fundamental que rege esta progressão é que, enquanto um estágio estiver num estado SOAKING com uma versão específica, o estágio não é elegível para iniciar um novo Rollout para uma versão mais recente. Esta prática ajuda a garantir que uma versão é totalmente validada antes de começar a atualização seguinte. Pode observar o progresso e a elegibilidade de cada cluster monitorizando o objeto de implementação. Se encontrar discrepâncias de versões que tornem um cluster inelegível, pode ter de tomar medidas, como atualizar manualmente o cluster, para permitir que a sequência avance. Se um cluster não for elegível para implementações, o GKE não atualiza automaticamente o cluster até que a versão atual atinja o fim do suporte técnico.

Os clusters que executam versões posteriores ao destino da atualização não impedem as atualizações

Se uma fase na sequência contiver clusters que executam uma versão posterior à versão de destino de uma implementação, o GKE atualiza os clusters elegíveis para a versão de destino e ignora os clusters que já estão numa versão posterior. Este comportamento não impede que a sequência de implementação avance para a fase seguinte.

Por exemplo, se a versão de destino de uma implementação gradual para uma fase for 1.32 e essa fase tiver clusters que executam as versões 1.31 e 1.33, o GKE atualiza os clusters na versão 1.31 para 1.32 e ignora os clusters que já estão na versão 1.33.

A fase anterior qualificou vários alvos de atualização para a fase seguinte

Uma fase anterior numa sequência pode concluir implementações de várias versões novas, enquanto uma fase subsequente está em pausa (por exemplo, devido a uma exclusão de manutenção) ou ainda está a processar uma atualização anterior. Neste caso, quando a fase subsequente fica pronta para aceitar uma nova atualização, o GKE atualiza a fase para a versão mais recente que foi qualificada. Para atualizações do plano de controlo, esta versão pode ser, no máximo, uma versão secundária posterior à versão do plano de controlo dos clusters na fase subsequente. Para atualizações de nós, esta versão pode ser igual ou anterior à versão do plano de controlo dos clusters na fase seguinte.

Por exemplo, este cenário é relevante se tiver configurado exclusões de manutenção para impedir temporariamente as atualizações nos seus clusters de produção. Se os clusters de pré-produção não tiverem as mesmas exclusões de manutenção, estes clusters podem ser atualizados várias vezes, qualificando várias novas versões, mas as fases de produção não são atualizadas.

Remolho forçado após 30 dias

Para ajudar a garantir que uma sequência de implementação termina a atualização dos clusters, o GKE inicia o período de saturação para um grupo se as atualizações do painel de controlo ou dos nós, respetivamente, não forem concluídas em todos os clusters dentro do tempo máximo de atualização (30 dias). As atualizações de todos os clusters restantes no grupo podem continuar durante o período de saturação.

Como funciona a sequenciação da implementação com outras funcionalidades de atualização

A sequenciação da implementação funciona em conjunto com outras funcionalidades de atualização do GKE:

• Janelas de manutenção e exclusões: ainda pode usar janelas de manutenção e exclusões para controlar quando as atualizações podem e não podem ocorrer nos seus clusters. O GKE inicia uma atualização do cluster apenas na janela de manutenção de um cluster. Pode usar uma exclusão de manutenção para impedir temporariamente a atualização de um cluster. Se o GKE não conseguir atualizar um cluster devido a um período de manutenção ou uma exclusão, esta circunstância pode impedir que as atualizações do cluster sejam concluídas numa fase. Se não for possível concluir uma atualização do cluster no prazo de 30 dias devido a janelas de manutenção ou exclusões, a fase entra na fase de teste de esforço, independentemente de todos os clusters terem terminado a atualização. As implementações do painel de controlo e do conjunto de nós podem ser executadas em paralelo numa determinada fase.

• Estratégias de atualização de nós: a sequenciação da implementação não afeta as estratégias de atualização de nós configuradas (por exemplo, atualizações azul-verde). Semelhante às atualizações de clusters que não têm sequenciação de implementação, o GKE usa atualizações de picos para nós do Autopilot. Para mais informações, consulte o artigo Upgrades automáticos de nós.

  Se as atualizações de nós não puderem ser concluídas no prazo de 30 dias, o grupo entra na fase de teste de estabilidade, independentemente de todos os clusters terem terminado a atualização. Este comportamento pode ocorrer se a estratégia de atualização de nós fizer com que a atualização de nós de um cluster padrão demore mais tempo a ser concluída, especialmente se for um conjunto de nós grande. A situação também pode ser agravada por períodos de manutenção que não são suficientemente grandes para que uma atualização do nó seja concluída.

• Canais de lançamento: recomendamos que inscreva todos os clusters numa sequência de implementação no mesmo canal de lançamento.

• Deteção de utilização de descontinuações: a deteção de utilização de descontinuações do GKE continua a funcionar como esperado, o que pode pausar as atualizações em clusters que usam uma API descontinuada.

• Atualizações manuais: a atualização manual de clusters na primeira fase de uma sequência não qualifica, por si só, essa versão nem aciona uma implementação para continuar. O processo de implementação automatizado é conduzido pelas segmentações de atualização automática oficiais definidas para o canal de lançamento. Uma atualização manual atualiza os clusters, mas a sequência começa a avançar para essa versão apenas depois de se tornar o destino de atualização automática designado.

Receber várias atualizações numa sequência

Um canal de lançamento seleciona um destino de atualização para o cluster. Se ficar disponível uma nova versão enquanto as atualizações para um destino anterior ainda estiverem em curso, a primeira fase pode iniciar a implementação de uma nova versão, mesmo quando as fases posteriores ainda recebem a atualização anterior. Por exemplo, se o terceiro grupo numa sequência estiver a implementar a versão 1.31.12-gke.1265000, o primeiro grupo na sequência pode implementar em simultâneo a versão 1.31.13-gke.1008000.

Considerações ao escolher a sequência de implementação

Considere usar a sequenciação de implementações se quiser gerir as atualizações de clusters qualificando novas versões num ambiente antes de as implementar noutro.

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

• Tem clusters que não estão no mesmo canal de lançamento ou versão secundária no mesmo ambiente de produção.
• Faz atualizações manuais com frequência que fazem com que os clusters num grupo tenham versões de destino de atualização automática diferentes.

Limitações

As seguintes limitações aplicam-se quando atualiza os clusters através da sequenciação de implementação com fases personalizadas:

• Não pode usar a Google Cloud consola para criar ou ver sequências de implementação com etapas personalizadas.
• Quando uma sequência de implementação faz referência a uma frota, tem de incluir toda a frota. Esta restrição significa que, se definir uma fase para segmentar apenas um subconjunto de clusters de uma frota com um label-selector (por exemplo, para uma implementação faseada), também tem de definir uma fase "catch-all" subsequente que inclua todos os clusters restantes dessa mesma frota. Esta fase geral segmenta a mesma frota, mas não inclui um label-selector, o que inclui automaticamente todos os clusters que não foram selecionados por fases anteriores na sequência.
• Se modificar uma sequência durante uma implementação, especificamente alterações que afetem os clusters participantes, o GKE cancela imediatamente todas as implementações existentes. Se modificar apenas o tempo de preparação de uma sequência, o GKE não cancela a implementação.
• Não pode acelerar manualmente uma implementação ativa para uma versão específica. Quando modifica a duração do período de teste na definição da sequência de implementação, a alteração atualiza o tempo de teste predefinido para todas as implementações atuais e futuras que são criadas após a modificação.
• O GKE atualiza automaticamente os clusters que atingiram o fim do apoio técnico para uma versão suportada, e esta atualização pode não seguir a sequência de implementação definida.
• Uma fase pode referenciar um máximo de uma frota. Não pode ter várias frotas numa única fase.
• Só é possível fazer referência a uma única frota numa sequência de implementação. Duas sequências de implementação não podem referenciar a mesma frota.

Problemas conhecidos

Esta secção descreve os problemas conhecidos para a sequenciação da implementação com fases personalizadas.

• Se uma fase na sua sequência de implementação não contiver clusters, a fase é ignorada, mas o tempo de teste de esforço definido para essa fase continua a decorrer antes de a implementação avançar para a fase seguinte.

O que se segue?

• Sequencie a implementação de atualizações de clusters com fases personalizadas