Sobre o sequenciamento de lançamento com etapas personalizadas

É 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 anterior desse recurso, o sequenciamento de implantação baseado em frota, que tem funcionalidade mais limitada e não é recomendado para novos ambientes.

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

Para configurar uma sequência de lançamento, consulte Sequenciar o lançamento de upgrades de cluster com etapas personalizadas.

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 logicamente para sequenciamento de lançamento sem ativar todas as configurações e recursos no nível da frota. A associação simplificada é uma boa opção se você quiser usar o sequenciamento de implantação 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 básicos de upgrades progressivos e baseados em frota, mas recomendamos usar o sequenciamento de lançamento com etapas personalizadas para novos ambientes:

  • Sequência de lançamento com etapas personalizadas (recomendado para novos ambientes): essa versão é uma evolução do modelo baseado em frota, oferecendo mais controle e flexibilidade granulares, mas sem suporte do console Cloud de Confiance . Com estágios personalizados, é possível definir estágios específicos em uma frota usando rótulos, o que é 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. Além disso, você tem mais controle sobre os lançamentos, como iniciar um lançamento para uma versão específica, escolher os tipos de upgrades a serem lançados em uma sequência e pausar ou cancelar lançamentos. Escolha essa opção se você estiver criando uma sequência de lançamento pela primeira vez.
  • Sequenciamento de lançamento baseado em frota:é a única versão desse recurso que pode ser usada com o console Cloud de Confiance . No entanto, ela tem funcionalidade mais limitada e não é recomendada se você estiver criando uma sequência de lançamento pela primeira vez.

O restante deste documento se refere apenas ao sequenciamento de lançamento com etapas personalizadas.

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 lançamentos graduais.
  • Tenha mais controle e capacidade de observação 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 estágios personalizados no GKE.
Figura : uma sequência de lançamento com estágios personalizados

Quando o GKE lança uma nova versão, ele faz upgrade primeiro dos clusters na frota de teste e depois dos clusters na frota de preparo. Em seguida, na frota Production, o GKE prioriza os 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) ao final do processo, porque essa etapa não tem um seletor de rótulo.

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 espera: um período de espera configurável que ocorre depois que todos os clusters em uma etapa são atualizados. Esse período permite validar a nova versão em um ambiente e detectar possíveis problemas antes que o upgrade prossiga para o próximo ambiente. É possível configurar um tempo de espera de até 30 dias para cada etapa da sequência. Um tempo de teste mais longo em uma etapa de pré-produção oferece mais tempo para validação.
  • RolloutSequence: esse objeto é o recurso principal usado para definir a 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 teste antes que o upgrade prossiga para a próxima etapa. Cada RolloutSequence tem um Rollout para cada nova versão lançada.
  • 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. Cada Rollout está associado a um RolloutSequence específico que representa a sequência de lançamento da versão.
  • Projeto host dedicado: recomendamos que você use um projeto Cloud de Confiance by S3NS 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, que é uma prática recomendada semelhante para gerenciar pipelines de CI/CD.
Prática recomendada:

Crie e gerencie seus recursos do 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 é possível 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 permanência 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 inicia um novo lançamento na sequência. Por padrão, um lançamento é iniciado quando 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. Para sequenciamento de lançamento com etapas personalizadas, é possível acionar um novo lançamento em uma sequência de lançamento para uma versão específica escolhida.

  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 a qualificada 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 a qualificada 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 a nova versão.

Enquanto os clusters são atualizados em cada grupo, durante o tempo de permanência, 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. Para mais informações sobre como controlar esse processo, consulte:

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 totalmente 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 do 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. O estágio 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. Teste: essa etapa 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 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 espera 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 preparo muito mais rápido do que o esperado. 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 etapa us-west1 da frota de Production. Como essa mudança na definição de RolloutSequence atualiza o tempo de espera padrão para todos os lançamentos atuais e futuros, o administrador anota para reverter o tempo de espera 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 espera 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, de modo que o GKE atualize os clusters somente após o horário comercial.
  • 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.

Além disso, o administrador pode gerenciar um lançamento com ações como pausar um lançamento se detectar problemas ou concluir uma etapa se tiver certeza das mudanças nela e estiver pronto para prosseguir imediatamente.

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 das cargas de trabalho em execução nesses nós.

Como o GKE inicia o lançamento de uma nova versão

Por padrão, o GKE cria um novo lançamento ao definir um novo destino de upgrade automático. A versão que o GKE seleciona para fazer o lançamento depende da versão secundária e do canal de lançamento dos clusters na sequência. Por exemplo, se os clusters estiverem executando a versão 1.35 do GKE no Canal normal e o GKE definir uma meta de upgrade automático para 1.35.5-gke.1000000, o GKE vai criar um novo Rollout.

No entanto, você também pode escolher uma versão que quer que o GKE implante.

Lançar uma versão específica

Também é possível iniciar um lançamento para uma versão específica, por exemplo, se você quiser aplicar um patch rápido em uma vulnerabilidade de segurança ou corrigir um problema crítico com seus clusters do GKE. Essa ação cria um objeto Rollout, iniciando um lançamento em toda a sequência da mesma forma que quando o GKE define um destino de upgrade automático. Para lançar uma nova versão, consulte Lançar uma versão específica.

Se você precisar lançar uma nova versão para um cluster o mais rápido possível, poderá fazer upgrades manuais de cluster para os clusters individuais. Os upgrades manuais são realizados no nível do cluster.

Escolher os tipos de upgrades que o GKE realiza em uma sequência de lançamento

Por padrão, o GKE implanta todos os tipos de upgrades de cluster em uma sequência de implantação, incluindo upgrades de versão de patch e versão secundária para o plano de controle e nós.

Há quatro tipos principais de upgrades:

  • Upgrades de versão de patch do plano de controle
  • Upgrades de versão de patch dos nós
  • Upgrades de versão secundária do plano de controle
  • Upgrades de versão secundária dos nós

É possível restringir o escopo dos upgrades de cluster em uma sequência de lançamento para realizar apenas tipos específicos de upgrades. Por exemplo, se você quiser que o GKE implante apenas upgrades do plano de controle e não de nós, especifique isso na sequência de lançamento.

Se você restringir o escopo dos upgrades de cluster para uma sequência de lançamento, o GKE não vai realizar esse tipo de upgrade automático para nenhum cluster na sequência de lançamento, exceto os upgrades automáticos obrigatórios, conforme necessário. Para mais informações, consulte Lançamentos para upgrades automáticos obrigatórios. Restringir o escopo dos upgrades de cluster não cancela os rollouts em andamento do tipo que você restringe. Isso apenas impede que o GKE crie rollouts futuros desse tipo.

Como o GKE não faz upgrade dos nós de um cluster para uma versão posterior à do plano de controle, restringir o escopo dos upgrades do plano de controle também pode restringir os upgrades de nós.

Para restringir o escopo de upgrades automáticos em uma sequência de lançamento, consulte Escolher quais tipos de upgrades o GKE realiza em uma sequência de lançamento.

Restringir o escopo de uma sequência de lançamento funciona de maneira semelhante às exclusões de manutenção, mas elas são definidas para clusters individuais ou pools de nós em um cluster.

Lançamentos para upgrades automáticos obrigatórios

Se o cluster estiver inscrito em uma sequência de lançamento, o GKE vai realizar upgrades automáticos de cluster para segurança e compatibilidade. Se os planos de controle dos clusters na sua sequência de lançamento não forem atualizados em 90 dias ou se os clusters estiverem executando uma versão secundária que atingiu o fim do suporte, o GKE vai criar um lançamento obrigatório para fazer upgrades automáticos. Esses lançamentos ajudam a garantir que o cluster permaneça com bom desempenho, disponível e seguro. O GKE cria rollouts para esses cenários, independentemente das restrições no escopo dos rollouts, das exclusões de manutenção ou de qualquer outro motivo de atraso.

Não é possível pausar ou cancelar esses tipos de lançamento. O GKE realiza esses tipos de upgrades de cluster, independentemente da inscrição na sequência de lançamento.

Para mais informações sobre essas políticas, consulte as seções a seguir:

Qualificação para o lançamento

Para que uma versão seja lançada em uma sequência que usa 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. Recomendamos que todos os clusters sejam registrados no mesmo canal de lançamento. Caso contrário, o GKE selecionará uma versão do canal mais conservador na sequência. Por exemplo, se os clusters forem misturados entre os canais Estável e Regular, o GKE vai escolher a versão do Canal estável.

O Rollout passa pelas etapas definidas no seu RolloutSequence. Em uma determinada etapa, a implantação do plano de controle e do pool de nós podem ser executadas 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. Monitore o objeto Rollout para acompanhar o progresso e a qualificação de cada cluster. 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 ou ignorar um cluster em uma sequência de lançamento, para permitir que o lançamento continue. Se um cluster não estiver qualificado para nenhum lançamento, o GKE não fará upgrade automático até que seja necessário criar lançamentos para upgrades automáticos obrigatórios, conforme descrito na seção anterior.

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 um estágio for 1.32, e esse estágio 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.

Uma etapa anterior em uma sequência pode concluir lançamentos para várias versões novas, enquanto uma etapa subsequente está pausada (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 posterior à versão do plano de controle dos clusters na etapa seguinte. 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 de 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.

Forçar a remoção após 30 dias

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 de 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 soaking.

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. Os dois métodos a seguir podem restringir o GKE a realizar determinados tipos de upgrades:

    No entanto, nenhum desses métodos que restringem o escopo dos upgrades de cluster impede os upgrades automáticos obrigatórios. Se o GKE não puder fazer upgrade de um cluster devido a uma janela de manutenção ou exclusão, isso pode 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.

  • 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 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 vai entrar na fase de imersão, mesmo que todos os clusters tenham concluído o upgrade. Esse comportamento 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 descontinuação: a detecção de uso de descontinuação do GKE ainda funciona como esperado, pausando potencialmente os 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.

  • Notificações de cluster: o GKE fornece notificações para sequenciamento de lançamento, além de outras notificações de cluster disponíveis. Para mais informações, consulte Notificações para sequenciamento de lançamento.

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.

Notificações para sequenciamento de lançamento

O GKE envia notificações de cluster, que fornecem informações críticas sobre upgrades de cluster no nível do cluster. Além disso, o GKE envia notificações sobre sequências de lançamento com etapas personalizadas e os lançamentos que ocorrem com essas sequências. Por exemplo, o GKE envia notificações quando um estágio de lançamento começa, termina ou é bloqueado. Ou o GKE envia uma notificação se você configurou incorretamente uma sequência de lançamento. Para mais informações, consulte o documento Notificações de cluster e as respectivas seções para RolloutEvent e RolloutSequenceEvent.

Gerenciar um lançamento

Quando o GKE lança uma nova versão nos clusters da sua sequência de lançamento, é possível usar as seguintes ações para controlar o processo enquanto você avalia como seu cluster e suas cargas de trabalho respondem à mudança. Além disso, é possível criar um novo lançamento para lançar uma versão específica.

Enquanto os upgrades estão em andamento, é possível verificar o status deles. Com base em como o upgrade está sendo feito, use as ações explicadas nas subseções a seguir.

Pausar um lançamento

É possível pausar um lançamento em andamento. Por exemplo, se você notar um possível problema com seus clusters e a nova versão sendo lançada, pause temporariamente o lançamento. O GKE não vai iniciar novas operações de upgrade para essa versão, permitindo que você investigue qualquer problema, conforme necessário. O GKE não vai interromper as operações de upgrade em andamento, mas não vai iniciar novas, incluindo para etapas subsequentes.

Para pausar um lançamento, consulte Pausar um lançamento.

Depois de pausar um lançamento, é possível retomar ou cancelar o lançamento. Um lançamento pode ser pausado por até 90 dias. Após 90 dias, o GKE cancela o lançamento.

Pausar um lançamento não impede que os próximos sejam iniciados. No entanto, esses lançamentos não vão substituir a etapa pausada. Por exemplo, se o GKE já tiver lançado a versão 1.34.8-gke.1000000 para a primeira e a segunda etapas, e você pausar o lançamento na terceira etapa, o GKE poderá iniciar um novo lançamento para a versão 1.35.5-gke.1163000 e fazer upgrade dos clusters nas duas primeiras etapas. No entanto, o GKE não vai iniciar upgrades para 1.35.5-gke.1163000 na terceira etapa até que o lançamento de 1.34.8-gke.1000000 seja concluído ou cancelado na terceira etapa.

Se houver vários lançamentos em andamento em uma sequência e você quiser pausar todos eles, será necessário fazer isso individualmente. Se você quiser impedir que o GKE inicie outros lançamentos, escolha quais tipos de upgrades o GKE realiza em uma sequência de lançamento.

Retomar um lançamento

Você pode retomar um lançamento pausado por menos de 90 dias depois de investigar possíveis problemas e quando estiver pronto para continuar com os upgrades. Só é possível retomar uma implementação pausada se outra implementação do mesmo tipo (implementação do plano de controle ou de nós) não estiver em execução ao mesmo tempo no mesmo estágio. Também é possível retomar um lançamento que foi pausado automaticamente pelo GKE por motivos técnicos ou comerciais, mas recomendamos cautela antes de fazer isso.

Se você retomar o lançamento, o GKE vai iniciar novas operações de upgrade para continuar lançando a nova versão nas etapas da sequência de lançamento.

Para retomar um lançamento, consulte Retomar um lançamento.

Cancelar um lançamento

É possível cancelar um lançamento, incluindo os que estão ativos ou foram pausados. Quando você cancela um lançamento, o GKE não cria automaticamente um novo lançamento para a mesma versão. No entanto, cancelar um lançamento não impede que o GKE lance versões posteriores. Se você quiser impedir que o GKE também lance versões posteriores, cancele todos os lançamentos em andamento e restrinja o escopo dos upgrades de cluster na sequência de lançamento.

Para cancelar um lançamento, consulte Cancelar um lançamento.

Se você precisar lançar a mesma versão que foi cancelada, lance uma versão específica.

Concluir uma etapa de lançamento

Se você tiver certeza de que o lançamento de uma versão pode passar para a próxima etapa na sequência de lançamento porque, por exemplo, concluiu os testes nessa etapa, é possível avançar manualmente o lançamento concluindo a etapa. Se você concluir a etapa, os clusters que o GKE ainda não tiver atualizado não serão atualizados como parte desse lançamento. Concluir a etapa também pula o tempo restante de imersão. Isso também significa que você não precisa mudar o tempo de espera no nível da sequência de lançamento.

Para concluir um estágio de lançamento, consulte Concluir um estágio de lançamento.

Gerenciar um lançamento mudando a sequência de lançamento

Também é possível gerenciar um lançamento realizando ações que afetam toda a sequência. No entanto, considere realizar as ações descritas nas seções anteriores, como pausar um lançamento. Algumas mudanças em uma sequência de lançamento podem cancelar os lançamentos em andamento, além de afetar o funcionamento dos lançamentos futuros na sequência. Se você quiser mudar apenas um lançamento, use as ferramentas fornecidas para gerenciar um lançamento em vez de mudar a sequência inteira.

No entanto, se você quiser mudar como uma sequência de lançamento funciona para todos os lançamentos, não apenas para o lançamento de uma nova versão, consulte a seção a seguir, Gerenciar uma sequência de lançamento.

Controlar upgrades individuais do cluster para gerenciar o lançamento

Para upgrades de cluster individuais, use as seguintes ferramentas para gerenciar upgrades:

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

Para mais informações, consulte Como o sequenciamento de lançamento funciona com outros recursos de upgrade.

Gerenciar uma sequência de lançamento

Para gerenciar uma sequência de lançamento, você pode realizar ações básicas, como:

  • Listar suas sequências de lançamento
  • Descrever uma sequência de lançamento

Além disso, é possível realizar ações como modificar uma sequência de lançamento e ignorar um cluster em uma sequência de lançamento. Essas ações são descritas nas subseções a seguir.

Para saber mais sobre como gerenciar o lançamento de uma versão em vez de toda a sequência de lançamento, consulte a seção anterior, Gerenciar um lançamento.

Como ignorar um cluster em uma sequência de lançamento

Por padrão, todos os clusters que fazem parte de uma frota em uma sequência de lançamento são atualizados como parte da sequência de lançamento. É possível adicionar clusters a estágios específicos ou fazer upgrade de todos os clusters em uma frota que não tenham rótulos.

No entanto, se você tiver um cluster que não quer incluir na sequência de implantação, é possível rotulá-lo para que o GKE ignore o cluster ao implantar novas versões. Isso pode ser necessário, por exemplo, se você precisar de mais tempo antes de fazer upgrade desse cluster específico. É possível ignorar um ou mais clusters em uma sequência de lançamento.

Se você ignorar um cluster em uma sequência de lançamento, o GKE não o considerará ao lançar uma nova versão e não fará upgrades automáticos para o cluster, exceto upgrades automáticos obrigatórios, incluindo upgrades automáticos no fim do suporte e upgrades automáticos para planos de controle que não foram atualizados em 90 dias.

Para ignorar um cluster em uma sequência de lançamento, consulte Ignorar um cluster em uma sequência de lançamento.

Como modificar uma sequência de lançamento

Se quiser mudar a forma como os lançamentos são feitos em uma sequência, você pode modificar a sequência de duas maneiras:

  • Edite uma sequência de lançamento modificando o arquivo de configuração YAML em que você definiu a sequência.
  • Modifique os clusters na sequência.

Se você modificar uma sequência de lançamento, vai acontecer o seguinte:

  • Se você adicionar, remover, mudar a ordem ou editar um estágio (por exemplo, para mudar o ID do projeto ou os seletores de rótulo) em uma sequência de lançamento, o GKE cancelará todos os lançamentos ativos.
  • Se você mudar o tempo de espera de uma etapa, o GKE não vai cancelar os rollouts ativos.

Para modificar uma sequência de lançamento, consulte Modificar uma sequência de lançamento.

Se você modificar os clusters em uma sequência, vai acontecer o seguinte:

  • Se você remover um cluster de uma sequência de lançamento ao removê-lo de uma frota, os lançamentos ativos vão continuar. O GKE pode fazer upgrade automático do cluster com base em procedimentos típicos para clusters não registrados em uma sequência.
  • Se você adicionar um cluster a uma frota em uma sequência de lançamento, o GKE fará upgrade desse cluster como parte de qualquer lançamento ativo que ainda não tenha passado da fase em que você o adicionou. No entanto, se a etapa tiver sido concluída para o lançamento, o GKE não fará upgrade do cluster nesse lançamento.

  • Se você mover um cluster para um estágio diferente sem editar a configuração da sequência de lançamento, o seguinte vai acontecer, dependendo se o estágio para onde você moveu o cluster foi concluído:

    • Se você mover um cluster para um estágio que já concluiu o lançamento, o GKE não vai fazer upgrade do cluster nesse lançamento.
    • Se você mover um cluster que já foi atualizado em um lançamento para uma etapa posterior inconcluída, o GKE vai ignorar o cluster e não interromperá o progresso do lançamento.

Para modificar os clusters em uma sequência, consulte Registrar um cluster no Cloud de Confiance by S3NS na sua frota.

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 Cloud de Confiance 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 subsequente de "catch-all" 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, incluindo 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 espera de uma sequência, o GKE não vai cancelar o lançamento.
  • 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 implantação não podem fazer referência à mesma frota.
  • Não é possível fazer upgrade de clusters com sequenciamento de lançamento que usam atualizações automáticas de patch aceleradas.
  • É possível criar uma sequência de lançamento com até 15 etapas.
  • É possível incluir até 250 clusters em uma frota. Para clusters com associações leves, é possível pedir um aumento de cota para até 2.000 clusters em uma frota. Para mais informações, consulte Cotas e limites.
  • É possível configurar um tempo máximo de teste por sequência de até 90 dias em todas as etapas.

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 absorção definido para essa etapa ainda vai passar antes que o lançamento avance para a próxima etapa.

A seguir