Acerca das atualizações de clusters com sequenciação da implementação

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 da sequência de implementação que usa etapas personalizadas (pré-visualização) para lhe dar um controlo mais detalhado sobre as atualizações do cluster.

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

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.

  • Sequenciação da implementação baseada na frota (GA): esta versão é a estratégia 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.

  • Implementação sequencial 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 implementar 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.

Sequência de implementação baseada na frota

Para atualizar automaticamente clusters com a sequenciação da implementação, use frotas onde agrupou os seus clusters com o mesmo canal de lançamento e versão secundária em fases de implementação. Defina a sequência de implementações rápidas e o tempo de saturação que quer entre cada grupo de clusters. Em seguida, quando o GKE seleciona uma nova versão para atualizações automáticas no canal de lançamento, os seus grupos de clusters são atualizados na sequência que definiu, e pode validar se as cargas de trabalho são executadas conforme esperado com uma nova versão antes de as atualizações começarem com os seus clusters de produção.

O diagrama seguinte ilustra como o GKE atualiza automaticamente os clusters numa sequência de implementação organizada com frotas:

Sequência de implementação baseada na frota em que agrupa clusters em frotas.
Figura: uma sequência de implementação baseada na frota

Com uma sequência baseada na frota, quando o GKE disponibiliza um novo destino de atualização no canal de lançamento em que todos os clusters nesta sequência estão inscritos, o GKE atualiza estas frotas de clusters nesta sequência, com os clusters da frota a montante a qualificarem a nova versão para os clusters na frota a jusante, até um máximo de cinco frotas. A montante, numa sequência de implementação, refere-se ao grupo anterior e a jusante refere-se ao grupo seguinte.

Durante o tempo de teste de esforço configurado entre frotas, pode confirmar que as suas cargas de trabalho estão a ser executadas conforme esperado nos clusters atualizados.

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:

Implementação de sequência com fases personalizadas no GKE.
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.

Para mais informações sobre a sequenciação de implementações com fases personalizadas, consulte o artigo Acerca da sequenciação de implementações com fases personalizadas.

O resto deste documento refere-se apenas à sequenciação da implementação baseada na frota.

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 .

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:

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

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

Por exemplo, o administrador da plataforma de um banco comunitário gere três ambientes de implementação principais: testes, preparação e produção. Cada ambiente tem um grupo de clusters organizado numa frota. Conforme necessário para a sequenciação da implementação, o administrador inscreveu cada cluster nas três frotas no mesmo canal de lançamento, neste caso, o canal normal, com todos os clusters a executar a mesma versão secundária.

O administrador usa a sequenciação da implementação para definir a ordem em que o GKE atualiza os clusters nestes ambientes. A ordenação da implementação dá ao administrador a oportunidade de verificar se as respetivas cargas de trabalho são executadas conforme esperado com clusters numa nova versão do GKE antes de o ambiente de produção ser atualizado para a nova versão. Esta sequência é ilustrada pelo diagrama de sequência de implementação baseada na frota.

O administrador usa o tempo de imersão entre as frotas para verificar se as respetivas cargas de trabalho são executadas conforme esperado na nova versão do GKE. Para a frota de testes, o administrador define o tempo de teste de esforço para 14 dias, para ter duas semanas completas para testar o funcionamento das cargas de trabalho. Para o ambiente de preparação, definem o tempo de estabilização como 7 dias, uma vez que não precisam de tanto tempo adicional depois de as cargas de trabalho já terem sido executadas no ambiente de teste.

O administrador também pode substituir o tempo de teste de implementação predefinido para atualizações para versões específicas, o que pode ser útil numa das seguintes situações:

  • O administrador termina a qualificação da versão antes de o tempo de teste de estabilidade estar concluído e quer que as atualizações avancem para a frota seguinte. Por isso, define o tempo de teste de estabilidade como zero.
  • O administrador precisa de mais tempo para qualificar a nova versão antes de as atualizações passarem para a frota seguinte, uma vez que detetou um problema com algumas das respetivas cargas de trabalho. Por isso, define o tempo de teste de estabilidade 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 numa sequência de implementação.

  • O administrador configurou janelas de manutenção para os respetivos clusters, de modo que o GKE só atualiza os clusters 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 baseada na frota

Para que os clusters sejam atualizados automaticamente com a sequenciação da implementação, todos os clusters em todas as frotas numa sequência de implementação têm de receber o mesmo alvo de atualização. Os clusters têm de estar inscritos no mesmo canal de lançamento e recomendamos que executem a mesma versão secundária, uma vez que os destinos de atualização são definidos por versão secundária. No entanto, para algumas versões, como a versão no exemplo seguinte, os clusters de várias versões secundárias receberam o mesmo destino, o que significa que os clusters podiam ser atualizados com êxito na sequência de implementação que executava várias versões secundárias.

Pode verificar o estado da implementação da versão numa sequência para receber mais informações sobre o estado e se os problemas de elegibilidade da versão estão a impedir a continuação das atualizações. Consoante as discrepâncias de versões, pode ter de tomar medidas, como atualizar manualmente um cluster ou removê-lo de um grupo para que as atualizações de clusters continuem. Se um cluster numa sequência de implementação não tiver um destino de atualização elegível, o GKE não atualiza automaticamente o cluster até que a versão secundária existente do cluster atinja o fim do apoio técnico.

Para resolver problemas de elegibilidade para a implementação, consulte o artigo Resolva problemas de elegibilidade para a implementação.

Exemplo de versão do GKE

Por exemplo, o lançamento 2025-R45 definiu um destino de atualização para várias versões secundárias em clusters inscritos no canal Regular. Um destino de atualização 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, foram disponibilizadas as seguintes novas versões para clusters em versões secundárias específicas:

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

O grupo mais a montante recebe todos os alvos de atualização

Para clusters no primeiro grupo numa sequência, que não tem um grupo a montante para qualificar novas versões, o GKE atualiza todos os clusters com destinos de atualização elegíveis, independentemente de esses destinos de atualização serem diferentes entre si. Por exemplo, no primeiro grupo de uma sequência, se alguns clusters estivessem a ser executados na versão 1.30, esses clusters poderiam ser atualizados para a versão 1.31.13-gke.1023000 e os clusters que estivessem a ser executados na versão 1.32 poderiam ser atualizados para a versão 1.33.5-gke.1162000. Isto acontece porque, para o primeiro grupo numa sequência, o GKE considera todos os destinos de atualização como qualificados para estes clusters, uma vez que não existe um grupo a montante para qualificar uma nova versão.

Um grupo a montante tem de qualificar apenas uma versão

Para que os clusters em qualquer grupo a jusante comecem a ser atualizados, o grupo a montante tem de ter qualificado com êxito um único alvo de atualização comum para o qual todos os clusters no grupo a jusante são elegíveis. Se o grupo a montante tiver clusters que foram atualizados com êxito para duas versões diferentes (como pode acontecer quando o grupo a montante é o primeiro grupo numa sequência), o grupo a montante qualifica a versão inferior das duas como o destino de atualização comum para o grupo a jusante. Por exemplo, se o grupo a montante tiver alguns clusters atualizados para 1.31.13-gke.1023000 e outros clusters atualizados para 1.33.5-gke.1162000, o grupo qualifica 1.31.13-gke.1023000 como o destino de atualização comum para o grupo a jusante.

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

Se um grupo a jusante tiver clusters que executam uma versão mais recente do que o destino de atualização qualificado por um grupo a montante, o GKE atualiza os clusters elegíveis para o destino de atualização e ignora os clusters que já estão numa versão mais recente. Este comportamento não impede o progresso da sequência de implementação, desde que, pelo menos, um cluster no grupo a jusante seja elegível para o destino da atualização.

Por exemplo, se o grupo a montante se qualificar para a atualização para a versão 1.32 e o grupo a jusante tiver clusters a executar as versões 1.31 e 1.33, o GKE atualiza os clusters que executam a versão 1.31 para a versão 1.32 e ignora os clusters que executam a versão 1.33.

Um grupo a montante tem de qualificar uma versão que corresponda aos clusters do grupo seguinte

Se os clusters num grupo a montante qualificarem uma versão diferente daquela para a qual os clusters no grupo seguinte eram elegíveis, o GKE também não pode atualizar automaticamente os clusters em grupos a jusante.

Por exemplo, se todos os clusters no primeiro grupo foram atualizados para 1.31.13-gke.1023000, mas os clusters no segundo grupo estavam a executar uma versão mais recente, como 1.32.9-gke.1108000, os clusters do segundo grupo não seriam atualizados automaticamente. O primeiro grupo qualificou-se para 1.31.13-gke.1023000, mas os clusters no segundo grupo (atualmente na versão 1.32) só são elegíveis para o destino de atualização 1.33.5-gke.1162000. Por isso, o GKE não pode atualizar automaticamente estes clusters. Para avançar com as atualizações nesta situação, consulte o artigo Corrija a elegibilidade entre grupos.

O grupo a montante qualificou vários alvos de atualização para o grupo a jusante

Se o GKE atualizou os clusters no grupo a montante várias vezes antes de atualizar os clusters no grupo a jusante, o GKE atualiza os clusters no grupo a jusante para a versão mais recente qualificada pelo grupo a montante, para a qual os clusters no grupo a jusante são elegíveis. 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 no grupo a jusante. Para atualizações de nós, esta versão pode ser igual à versão do plano de controlo dos clusters no grupo a jusante, mas não posterior.

Por exemplo, este cenário é relevante se tiver configurado exclusões de manutenção para impedir temporariamente as atualizações do seu grupo a jusante, que inclui os clusters de produção. No entanto, o seu grupo a montante, que inclui clusters de pré-produção, também não usou exclusões de manutenção para impedir atualizações. Assim, o seu grupo a montante foi atualizado várias vezes, qualificando vários potenciais alvos de atualização, enquanto o seu grupo a jusante não foi atualizado.

As atualizações não concluídas no prazo de 30 dias são forçadas para desbloquear a sequência

Para 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 no 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 estabilização. Para mais informações, consulte a linha de FORCED_SOAKING na tabela de informações de estado de uma sequência de implementação.

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

A sequenciação da implementação é uma funcionalidade num conjunto de funcionalidades que lhe dão controlo sobre o aspeto da atualização do ciclo de vida do cluster. Esta secção explica como esta funcionalidade funciona com algumas das outras funcionalidades disponíveis relacionadas com as atualizações de clusters.

Como funciona a implementação faseada baseada na frota com janelas de manutenção e exclusões

O GKE respeita as janelas de manutenção e as exclusões de manutenção quando atualiza clusters com sequenciação de implementação. O GKE só inicia uma atualização de cluster dentro do período 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 a uma exclusão, esta circunstância pode impedir que as atualizações de clusters terminem num grupo. 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, o grupo entra na respetiva fase de teste de estabilidade, independentemente de todos os clusters terem terminado a atualização.

Pode usar exclusões de manutenção como uma medida temporária para impedir que uma sequência conclua uma implementação num grupo e avance para o grupo seguinte. Para mais informações, consulte o artigo Atrasar a conclusão da implementação da versão do grupo.

Como funciona a sequenciação da implementação baseada na frota com a deteção de utilização da descontinuação

O GKE pausa as atualizações de clusters quando deteta a utilização de determinadas APIs e funcionalidades descontinuadas. As atualizações automáticas também são pausadas para clusters num grupo numa sequência de implementação. Para mais informações, consulte o artigo Como funcionam as descontinuações do Kubernetes com o GKE.

Como funciona a sequenciação da implementação com as estratégias de atualização de nós

As atualizações de nós usam a respetiva estratégia de atualização de nós configurada quando são atualizadas numa sequência de implementação. Tal como nas atualizações de clusters sem sequenciação de implementação, o GKE usa atualizações de picos para nós do Autopilot. Para mais informações, consulte o artigo Atualizações automáticas 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. Também pode ser agravado por períodos de manutenção que não sejam suficientemente grandes para concluir uma atualização de um nó.

Como funciona a sequenciação da implementação com os canais de lançamento

Os canais de lançamento são obrigatórios para usar a sequenciação de implementações. Todos os clusters em todos os grupos numa sequência de implementação têm de estar no mesmo canal de lançamento.

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

Se uma nova versão se tornar um destino de atualização no canal de lançamento enquanto as atualizações de cluster para um destino de atualização anterior ainda estiverem a decorrer na sequência de implementação, um grupo a montante pode iniciar a implementação de uma nova versão enquanto um grupo a jusante ainda estiver a receber a atualização anterior. Por exemplo, se o terceiro grupo numa sequência estiver a ser implementado com a versão 1.31.12-gke.1265000, o primeiro grupo na sequência pode estar a ser implementado em simultâneo com a versão 1.31.13-gke.1008000.

Considerações ao escolher a sequenciação da implementação baseada na frota

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.
  • Tem de automatizar as atualizações que não podem ser mapeadas para apenas cinco fases de implementação, uma vez que só pode criar uma sequência de implementação com um máximo de cinco grupos de clusters. Não pode associar grupos em várias sequências de implementação para criar uma sequência de implementação com mais de cinco grupos. As sequências baseadas em frotas podem incluir até cinco frotas.
  • 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 da sequenciação da implementação baseada na frota

Para atualizar com êxito os seus clusters com a sequenciação da implementação, tem de cumprir as seguintes limitações:

  • Certifique-se de que todos os clusters numa sequência de implementação 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 atualização. Para mais informações, consulte o artigo Elegibilidade para implementação.
  • Crie uma sequência de implementação linear sem ciclos (um grupo tem um grupo a jusante como grupo a montante) ou ramificações (um grupo tem mais do que um grupo a jusante).
  • Crie uma sequência de implementação entre clusters na mesma organização. Não pode criar sequências com clusters em várias organizações.

Problemas conhecidos com a sequenciação da implementação baseada na frota

  • Se um grupo contiver clusters de localizações diferentes, uma atualização de cluster pode estar temporariamente disponível apenas para alguns dos clusters devido à implementação gradual da nova versão. É mais provável que este comportamento ocorra no primeiro grupo de clusters e deve ser resolvido no prazo de uma semana.
  • Se existir um grupo vazio numa sequência de implementação, a forma como isto afeta a qualificação da versão depende das seguintes condições:
    • Se o grupo vazio não tiver um grupo a montante, as atualizações de clusters não prosseguem para o grupo a jusante, uma vez que o grupo vazio não pode qualificar versões.
    • Se o grupo vazio tiver um grupo a montante, todas as atualizações de clusters pendentes entram no estado COMPLETE e propagam-se para o grupo a jusante.

O que se segue?