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, a sequência de lançamento baseada em frota, que tem uma funcionalidade mais limitada e não é recomendada para novos ambientes.

Este documento pressupõe que você conhece os seguintes conceitos:

Para configurar uma sequência de lançamento, consulte Sequenciar o lançamento de upgrades de cluster com estágios personalizados.

Visão geral

O sequenciamento de lançamento do GKE permite 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, na produção. Essa estratégia progressiva oferece um tempo de teste integrado, permitindo que você descubra e mitigue possíveis problemas antes que o upgrade chegue aos sistemas mais críticos.

A sequência de lançamento é baseada 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 composta por frotas e defina o tempo de imersão entre cada grupo. Quando o GKE seleciona uma nova versão, os 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 assinaturas leves, que permitem agrupar clusters de forma lógica para o sequenciamento de lançamento sem ativar todas as configurações e recursos no nível da frota. A assinatura leve é uma boa opção se você quiser usar o sequenciamento de lançamento sem algumas das outras implicações do gerenciamento completo da frota, como a semelhança de namespace no nível da frota. Para mais informações, consulte Associações leves.

Escolher uma estratégia de sequenciamento de lançamento

O GKE oferece duas versões de sequenciamento de lançamento. As duas versões são criadas com base nos mesmos princípios de upgrades progressivos baseados em frota, mas recomendamos o uso do sequenciamento de lançamento com etapas personalizadas para novos ambientes:

  • Sequência de lançamento com fases personalizadas (recomendado para novos ambientes): essa versão é uma evolução do modelo baseado em frota, oferecendo mais controle granular e flexibilidade, mas sem suporte abrangente ao console do Cloud de Confiance . Com os estágios personalizados, é possível definir estágios específicos em uma frota usando rótulos, o que os torna 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 upgrade a serem lançados em uma sequência e pausar ou cancelar lançamentos. Escolha essa opção se estiver criando uma sequência de lançamento pela primeira vez.
  • Sequenciamento de lançamento baseado em frota: essa versão do recurso tem suporte mais abrangente no console do Cloud de Confiance , mas 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 estágios personalizados.

Sequenciamento de lançamento com estágios personalizados

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

  • 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 em fases.
  • Tenha mais controle e observabilidade com os novos objetos de API RolloutSequence e Rollout.

Esse método oferece mais flexibilidade e controle granular sobre os upgrades de cluster. Para segmentar subconjuntos específicos de clusters em uma frota, use um label-selector para segmentar apenas os clusters que têm 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. O estágio segmenta 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 dos clusters na frota de teste primeiro, seguidos pelos 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 fase principal) no final do processo, porque essa fase não tem nenhum seletor de rótulo.

Durante o tempo de imersão configurado entre as fases, é possível confirmar se as cargas de trabalho estão em execução conforme o esperado nos clusters atualizados. O exemplo anterior mostra um estágio personalizado na frota de Production, mas é possível adicionar vários estágios a qualquer frota ou usar apenas uma frota com vários estágios.

Principais conceitos

  • Tempo de imersão: um período de espera configurável que ocorre depois que todos os clusters em um estágio são atualizados. Esse tempo de imersão 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 imersão de até 30 dias para cada estágio da sequência. Um tempo de imersão maior em um estágio em 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 etapas, que verifica se os clusters nas etapas anteriores foram totalmente atualizados e concluíram o período de imersão 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 upgrade de versão única na sequência. Use Rollout para conferir o status do lançamento, acompanhar o progresso e ver se algum cluster não está qualificado para upgrade e por quê. Cada Rollout está associado a um RolloutSequence específico que representa a sequência em que a versão é lançada.
  • Projeto host dedicado: recomendamos que você use um projeto dedicado doCloud de Confiance by S3NS para hospedar seus objetos do 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. Um estágio em uma sequência de lançamento pode referenciar uma ou mais frotas. Uma única sequência de lançamento pode incluir frotas hospedadas em várias organizações doCloud de Confiance by S3NS .
  • Seletores de rótulos: uma sequência de lançamento é composta por um ou mais estágios. 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 em fases, em que um pequeno subconjunto de clusters de produção é atualizado primeiro.

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

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

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

  1. O GKE inicia um novo lançamento na sequência de lançamento. Por padrão, um lançamento é iniciado quando o GKE define um novo destino 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 estágios personalizados, também é possível acionar um novo lançamento em uma sequência de lançamento para uma versão específica de sua escolha.

  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 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 essa 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 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 posterior à versão 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 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 de cluster do primeiro grupo várias vezes antes de fazer upgrade dos nós de 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 posterior à versão 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 imersão, verifique se as cargas de trabalho com clusters que executam 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 importância. Para gerenciar os upgrades de maneira eficaz, o administrador agrupa os clusters de cada ambiente em frotas. Como é necessário para o sequenciamento de lançamento, cada cluster em todas as três frotas está inscrito no mesmo canal de lançamento. Nesse caso, o canal normal, e todos os clusters executam a mesma versão secundária.

O principal objetivo do administrador é garantir que as novas versões do GKE sejam totalmente verificadas antes de chegarem ao ambiente de produção crítico do banco. Eles também querem fazer upgrade progressivo dos clusters em uma região de menor tráfego primeiro, depois passar para uma região de maior tráfego e, por fim, para a região mais crítica. Para isso, eles usam o sequenciamento de lançamento com estágios personalizados 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 estão rotulados. O estágio final de uma frota em uma sequência precisa atuar 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: esse estágio inclui todos os clusters na frota testing. O administrador define um tempo de imersão de três dias para permitir uma validação completa.
  2. Staging: esse estágio inclui todos os clusters na frota staging, com um tempo de imersão de três dias.
  3. Produção na região us-west1: esse estágio tem como meta 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 pode monitorar problemas em um pequeno subconjunto de clusters de produção com um tempo de imersão de três dias.
  4. Produção na região europe-west1: esse estágio inclui os clusters na frota production que têm o rótulo prod-region: europe-west1. O administrador define um tempo de imersão mais longo de quatro dias para uma validação mais completa.
  5. Produção na região us-east1: essa 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 um upgrade de patch de rotina, os testes automatizados do banco são concluídos com sucesso no ambiente de preparo muito mais rápido do que o esperado. O administrador observa que a nova versão é estável e decide que o tempo de imersão de três dias após o upgrade da frota de preparo é 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 soak para o estágio us-west1 da frota de Production. Como essa mudança na definição de RolloutSequence atualiza o tempo de imersão padrão para todos os lançamentos atuais e futuros, o administrador faz uma observação para reverter o tempo de imersão para o período original de três dias após a conclusão desse lançamento de patch específico. Essa abordagem ajuda a garantir que o tempo de imersão padrão e mais cauteloso seja usado para futuros upgrades 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 em uma sequência de lançamento:

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

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 estiver confiante com as mudanças nela e estiver pronto para prosseguir imediatamente.

O administrador usa uma combinação de upgrades súbitos e azul-verde para os nós, equilibrando entre velocidade e tolerância de risco, dependendo nas 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 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 como 1.35.5-gke.1000000, o GKE vai criar um novo Rollout.

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

Como lançar uma versão específica

Também é possível iniciar um lançamento para uma versão específica se, por exemplo, você quiser corrigir rapidamente uma vulnerabilidade de segurança ou um problema crítico nos clusters do GKE. Essa ação cria um objeto Rollout, iniciando um lançamento em toda a sequência de lançamento 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 em um cluster o mais rápido possível, faça upgrades manuais de cluster para os clusters individuais. Os upgrades manuais de cluster são realizados no nível do cluster.

Como escolher os tipos de upgrade que o GKE realiza em uma sequência de lançamento

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

Há quatro tipos principais de upgrade:

  • 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 upgrade. Por exemplo, se você quiser que o GKE lance 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 para 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 lançamentos em andamento do tipo que você restringe, apenas impede que o GKE crie lançamentos futuros desse tipo.

Como o GKE não faz upgrade dos nós de um cluster para uma versão posterior ao 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 os tipos de upgrade que 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 as exclusões de manutenção são definidas para clusters individuais ou pools de nós em um cluster.

Lançamentos de 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 clusters na sequência de lançamento não tiverem os planos de controle atualizados em 90 dias ou se estiverem executando uma versão secundária que chegou ao fim do suporte, o GKE criará um lançamento obrigatório para realizar upgrades automáticos. Esses lançamentos ajudam a garantir que o cluster permaneça com bom desempenho, disponível e seguro. O GKE cria lançamentos para esses cenários, independentemente de restrições no escopo de lançamentos, exclusões de manutenção ou qualquer outro motivo de atraso.

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

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

Qualificação para o lançamento

Para que uma versão seja lançada por 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. Embora seja recomendável que todos os clusters estejam inscritos no mesmo canal de lançamento, se não estiverem, 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 normal, o GKE vai escolher a versão do canal estável.

Em seguida, o Rollout avança pelos estágios definidos no RolloutSequence. Em um determinado estágio, o lançamento do plano de controle e do pool de nós podem ser executados em paralelo. Uma regra importante que rege essa progressão é que, enquanto um estágio estiver em um estado SOAKING com uma versão específica, ele não poderá iniciar um novo Rollout para uma versão mais recente. Essa prática ajuda a garantir que uma versão seja totalmente validada antes do início do próximo upgrade. É possível observar o progresso e a qualificação de cada cluster monitorando o objeto Rollout. Se você encontrar discrepâncias de versão que tornem um cluster inelegível, talvez seja necessário realizar ações, 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á o upgrade automático dele até que seja necessário criar lançamentos para upgrades automáticos obrigatórios, conforme descrito na seção anterior.

Os clusters que executam versões posteriores ao destino do upgrade não impedem upgrades

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

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

O estágio anterior qualificou vários destinos de upgrade para o estágio seguinte

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

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 as etapas de produção não serão atualizadas.

Forced soaking após 30 dias

Para garantir que uma sequência de lançamento conclua o upgrade dos clusters, o GKE inicia o período de imersão de um grupo se os upgrades do plano de controle ou dos nós, 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 imersão.

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

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

  • Janelas e exclusões de manutenção: ainda é possível usar janelas e exclusões de manutenção para controlar quando os upgrades podem e não podem ocorrer nos clusters. O GKE só inicia um upgrade de cluster dentro da janela de manutenção de um cluster. É possível usar uma exclusão de manutenção para impedir temporariamente o upgrade de um cluster. Os dois métodos a seguir podem restringir o GKE para realizar determinados tipos de upgrades:

    No entanto, nenhum desses métodos que restringem o escopo dos upgrades de cluster impede 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, essa circunstância poderá impedir que os upgrades do cluster sejam concluídos em uma etapa. Se um upgrade de cluster não puder ser concluído em 30 dias devido a janelas de manutenção ou exclusões, o estágio vai entrar na fase de imersão, mesmo que todos os clusters tenham concluído o upgrade.

  • 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 entrará na fase de imersão, independentemente de todos os clusters terem concluído o upgrade. Isso pode acontecer se a estratégia de upgrade de nós fizer com que o upgrade de nós de um cluster padrão demore mais para ser concluído, especialmente se for um pool de nós grande. A situação também pode ser exacerbada por janelas de manutenção que não são grandes o suficiente para a conclusão de um upgrade de nós.

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

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

  • Upgrades manuais: o upgrade manual de clusters no primeiro estágio de uma sequência não qualifica essa versão nem aciona um lançamento para prosseguir. O processo de lançamento automatizado é impulsionado pelas metas oficiais de upgrade automático definidas 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 um destino 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 fase poderá iniciar o lançamento de uma nova versão, mesmo quando as fases 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 seguintes afirmações 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.
  • Geralmente, você faz upgrades manuais que fazem 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 importantes sobre upgrades no nível do cluster. Além disso, o GKE fornece notificações sobre sequências de lançamento com estágios personalizados e os lançamentos que ocorrem com essas sequências. Por exemplo, o GKE envia notificações quando um estágio de lançamento é iniciado, concluído 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.

Como 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 ações a seguir para controlar o processo enquanto avalia como o cluster e as 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á progredindo, use as ações explicadas nas subseções a seguir.

Como pausar um lançamento

É possível pausar um lançamento em andamento. Se, por exemplo, você notar um possível problema com os clusters e a nova versão que está 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 interrompe as operações de upgrade em andamento, mas não inicia novas, inclusive para as 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 ultrapassar o estágio de lançamento pausado. Por exemplo, se o GKE já tiver lançado a versão 1.34.8-gke.1000000 para o primeiro e o segundo estágios, e você pausar o lançamento no terceiro estágio, o GKE poderá iniciar um novo lançamento para a versão 1.35.5-gke.1163000 e fazer upgrade dos clusters nos dois primeiros estágios. No entanto, o GKE não vai iniciar os upgrades para 1.35.5-gke.1163000 na terceira etapa até que o lançamento de 1.34.8-gke.1000000 seja concluído na terceira etapa ou seja cancelado.

Se houver vários lançamentos em andamento para uma sequência de lançamento e você quiser pausar todos eles, pause cada lançamento individualmente. Se você quiser impedir que o GKE inicie outros lançamentos, escolha os tipos de upgrade que o GKE realiza em uma sequência de lançamento.

Como retomar um lançamento

É possível retomar um lançamento pausado há menos de 90 dias, depois de investigar possíveis problemas e se preparar para os upgrades. Só é possível retomar um lançamento pausado se outro lançamento do mesmo tipo (lançamento do plano de controle ou do nó) 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.

Como 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, o cancelamento de 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 prosseguir para a próxima etapa na sequência de lançamento porque, por exemplo, você concluiu os testes nessa etapa, é possível avançar manualmente o lançamento concluindo a etapa. Se você concluir o estágio, os clusters que o GKE ainda não tiver atualizado não serão atualizados como parte desse lançamento. A conclusão do estágio também ignora qualquer tempo de imersão restante. Essa ação também significa que você não precisa mudar o tempo de imersão no nível da sequência de lançamento.

Para concluir uma etapa de lançamento, consulte Concluir uma etapa de lançamento.

Como 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 de lançamento. No entanto, antes de fazer isso, considere as ações descritas nas seções anteriores, como pausar um lançamento. Algumas mudanças em uma sequência de lançamento podem fazer com que os lançamentos em andamento sejam cancelados, além de afetar como os lançamentos futuros funcionam na sequência. Se você quiser alterar apenas um lançamento, use as ferramentas fornecidas para gerenciar um lançamento, em vez de alterar toda a sequência.

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

Controlar upgrades de clusters individuais para gerenciar o lançamento

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

  • Controlar manualmente os upgrades tomando medidas, por exemplo, cancelando, retomando, revertendo ou concluindo upgrades de pool de nós.
  • Use exclusões e janelas 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 saber mais, consulte Como o sequenciamento de lançamento funciona com outros recursos de upgrade.

Como gerenciar uma sequência de lançamento

Para gerenciar uma sequência de lançamento, faça ações básicas como as seguintes:

  • Listar as 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, Como 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 todos os clusters que estão em uma frota e não estão rotulados serão atualizados juntos.

No entanto, se você tiver um cluster que não quer incluir na sequência de lançamento, rotule-o para que o GKE o ignore ao lançar novas versões. Talvez seja necessário fazer isso se, por exemplo, 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 realizará upgrades automáticos para o cluster, exceto para 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 você quiser mudar como os lançamentos ocorrem em uma sequência de lançamento, modifique a sequência de uma das seguintes maneiras:

  • Modifique uma sequência de lançamento editando 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 desse estágio) em uma sequência de lançamento, o GKE vai cancelar todos os lançamentos ativos.
  • Se você mudar o tempo de imersão de uma etapa, o GKE não vai cancelar as implementações ativas.

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 inscritos em uma sequência.
  • Se você adicionar um cluster a uma frota em uma sequência de lançamento, o GKE vai fazer upgrade desse cluster como parte de todos os lançamentos ativos que ainda não passaram do estágio em que você o adicionou. No entanto, se o estágio tiver sido concluído 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 o qual 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 fará upgrade do cluster nesse lançamento.
    • Se você mover um cluster que já foi atualizado em um lançamento para um estágio posterior inacabado, 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 para sua frota.

Limitações

As limitações a seguir 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 modificar sequências de lançamento com estágios personalizados. No entanto, é possível usar o console para monitorar um lançamento (pré-lançamento).
  • 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 um estágio para segmentar apenas um subconjunto de clusters de uma frota com um label-selector (por exemplo, para uma implantação em fases), também será necessário definir um estágio subsequente "catch-all" que inclua todos os clusters restantes dessa mesma frota. Esse estágio geral tem como alvo a mesma frota, mas não inclui um label-selector, incluindo automaticamente todos os clusters que não foram selecionados por estágios anteriores na sequência.
  • Se você modificar uma sequência durante um lançamento, especificamente as mudanças que afetam os clusters participantes, o GKE cancelará imediatamente todos os lançamentos atuais. Se você modificar apenas o tempo de imersão de uma sequência, o GKE não cancelará o lançamento.
  • Um estágio pode referenciar no máximo uma frota. Não é possível ter várias frotas em um único estágio.
  • Uma única frota só pode ser referenciada em uma sequência de lançamento. Duas sequências de lançamento não podem fazer referência à mesma frota.
  • Não é possível fazer upgrade de clusters com sequenciamento de lançamento que usam upgrades automáticos de patch acelerados.
  • É possível criar uma sequência de lançamento com até 15 estágios.
  • É possível incluir até 250 clusters em uma frota. Para clusters com assinaturas leves, é possível solicitar um aumento na cota para até 2.000 clusters em uma frota. Para mais informações, consulte Cotas e limites.
  • É possível configurar um tempo de imersão máximo por sequência de até 90 dias em todas as etapas.

Problemas conhecidos

Nesta seção, descrevemos os problemas conhecidos do sequenciamento de lançamento com estágios personalizados.

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

A seguir