Sobre upgrades de cluster com sequenciamento de lançamento

É possível gerenciar a ordem dos upgrades automáticos nos clusters do Google Kubernetes Engine (GKE) em vários ambientes usando o sequenciamento de lançamento. Por exemplo, é possível qualificar uma nova versão em clusters de pré-produção antes de fazer upgrade dos clusters de produção. Para usar esse recurso, é preciso conhecerupgrades de cluster ,canais de lançamento egerenciamento de frota.

Para começar, consulte Sequência do lançamento dos upgrades de cluster.

Qualificar upgrades em vários ambientes

Para fazer upgrade dos clusters automaticamente com o sequenciamento de lançamento, use frotas ou escopos da equipe em que você agrupou seus clusters com a mesmacanal de lançamento e versão secundária em etapas da implantação. Escolha a sequência de frotas ou a sequência de escopos de equipe e defina o tempo de teste de imersão desejado entre cada grupo de clusters. Em seguida, quando o GKE seleciona uma nova versão para upgrades automáticos no canal de lançamento, seus grupos de clusters são atualizados na sequência definida por você. é possível validar se as cargas de trabalho são executadas conforme o esperado com uma nova versão antes que os upgrades comecem com os clusters de produção.

Sequência de lançamento baseado em frota

O diagrama a seguir ilustra como o GKE atualiza automaticamente os clusters em uma sequência de lançamento organizada com frotas:

Sequência de lançamento com base na frota. É possível organizar clusters em frotas ou subdividi-los ainda mais em frotas com escopos.

Com uma sequência baseada em frota, quando o GKE disponibiliza um novo destino de upgrade no canal de lançamento em que todos os clusters nessa sequência estão inscritos, o GKE faz upgrade desses grupos de clusters nessa sequência, com o upstream clusters da frota que qualificam a nova versão para clusters na frota downstream, para até três frotas. Upstream, na sequência de lançamento, refere-se ao grupo anterior e downstream, ao próximo.

Durante o tempo de imersão configurado entre as frotas, após a conclusão dos upgrades na frota upstream e antes de eles começarem na frota downstream, é possível confirmar se as cargas de trabalho estão sendo executadas conforme o esperado nos clusters atualizados.

Sequência de lançamentos baseada em equipe

Se você subdividiu ainda mais os clusters em uma frota por equipe ou aplicativo, crie uma sequência de lançamento entre escopos de equipe. Os escopos de equipe são uma construção no nível da frota empresarial para associar subconjuntos de clusters de frota a equipes de aplicativos específicas e podem ser usados para ativar uma variedade de recursos baseados em equipe, incluindo controle de acesso e observabilidade com escopo, bem como sequenciamento de lançamento.

Sequências de lançamento com base no escopo. É possível organizar clusters em frotas ou subdividi-los ainda mais em frotas com escopos.

Com os escopos da equipe, é possível criar várias sequências de lançamento em uma frota, cada uma com os próprios canais de lançamento, destinos de upgrade e tempos de imersão independentes. Uma sequência de lançamento baseada em equipe funciona de maneira idêntica a uma sequência de lançamento baseada em frota. A diferença é que os upgrades são qualificados entre os clusters de uma equipe específica em cada frota, em vez de de frota para frota. Isso é particularmente útil para operadores de aplicativos que querem gerenciar upgrades dentro dos clusters da própria equipe.

O sequenciamento de lançamento com base na equipe está em pré-lançamento, enquanto o sequenciamento de lançamento baseado na frota está em disponibilidade geral (GA, na sigla em inglês).

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 ou escopos) de clusters são atualizados e você especifica um tempo de permanência para escolher como longo, o GKE faz uma pausa antes que os upgrades continuem de um grupo para o próximo.

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

  1. O GKE define um novo destino de upgrade automático para clusters em uma versão secundária em um canal de lançamento específico, com as notas da versão mencionando algo semelhante à seguinte mensagem: "Planos de controle". e os nós com upgrade automático ativado no canal normal serão atualizados da versão 1.21 para a versão 1.22.15-gke.1000 com esta versão."
  2. O GKE começa a fazer upgrade dos planos de controle do cluster para a nova versão no primeiro grupo de clusters. Depois que o GKE faz upgrade do plano de controle de um cluster, o GKE começa a fazer upgrade dos nós do cluster. O GKE respeita a disponibilidade de manutenção ao fazer upgrade dos clusters em uma sequência de lançamento.
  3. O GKE realiza as seguintes etapas para upgrades do plano de controle:
    1. O GKE começa o período de imersão para upgrades do plano de controle depois que todos os upgrades do plano de controle no primeiro grupo forem concluídos ou 30 dias após o início dos upgrades.
    2. Depois que o período de imersão para upgrades do plano de controle do cluster no primeiro grupo for concluído, o GKE iniciará os upgrades do plano de controle no segundo grupo.
  4. Em paralelo aos upgrades do plano de controle, o GKE realiza as seguintes etapas para upgrades de nós:
    1. O GKE começa o período de imersão para upgrades de nós após a conclusão de todos os upgrades de nó do cluster no primeiro grupo ou após 30 dias do início do upgrade.
    2. O GKE inicia os upgrades de nós no segundo grupo para clusters em que o plano de controle já foi atualizado após o período de imersão para upgrades de nós no primeiro grupo.
  5. O GKE repete essas etapas do segundo grupo para o terceiro, até que os clusters em todos os grupos na sequência de lançamento tenham sido atualizados para o novo destino de upgrade.

À medida que os clusters são atualizados em cada grupo, verifique durante o tempo de permanência que suas cargas de trabalho são executadas conforme o esperado com clusters executando a nova versão do GKE.

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. Para saber mais, consulte Como o sequenciamento de lançamento funciona com outros recursos de upgrade.

Como controlar upgrades em uma sequência de lançamento

Com os upgrades de cluster em uma sequência de lançamento, os grupos de clusters são atualizados na ordem definida e mergulhados em cada grupo pelo tempo que você escolheu. Enquanto os upgrades estão em andamento, é possível verificar o status de uma sequência de lançamento e gerenciá-la conforme necessário. Também é possível controlar o processo das seguintes maneiras:

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

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

Por exemplo, o administrador da plataforma em um banco da comunidade gerencia três ambientes principais de implantação, cada um com um grupo de clusters organizados em uma frota: teste, preparo e produção. Como é necessário para o sequenciamento de implementação, o administrador inscreveu cada cluster em todas as três frotas no mesmo canal de lançamento. Nessas frotas, o canal normal, com todos clusters executando a mesma versão secundária

O administrador usa o sequenciamento de lançamento para definir a ordem em que o GKE faz upgrade dos clusters nesses ambientes. Pedir o lançamento dá ao administrador a oportunidade de verificar se as cargas de trabalho são executadas conforme o esperado com clusters em uma nova versão do GKE antes que o ambiente de produção seja atualizado para a nova versão. Essa sequência é ilustrada pelo diagrama de sequência de lançamento baseado em frota.

O administrador usa o tempo de imersão entre essas frotas que estão sendo atualizadas para verificar se as cargas de trabalho são executadas conforme o esperado com clusters na nova versão do GKE. Para a frota de testes, o administrador define o tempo de imersão como 14 dias para que tenha duas semanas completas para testar como as cargas de trabalho são executadas. Para o preparo, eles definem o tempo de imersão como sete dias, já que não precisam de tanto tempo adicional depois da execução das cargas de trabalho nos testes.

O administrador também pode modificar o tempo de imersão padrão para upgrades para versões específicas, o que pode ser feito em uma das seguintes situações:

  • O administrador termina de qualificar a versão antes que o tempo de imersão seja concluído e quer que os upgrades prossigam para a próxima frota. Portanto, ele define o tempo de imersão como zero.
  • O administrador precisa de mais tempo para qualificar a nova versão antes que os upgrades continuem para a próxima frota, já que eles perceberam um problema com algumas das cargas de trabalho e, portanto, definiram o tempo máximo para o máximo de 30 dias.

O administrador usa janelas de manutenção e exclusões para garantir 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 garantir 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.

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

O administrador muda para as sequências de lançamento com base na equipe

Se o administrador decidir que precisa agrupar ainda mais clusters dentro de uma frota por aplicativo e dar aos administradores da equipe do aplicativo mais controle sobre os upgrades do cluster, ele poderá usar escopos de equipe. Com os escopos de equipe, os administradores da equipe de aplicativos podem criar sequências de lançamento independentes com os grupos de clusters atribuídos às equipes, possivelmente em execução em diferentes canais de lançamento ou com diferentes tempos de imersão.

Por exemplo, se a equipe do banco de dados quiser que os clusters usem o Canal estável e tempos de imersão mais longos enquanto os clusters da equipe do site do front-end usam o canal rápido e tempos de imersão mais curtos, ela poderá usar os escopos da equipe para criar lançamentos separados de SQL. Esse tipo de sequência é ilustrado pelo diagrama da sequência de lançamento com base na equipe. Para fazer isso no seu ambiente, siga as instruções para alternar entre as sequências de lançamento com base na frota e na equipe.

Observe que o uso desse recurso requer clusters de locação única: em outras palavras, cada cluster individual é associado somente a uma única equipe. Os clusters compartilhados (que recebem suporte no gerenciamento geral de equipes da frota) não têm suporte para o sequenciamento de lançamento. Saiba mais sobre como gerenciar clusters para equipes em Gerenciamento de equipes da frota.

Qualificação para o lançamento

Para que os clusters sejam atualizados automaticamente com o sequenciamento de lançamento, todos os clusters em todos os grupos (frotas ou escopos) em uma sequência de lançamento precisam receber a mesma meta de upgrade. Os clusters precisam estar inscritos no mesmo canal de lançamento. Recomendamos que os clusters executem a mesma versão secundária que os destinos de upgrade são definidos por versão secundária. No entanto, para algumas versões, como a versão no exemplo a seguir, os clusters de várias versões secundárias receberam o mesmo destino, o que significa que os clusters puderam ser atualizados com sucesso na sequência de várias versões secundárias.

É possível verificar o status do lançamento de versões em sequência para ver mais informações sobre o status e se problemas de qualificação de versão estão impedindo que os upgrades continuem. Dependendo das discrepâncias da versão, talvez seja necessário realizar ações, como fazer upgrade manual de um cluster ou removê-lo de um grupo para que os upgrades de clusters continuem. Se um cluster em uma sequência de lançamento não tiver um destino de upgrade qualificado, o GKE não fará o upgrade automático do cluster até que a versão secundária atual do cluster chegue ao fim da vida útil.

Para resolver problemas de qualificação para o lançamento, consulte Resolver problemas de qualificação para lançamento.

Exemplo de versão do GKE

Por exemplo, a versão de 2022-R25 definiu um destino de upgrade para várias versões secundárias em clusters inscritos no canal normal. Um destino de upgrade pode ser uma nova versão secundária (1.20 a 1.21) ou apenas uma nova versão de patch (1.21.x-gke.x para 1.21.14-gke.4300). Nesta versão, no Canal normal, as seguintes versões novas foram disponibilizadas para clusters em versões secundárias específicas:

  • Os clusters nas versões 1.20 e 1.21 foram atualizados para 1.21.14-gke.4300.
  • Os clusters na versão 1.22 foram atualizados para 1.23.8-gke.1900.
  • Os clusters na versão 1.24 foram atualizados para 1.24.5-gke.600.

O grupo mais ascendente recebe todos os destinos de upgrade

Para clusters no primeiro grupo em uma sequência, que não tem um grupo upstream para qualificar novas versões, o GKE faz upgrade de todos os clusters com destinos de upgrade qualificados, independentemente de esses destinos serem diferentes de cada um. outro. Por exemplo, no primeiro grupo de uma sequência, se alguns clusters estivessem executando a versão 1.20, esses clusters poderiam ser atualizados para 1.21.14-gke.4300 e os clusters que executam a versão 1.24 poderiam ser atualizados para 1.24.5- gke.600 Isso ocorre porque, para o primeiro grupo em uma sequência, o GKE considera todos os destinos de upgrade qualificados para esses clusters, já que não há um grupo upstream para qualificar uma nova versão.

Um grupo upstream precisa qualificar apenas uma versão

Em qualquer grupo downstream, a determinação do upgrade de clusters depende se o grupo upstream tiver qualificado um destino de upgrade para o qual todos os clusters desse grupo estarão qualificados. Normalmente, isso significa que todos os clusters começam na mesma versão secundária. No entanto, na versão de exemplo, os clusters nas versões 1.20 e 1.21 tinham a mesma meta de upgrade.Portanto, os clusters que executam as duas versões podem, no mesmo grupo, qualificar o upgrade para 1.21.14-gke.4300

Se todos os clusters em um grupo não tiverem a mesma meta de upgrade, esse grupo não poderá qualificar uma meta de upgrade para o próximo grupo. Nessa situação, o GKE não pode fazer upgrade dos clusters automaticamente em grupos downstream. Por exemplo, se no primeiro grupo alguns clusters tiverem sido atualizados para 1.21.14-gke.4300 e outros para 1.23.8-gke.1900, os clusters do segundo grupo não poderão ser atualizados automaticamente à medida que não recebeu uma versão qualificada. Para avançar os upgrades nessa situação, consulte Corrigir qualificação em um grupo.

Um grupo upstream precisa qualificar uma versão correspondente aos clusters do próximo grupo

Se os clusters em um grupo upstream tiverem qualificado uma versão diferente daquela para a qual os clusters no grupo seguinte estão qualificados, o GKE também não poderá fazer upgrade automaticamente dos clusters em nenhum grupo downstream.

Por exemplo, se todos os clusters no primeiro grupo forem atualizados para 1.21.14-gke.4300, mas os clusters no segundo grupo estiverem executando 1.22 (em que o destino do upgrade é 1.23.8-gke.1900), os clusters do segundo grupo não serão atualizados automaticamente. O primeiro grupo se qualificou para 1.21.14-gke.4300, mas os clusters no segundo grupo (atualmente em 1.22) só estão qualificados para o upgrade 1.23.8-gke.1900, portanto, o GKE não pode automaticamente fazer upgrade desses clusters. Para avançar upgrades nessa situação, consulte Corrigir qualificação entre grupos.

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

O sequenciamento de lançamento é um recurso em uma coleção de recursos que fornece controle sobre o aspecto de upgrade do ciclo de vida do cluster. Nesta seção, explicamos como esse recurso funciona com alguns dos outros recursos disponíveis relacionados a upgrades de cluster.

Como o sequenciamento de lançamentos funciona com janelas e exclusões de manutenção

O GKE respeita janelas de manutenção e exclusões de manutenção ao fazer upgrade dos clusters com o sequenciamento de lançamento. 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. Se o GKE não puder fazer upgrade de um cluster devido a uma janela de manutenção ou exclusão, isso poderá impedir que os upgrades do cluster sejam concluídos em um grupo. Se um upgrade de cluster não puder ser concluído em 30 dias devido a janelas de manutenção ou exclusões, o grupo vai entrar na fase de imersão, mesmo que todos os clusters tenham concluído o upgrade.

É possível usar exclusões de manutenção como uma medida temporária para evitar que uma sequência conclua um lançamento em um grupo e passe para o próximo grupo. Para saber mais, consulte Atrasar a conclusão da versão do grupo.

Como o sequenciamento de lançamentos funciona com a detecção de uso descontinuado

O GKE pausa os upgrades do cluster quando detecta o uso de determinados recursos e APIs descontinuados. Os upgrades automáticos também são pausados para clusters em um grupo em uma sequência de lançamento. Para saber mais, consulte Como as descontinuações do Kubernetes funcionam com o GKE.

Como o sequenciamento de lançamentos funciona com estratégias de upgrade de nós

Os upgrades de nós usarão a estratégia de upgrade de nó configurada quando eles forem atualizados em uma sequência de lançamento. 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. Ela 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. Para saber mais, consulte Considerações ao configurar uma janela de manutenção.

Como o sequenciamento de lançamentos funciona com canais de lançamento

Os canais de lançamento são obrigatórios para usar o sequenciamento de lançamento. Todos os clusters em todos os grupos em uma sequência de lançamento precisam estar no mesmo canal de lançamento.

Como receber vários upgrades em uma sequência

Se uma nova versão se tornar um destino de upgrade no canal de lançamento enquanto os upgrades do cluster para um destino anterior ainda estiverem ocorrendo na sequência de lançamento, um grupo upstream poderá iniciar o lançamento de uma nova versão enquanto um grupo downstream ainda está recebendo o upgrade anterior. Por exemplo, se o terceiro grupo em uma sequência estiver lançando 1.24.2-gke.100, o primeiro grupo na sequência poderá ser lançado simultaneamente.

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 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ê precisa automatizar os upgrades que não podem ser mapeados para apenas três estágios de implantação, já que só é possível criar uma sequência de lançamento com até três grupos de clusters. Não é possível vincular grupos em várias sequências de lançamento para criar uma sequência com mais de três grupos.
  • Não é possível usar o gerenciamento de frotas.
  • Geralmente, você faz upgrades manuais que fazem com que os clusters de um grupo tenham versões de destino de upgrade automático diferentes.

Para criar sequências de lançamento baseadas em equipe, você também precisa ativar o GKE Enterprise nos seus projetos host da frota.

Limitações

Para fazer upgrade dos clusters com o sequenciamento de lançamento, você precisa aderir a estas limitações:

  • Se você estiver usando o sequenciamento de lançamentos baseado em equipe, registre um cluster em apenas um escopo de equipe. Se um cluster estiver inscrito em vários escopos de equipe, o GKE não poderá fazer upgrade automaticamente do cluster em uma sequência de implantação baseada em equipe.
  • Não é possível criar uma sequência de lançamento baseada em equipe com vários escopos de equipe na mesma frota.
  • Crie uma sequência de lançamento linear sem ciclos (um grupo tem um grupo downstream como seu grupo upstream) ou ramificações (um grupo tem mais de um grupo downstream).
  • Crie sequências de lançamento entre os escopos de uma equipe ou entre frotas. Não é possível criar sequências mistas com frotas e escopos da equipe na mesma sequência.
  • Verifique se todos os clusters em uma sequência de lançamento estão inscritos no mesmo canal de lançamento e executando a mesma versão secundária.

Problemas conhecidos

  • Se um grupo contiver clusters de diferentes locais, um upgrade de cluster poderá ficar temporariamente disponível apenas para alguns dos clusters devido ao lançamento gradual da nova versão. É mais provável que isso aconteça com o primeiro grupo de clusters e deve ser resolvido em uma semana.
  • Se houver um grupo vazio em uma sequência de lançamento, a forma como isso afetará a qualificação da versão depende das seguintes condições:
    • Se o grupo vazio não tiver um grupo upstream, os upgrades de cluster não prosseguirão para o grupo downstream, já que o grupo vazio não pode qualificar versões.
    • Se o grupo vazio tiver um grupo upstream, todos os upgrades de cluster pendentes entrarão no status COMPLETE e serão propagados para o grupo downstream.
  • Devido à forma como o GKE rastreia upgrades pequenos e patches, é possível ver dois upgrades do mesmo tipo e versão, mas com status diferentes ao verificar o status do escopo.

A seguir