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

Pode gerir a ordem das atualizações automáticas de clusters em clusters do Google Kubernetes Engine (GKE) em vários ambientes através da sequenciação da implementação. Por exemplo, pode validar uma nova versão em clusters de pré-produção antes de atualizar os clusters de produção. Para usar esta funcionalidade, deve estar familiarizado com as atualizações de clusters, os canais de lançamento e a gestão de frotas.

Para começar, consulte o artigo Sequencie a implementação de atualizações de clusters.

Terminologia

Este documento usa o termo grupo para se referir a frotas ou âmbitos de equipa, porque pode criar uma sequência de implementação organizada com qualquer um dos métodos de agrupamento.

Qualifique atualizações em vários ambientes

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

Sequência de implementação baseada na frota

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

Sequência de implementação baseada na frota. Pode organizar clusters em frotas ou subdividi-los ainda mais em frotas com âmbitos.

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

Durante o tempo de teste de esforço configurado entre frotas, após a conclusão das atualizações na frota a montante e antes de começarem na frota a jusante, pode confirmar que as suas cargas de trabalho estão a ser executadas conforme esperado nos clusters atualizados.

Sequência de implementação baseada em equipas

Se subdividiu ainda mais os clusters numa frota por equipa ou aplicação, pode criar uma sequência de implementação entre âmbitos de equipa. Os âmbitos da equipa associam subconjuntos de clusters da frota a equipas de aplicações específicas e podem ser usados para ativar uma variedade de funcionalidades baseadas na equipa, incluindo o controlo de acesso e a observabilidade no âmbito da equipa, bem como a sequenciação da implementação.

Sequências de implementação baseadas no âmbito. Pode organizar clusters em frotas ou subdividi-los ainda mais em frotas com âmbitos.

Com os âmbitos de equipa, pode criar várias sequências de implementação numa frota, cada uma com os seus próprios canais de lançamento, alvos de atualização e tempos de teste independentes. Uma sequência de implementação baseada em equipas funciona de forma idêntica a uma sequência de implementação baseada em frotas, exceto que as atualizações são qualificadas entre os clusters de uma equipa específica em cada frota, em vez de frota a frota. Isto é particularmente útil para os operadores de aplicações que querem gerir as atualizações nos clusters da sua própria equipa.

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

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

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

  1. O GKE define um novo destino de atualização automática para clusters numa versão secundária num canal de lançamento específico, com a nota de lançamento a mencionar algo semelhante à seguinte mensagem: "Os planos de controlo e os nós com a atualização automática ativada no canal Regular vão ser atualizados da versão 1.21 para a versão 1.22.15-gke.1000 com este lançamento."
  2. O GKE começa a atualizar os painéis de controlo do cluster para a nova versão no primeiro grupo de clusters. Depois de o GKE atualizar o painel de controlo de um cluster, o GKE começa a atualizar os nós do cluster. O GKE respeita a disponibilidade de manutenção quando atualiza clusters numa sequência de implementação.

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

    1. O GKE inicia o período de teste para atualizações do painel de controlo depois de todas as atualizações do painel de controlo do cluster no primeiro grupo estarem concluídas. O GKE também inicia o período de teste de esforço se tiverem passado mais de 30 dias desde o início das atualizações do plano de controlo. Para mais informações, consulte o artigo As atualizações não concluídas no prazo de 30 dias são forçadas para desbloquear a sequência.

    2. Após o período de teste para as atualizações do painel de controlo do cluster no primeiro grupo estar concluído, o GKE inicia as atualizações do painel de controlo no segundo grupo para a nova versão. No entanto, tenha em atenção as seguintes restrições:

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

    1. O GKE inicia o período de saturação para atualizações de nós depois de todas as atualizações de nós do cluster no primeiro grupo estarem concluídas. O GKE também inicia o período de saturação se tiverem passado mais de 30 dias desde o início das atualizações de nós. Para mais informações, consulte o artigo As atualizações não concluídas no prazo de 30 dias são forçadas para desbloquear a sequência.
    2. Após o período de teste para as atualizações de nós no primeiro grupo estar concluído, o GKE inicia as atualizações de nós no segundo grupo para a nova versão. No entanto, compreenda as seguintes restrições:

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

À medida que os clusters são atualizados em cada grupo, verifique durante o período de teste que as cargas de trabalho são executadas conforme esperado com os clusters que executam a nova versão do GKE.

Também é possível impedir a atualização dos clusters devido a janelas de manutenção ou exclusões, utilização de APIs descontinuadas ou outros motivos. Para saber mais, consulte o artigo Como funciona a sequenciação da implementação com outras funcionalidades de atualização.

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

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

Para saber mais, veja como o sequenciamento da implementação funciona com outras funcionalidades de atualização.

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

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

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

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

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

  • O administrador termina a qualificação da versão antes de o tempo de teste de resistência estar concluído e quer que as atualizações avancem para a frota seguinte, pelo que define o tempo de teste de resistência como zero.
  • O administrador precisa de mais tempo para qualificar a nova versão antes de as atualizações passarem para a frota seguinte, uma vez que detetou um problema com algumas das respetivas cargas de trabalho. Por isso, define o tempo de teste de esforço para o máximo de 30 dias.

O administrador usa janelas de manutenção e exclusões para garantir que o GKE atualiza os clusters quando é menos disruptivo para o banco. O GKE respeita a disponibilidade de manutenção para clusters atualizados numa sequência de implementação.

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

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

O administrador muda para sequências de implementação baseadas em equipas

Se o administrador decidir que precisa de agrupar ainda mais os clusters numa frota por aplicação e dar aos administradores da equipa de aplicações um maior controlo sobre as atualizações dos respetivos clusters, pode usar âmbitos de equipa. Com os âmbitos de equipa, os administradores da equipa de aplicações podem criar sequências de implementação independentes com os grupos de clusters atribuídos às respetivas equipas, que podem ser executadas em diferentes canais de lançamento ou com diferentes tempos de teste de esforço.

Por exemplo, se a equipa da base de dados quiser que os respetivos clusters usem o canal estável e tempos de teste mais longos, enquanto os clusters da equipa do Website de front-end usam o canal rápido e tempos de teste mais curtos, podem usar os respetivos âmbitos de equipa para criar sequências de implementação separadas. Este tipo de sequência é ilustrado pelo diagrama da sequência de implementação baseada em equipas. Para o fazer no seu ambiente, siga as instruções para alternar entre sequências de implementação baseadas na frota e na equipa.

Tenha em atenção que a utilização desta funcionalidade requer clusters de posse única. Por outras palavras, cada cluster individual só está associado a uma única equipa. Os clusters partilhados (que são suportados na gestão geral de equipas de frotas) não são suportados para a sequenciação de implementações. Pode saber mais sobre a gestão de clusters para equipas em Gestão de equipas de frotas.

Elegibilidade para implementação

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

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

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

Exemplo de lançamento do GKE

Por exemplo, o lançamento 2022-R25 definiu um objetivo de atualização para várias versões secundárias em clusters inscritos no canal Regular. Um destino de atualização pode ser uma nova versão secundária (1.20 para 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, foram disponibilizadas as seguintes novas versões para clusters em versões secundárias específicas:

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

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

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

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

Em quaisquer grupos a jusante, a capacidade do GKE de atualizar clusters depende de o grupo a montante ter qualificado um destino de atualização para o qual todos os clusters neste grupo são elegíveis. Normalmente, isto significa que todos os clusters começam na mesma versão secundária. No entanto, a partir da versão de exemplo, os clusters nas versões 1.20 e 1.21 tinham o mesmo destino de atualização, pelo que os clusters que executavam ambas as versões podiam, no mesmo grupo, qualificar a atualização para a versão 1.21.14-gke.4300.

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

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

Por exemplo, se o grupo a montante qualificou a atualização para 1.23 e o grupo a jusante tiver clusters a executar 1.22 e 1.24, o GKE atualiza os clusters a executar 1.22 para 1.23 e ignora os clusters a executar 1.24.

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

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

Por exemplo, se todos os clusters no primeiro grupo foram atualizados para 1.21.14-gke.4300, mas os clusters no segundo grupo estavam a executar a versão 1.22 (em que o destino da atualização é 1.23.8-gke.1900), os clusters do segundo grupo não seriam atualizados automaticamente. O primeiro grupo qualificou-se para 1.21.14-gke.4300, mas os clusters no segundo grupo (atualmente na versão 1.22) só são elegíveis para o destino de atualização 1.23.8-gke.1900. Por isso, o GKE não pode atualizar automaticamente estes clusters. Para avançar com as atualizações nesta situação, consulte o artigo Corrija a elegibilidade entre grupos.

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

Se o GKE atualizou os clusters no grupo a montante várias vezes antes de atualizar os clusters no grupo a jusante, o GKE atualiza os clusters no grupo a jusante para a versão mais recente qualificada pelo grupo a montante, para a qual os clusters no grupo a jusante são elegíveis. Para atualizações do plano de controlo, esta versão pode ser, no máximo, uma versão secundária posterior à versão do plano de controlo dos clusters no grupo a jusante. Para atualizações de nós, esta versão pode ser igual à versão do plano de controlo dos clusters no grupo a jusante, mas não posterior.

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

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

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

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

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

Como funciona a sequenciação da implementação com janelas de manutenção e exclusões

O GKE respeita as janelas de manutenção e as exclusões de manutenção quando atualiza clusters com sequenciação de implementação. O GKE só inicia uma atualização de cluster dentro do período de manutenção de um cluster. Pode usar uma exclusão de manutenção para impedir temporariamente a atualização de um cluster. Se o GKE não conseguir atualizar um cluster devido a um período de manutenção ou a uma exclusão, isto pode impedir que as atualizações de clusters terminem num grupo. Se não for possível concluir uma atualização do cluster no prazo de 30 dias devido a janelas de manutenção ou exclusões, o grupo entra na respetiva fase de teste de esforço, independentemente de todos os clusters terem terminado a atualização.

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

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

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

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

As atualizações de nós usam a respetiva estratégia de atualização de nós configurada quando são atualizadas numa sequência de implementação. Tal como nas atualizações de clusters sem sequenciação de implementação, o GKE usa atualizações de picos para nós do Autopilot. Para mais informações, consulte o artigo Atualizações automáticas de nós.

Se as atualizações de nós não puderem ser concluídas no prazo de 30 dias, o grupo entra na fase de teste de estabilidade, independentemente de todos os clusters terem terminado a atualização. Isto pode acontecer se a estratégia de atualização de nós fizer com que a atualização de nós de um cluster padrão demore mais tempo a ser concluída, especialmente se for um conjunto de nós grande. Também pode ser agravado por períodos de manutenção que não sejam suficientemente grandes para concluir uma atualização de nós. Para saber mais, consulte o artigo Considerações ao configurar um período de manutenção.

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

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

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

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

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

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

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

  • Tem clusters que não estão no mesmo canal de lançamento ou versão secundária no mesmo ambiente de produção.
  • Tem de automatizar as atualizações que não podem ser mapeadas para apenas cinco fases de implementação, uma vez que só pode criar uma sequência de implementação com um máximo de cinco grupos de clusters. Não pode associar grupos em várias sequências de implementação para criar uma sequência de implementação com mais de cinco grupos. As sequências baseadas na frota podem incluir até cinco frotas e as sequências baseadas na equipa podem incluir até três âmbitos de equipa.
  • Não pode usar a gestão de frotas.
  • Faz atualizações manuais com frequência que fazem com que os clusters num grupo tenham versões de destino de atualização automática diferentes.

Limitações

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

  • Certifique-se de que todos os clusters numa sequência de implementação estão inscritos no mesmo canal de lançamento. Também recomendamos que todos os clusters executem a mesma versão secundária para se qualificarem para um alvo de atualização. Para mais informações, consulte o artigo Elegibilidade para implementação.
  • Se estiver a usar uma sequenciação de implementação baseada em equipas, inscreva um cluster apenas no âmbito de uma equipa. Se um cluster estiver inscrito em vários âmbitos de equipa, o GKE não pode atualizar automaticamente o cluster numa sequência de implementação baseada em equipas.
  • A criação de uma sequência de implementação baseada em equipas com vários âmbitos de equipa na mesma frota não é suportada.
  • Crie uma sequência de implementação linear sem ciclos (um grupo tem um grupo a jusante como grupo a montante) ou ramificações (um grupo tem mais do que um grupo a jusante).
  • Crie sequências de implementação entre os âmbitos de uma equipa ou sequências de implementação entre frotas. Não pode criar sequências mistas com âmbitos de frotas e de equipas na mesma sequência.
  • Crie uma sequência de implementação entre clusters na mesma organização. Não pode criar sequências com clusters em várias organizações.

Problemas conhecidos

  • Se um grupo contiver clusters de localizações diferentes, uma atualização de cluster pode estar temporariamente disponível apenas para alguns dos clusters devido à implementação gradual da nova versão. É mais provável que isto aconteça ao primeiro grupo de clusters e deve ser resolvido no prazo de uma semana.
  • Se existir um grupo vazio numa sequência de implementação, a forma como isto afeta a qualificação da versão depende das seguintes condições:
    • Se o grupo vazio não tiver um grupo a montante, as atualizações de clusters não prosseguem para o grupo a jusante, uma vez que o grupo vazio não pode qualificar versões.
    • Se o grupo vazio tiver um grupo a montante, todas as atualizações de clusters pendentes entram no estado COMPLETE e propagam-se para o grupo a jusante.
  • Devido à forma como o GKE acompanha as atualizações de patches e as atualizações secundárias, pode ver duas atualizações do mesmo tipo e versão, mas com estados diferentes quando verifica o estado do âmbito.

O que se segue?