Acerca das atualizações do GKE em vários clusters através da entrada em vários clusters

Autopilot Padrão

---

Este documento descreve como conceber, planear e implementar atualizações num ambiente do Google Kubernetes Engine (GKE) de vários clusters. Embora este documento use o Multi Cluster Ingress para atualizações, os conceitos podem ser aplicados a outras soluções, por exemplo, configurando manualmente um equilibrador de carga externo. Existe um tutorial complementar a este documento que mostra como atualizar um ambiente GKE de vários clusters com a Entrada em vários clusters. Este documento destina-se a administradores responsáveis pela manutenção de frotas para clusters do GKE. Google Cloud

A necessidade de uma arquitetura de vários clusters

Esta secção aborda vários motivos pelos quais pode precisar de uma arquitetura Kubernetes com vários clusters.

O Kubernetes como infraestrutura

Este documento considera os clusters do Kubernetes como componentes da infraestrutura. A infraestrutura é descartável. Não deve ser dado nenhum tratamento especial a nenhum componente de infraestrutura, uma vez que os componentes existem para um fim específico. O objetivo do Kubernetes é fornecer automatização e orquestração aos programadores e operadores para disponibilizar aplicações e serviços baseados em contentores aos consumidores. Os consumidores podem ser equipas internas, outros serviços ou clientes externos.

Cenários comuns de vários clusters

Além do argumento do Kubernetes como infraestrutura, existem vários motivos para ter um ambiente de vários clusters:

• Geografia. Muitos serviços têm de estar em várias regiões. Colocar um serviço mais perto do consumidor (na respetiva região) oferece uma melhor experiência devido à menor latência do que se o serviço for publicado a partir de uma única região. Um cluster do Kubernetes é executado numa única região. Para implementações multirregionais, são necessários vários clusters do Kubernetes em várias regiões. Os ambientes de nuvem híbrida ou multinuvém também requerem vários clusters em cada ambiente. Os clusters do Kubernetes também são frequentemente colocados com as origens de dados (com estado) dos Serviços. Determinadas aplicações podem ter de estar na mesma localização (região e zona) que o respetivo back-end, por exemplo, um sistema de gestão de bases de dados relacionais (RDBMS).
• Posse e ambientes. Os clusters do Kubernetes foram concebidos para multilocação. Várias equipas podem partilhar um único cluster para os respetivos serviços. O Kubernetes fornece recursos padrão, como namespaces, controlo de acesso baseado em funções (CABF), políticas de rede e autenticação, para configurar corretamente os controlos de acesso em ambientes multiinquilinos. Em alguns casos, determinados Serviços podem não poder coexistir num cluster com outros Serviços devido à política da empresa, à privacidade, à segurança ou à regulamentação da indústria. Nestes casos, são necessários vários clusters para separar determinados inquilinos nos respetivos clusters. Os ambientes (desenvolvimento, teste e produção) também são frequentemente criados como clusters separados. O âmbito do acesso e os tipos de aplicações instaladas em diferentes ambientes variam muito e devem ser mantidos como clusters separados.
• Composição e função. Por vezes, é criado um cluster para realizar uma função específica. Por exemplo, os fluxos de trabalho de aprendizagem automática usam o Kubeflow ou tarefas de análise de dados que podem exigir nós com GPUs ou outros requisitos de hardware para clusters de instâncias compostos por VMs de Spot para fins de cargas de trabalho de análise em lote. Estes requisitos de hardware podem não se aplicar a outros Serviços. Estes fluxos de trabalho podem não ser cruciais para a gestão da empresa e podem exigir clusters efémeros (clusters de curta duração). Os serviços partilhados, como a observabilidade (registos, métricas e rastreios) e as ferramentas de CI/CD, são mais adequados no respetivo cluster de administração da plataforma. Os clusters específicos de funções são frequentemente vistos para fluxos de trabalho não críticos para a empresa.
• Resiliência. Os vários clusters são frequentemente usados para aumentar a resiliência num ambiente. Cada cluster tem uma área de impacto. Neste contexto, uma área de impacto é o número de serviços que são afetados negativamente devido a um mau funcionamento do cluster, uma configuração incorreta ou um cluster a ficar offline devido a manutenção planeada ou não planeada. Se tiver um grande número de clusters de tamanho inferior, tem um grande número de áreas de impacto de tamanho inferior. Se um serviço existir em dois clusters, os clusters partilham a carga igualmente. Se um cluster ficar offline, 50% do tráfego é afetado. Se o mesmo serviço fosse publicado por um único cluster, qualquer evento nesse cluster causaria uma indisponibilidade de 100% para esse serviço. Por este motivo, também são frequentemente usados vários clusters para recuperação de desastres.

Este documento foca-se no aspeto da resiliência das implementações de vários clusters.

Serviços distribuídos e em vários clusters

Um serviço distribuído é um serviço do Kubernetes implementado em vários clusters do Kubernetes. Os serviços distribuídos são serviços sem estado e atuam de forma idêntica em vários clusters. Isto significa que um serviço distribuído tem o mesmo nome de serviço do Kubernetes e é implementado no mesmo espaço de nomes em vários clusters. Os serviços do Kubernetes estão associados ao cluster do Kubernetes no qual são executados. Se um cluster do Kubernetes ficar offline, o mesmo acontece com o serviço do Kubernetes. Os serviços distribuídos são abstraídos de clusters individuais do Kubernetes. Se um ou mais clusters do Kubernetes estiverem inativos, o serviço distribuído pode estar online e dentro do objetivo ao nível do serviço (SLO).

No diagrama seguinte, frontend é um serviço distribuído executado em vários clusters com o mesmo nome e espaço de nomes do serviço.

Com esta arquitetura, o serviço frontend não está associado a um único cluster e é representado conceptualmente no diagrama como uma camada que abrange a camada de infraestrutura do cluster do Kubernetes. Se algum dos clusters individuais que estão a executar o serviço frontend ficar inativo, o frontend permanece online. Existem serviços adicionais em execução em clusters individuais únicos: accounts Service e ledger Service. O tempo de atividade e a disponibilidade dependem do tempo de atividade do cluster do Kubernetes no qual residem.

A resiliência é um dos motivos para as implementações em vários clusters. Os serviços distribuídos criam serviços resilientes numa arquitetura de vários clusters. Os serviços sem estado são candidatos ideais para serviços distribuídos num ambiente de vários clusters. Os seguintes requisitos e considerações aplicam-se quando trabalha com serviços distribuídos:

• Redes em vários clusters. Pode enviar tráfego destinado a um serviço distribuído para clusters que estejam a executar esse serviço através de uma tecnologia de entrada em vários clusters, como a entrada em vários clusters, ou através da sua própria solução de proxy ou equilibrador de carga externo. Qualquer que seja a opção que usar, tem de lhe dar controlo sobre quando, onde e quanto tráfego é encaminhado para uma instância específica de um serviço distribuído. O diagrama seguinte mostra um balanceador de carga a enviar tráfego para um serviço distribuído frontend que está a ser executado em dois clusters do GKE.

  

• Observabilidade. Use ferramentas para medir os seus SLOs, normalmente a disponibilidade e a latência, coletivamente para um serviço distribuído. Esta configuração oferece uma vista global do desempenho de cada serviço em vários clusters. Embora o serviço distribuído não seja um recurso bem definido na maioria das soluções de observabilidade, pode recolher e combinar métricas de serviço individuais do Kubernetes. As soluções como o Cloud Monitoring ou as ferramentas de código aberto, como o Grafana, fornecem métricas do serviço Kubernetes. As soluções de malha de serviços, como o Istio e a malha de serviços na nuvem também fornecem métricas de serviços sem necessidade de instrumentação.

• Posicionamento de serviços. Os serviços do Kubernetes oferecem tolerância a falhas ao nível do nó num único cluster do Kubernetes. Isto significa que um serviço do Kubernetes pode resistir a falhas de nós. Durante as indisponibilidades de nós, um nó do painel de controlo do Kubernetes reagenda automaticamente os pods para nós em bom estado. Um serviço distribuído oferece tolerância a falhas ao nível do cluster. Isto significa que um serviço distribuído pode resistir a falhas de clusters. Quando planear a capacidade de um serviço distribuído, tem de considerar este posicionamento do serviço. Um Serviço distribuído não tem de ser executado em todos os clusters. Os clusters nos quais um serviço distribuído é executado dependem dos seguintes requisitos:

  • Onde, ou em que regiões, é necessário o serviço?
  • Qual é o SLO necessário para o serviço distribuído?
  • Que tipo de tolerância a falhas é necessária para o serviço distribuído: cluster, zonal ou regional? Por exemplo, precisa de vários clusters numa única zona ou de vários clusters em várias zonas numa única região ou em várias regiões?

  • Que nível de indisponibilidades deve o serviço distribuído suportar no pior cenário? As seguintes opções estão disponíveis ao nível do cluster:

    • N+1 (em que N representa o número de clusters necessários para satisfazer as necessidades de capacidade do serviço). Um serviço distribuído pode resistir a uma única falha de cluster
    • N+2. Um serviço distribuído pode resistir a duas falhas simultâneas. Por exemplo, uma indisponibilidade planeada e não planeada de um serviço Kubernetes em dois clusters ao mesmo tempo.

• Implementações e reversões. Os serviços distribuídos, como os serviços do Kubernetes, permitem implementações e reversões graduais. Ao contrário dos serviços do Kubernetes, os serviços distribuídos permitem que os clusters sejam uma unidade adicional de implementação como meio de mudança gradual. As implementações e as reversões também dependem do requisito do serviço. Em alguns casos, pode ter de atualizar o serviço em todos os clusters ao mesmo tempo, por exemplo, uma correção de erros. Noutros casos, pode ter de implementar lentamente (ou escalonar) a alteração de um cluster de cada vez. Esta implementação gradual reduz o risco para o serviço distribuído, introduzindo gradualmente alterações ao serviço. No entanto, este processo pode demorar mais tempo, consoante o número de clusters. Não existe uma estratégia de atualização única que seja a melhor. Muitas vezes, são usadas várias estratégias de implementação e reversão, consoante os requisitos do serviço distribuído. O ponto importante aqui é que os serviços distribuídos têm de permitir alterações graduais e controladas no ambiente.

• Continuidade do negócio e recuperação de desastres (BCDR). Estes termos são frequentemente usados em conjunto. A continuidade do negócio refere-se à continuação dos serviços críticos em caso de um evento importante (planeado ou não planeado), enquanto a recuperação de desastres refere-se aos passos tomados ou necessários para devolver as operações empresariais ao seu estado normal após esses eventos. Existem muitas estratégias para a BCDR que estão fora do âmbito deste documento. A PCDR requer algum nível de redundância nos sistemas e serviços. O princípio fundamental dos serviços distribuídos é que são executados em várias localizações (clusters, zonas e regiões).

  As estratégias de BCDR dependem frequentemente das estratégias de implementação e reversão discutidas anteriormente. Por exemplo, se as implementações forem realizadas de forma faseada ou controlada, o efeito de um erro ou de um envio de configuração incorreto pode ser detetado antecipadamente sem afetar um grande número de utilizadores. Numa grande escala e juntamente com uma taxa de alteração rápida (por exemplo, nas práticas modernas de CI/CD), é comum que nem todos os utilizadores recebam a mesma versão de um serviço distribuído. O planeamento e as estratégias de BCDR em sistemas e serviços distribuídos diferem das arquiteturas monolíticas tradicionais. Nos sistemas tradicionais, é feita uma alteração em grande escala, que afeta um grande número de utilizadores, ou talvez todos, e, por isso, tem de ter um sistema redundante ou de cópia de segurança em vigor em caso de efeitos indesejados de uma implementação. Nos sistemas e serviços distribuídos, quase todas as alterações são feitas de forma gradual para afetar apenas um pequeno número de utilizadores.

• Gestão do ciclo de vida do cluster. Tal como as implementações controladas e as reversões, os serviços distribuídos permitem a gestão controlada do ciclo de vida do cluster. Os serviços distribuídos oferecem resiliência ao nível do cluster, para que os clusters possam ser retirados da rotação para manutenção. A gestão do ciclo de vida do cluster é um princípio dos serviços distribuídos que não se aplica aos serviços do Kubernetes.

O resto deste documento foca-se no aspeto do ciclo de vida do cluster dos serviços distribuídos.

Gestão do ciclo de vida do cluster do GKE

A gestão do ciclo de vida do cluster pode ser definida como as estratégias e o planeamento necessários para manter uma frota de clusters do Kubernetes atualizada e em bom estado sem violar os SLOs de serviço. Com as estratégias e o planeamento adequados, a gestão do ciclo de vida do cluster deve ser rotineira, esperada e sem incidentes.

Este documento centra-se na gestão do ciclo de vida do GKE. No entanto, pode aplicar estes conceitos a outras distribuições do Kubernetes.

Controlo de versões e atualizações do GKE

Antes de discutir estratégias e planear a gestão do ciclo de vida do cluster, é importante compreender o que constitui uma atualização do cluster.

Um cluster contém dois componentes: nós do plano de controlo e nós de trabalho. Uma atualização do cluster do Kubernetes requer que todos os nós sejam atualizados para a mesma versão. O Kubernetes segue um esquema de versões semânticas. As versões do Kubernetes são expressas como X.Y.Z:, em que X é a versão principal, Y é a versão secundária e Z é a versão do patch. Os lançamentos secundários ocorrem aproximadamente a cada três meses (trimestralmente), e o projeto Kubernetes mantém ramos de lançamento para os três lançamentos secundários mais recentes. Isto significa que uma versão secundária do Kubernetes com nove meses já não é mantida e pode exigir alterações à API quando fizer a atualização para a versão mais recente. As atualizações do Kubernetes têm de ser planeadas com uma frequência regular. Recomendamos que faça atualizações planeadas do GKE trimestralmente ou a cada dois trimestres.

Os clusters do GKE suportam a execução de versões do Kubernetes a partir de qualquer versão secundária suportada. Estão disponíveis, pelo menos, duas versões secundárias em qualquer altura.

O GKE é um serviço gerido e oferece atualizações automáticas para nós do plano de controlo e nós de trabalho.

Atualização automática do GKE

A atualização automática do GKE é uma estratégia de ciclo de vida do cluster popular e usada com frequência. A atualização automática do GKE oferece uma forma totalmente gerida de manter os seus clusters do GKE atualizados para versões suportadas. As atualizações automáticas do GKE atualizam os nós do painel de controlo e os nós de trabalho separadamente:

• Domine as atualizações automáticas. Por predefinição, os nós do plano de controlo do GKE são atualizados automaticamente. Os clusters de zona única e de várias zonas têm um único plano de controlo (nó do plano de controlo). Durante as atualizações dos nós do plano de controlo, as cargas de trabalho continuam a ser executadas. No entanto, não pode implementar novas cargas de trabalho, modificar cargas de trabalho existentes nem fazer outras alterações à configuração do cluster até a atualização estar concluída.

  Os clusters regionais têm várias réplicas do plano de controlo e apenas uma réplica é atualizada de cada vez. Durante a atualização, o cluster permanece altamente disponível e cada réplica do plano de controlo fica indisponível apenas durante a atualização.

• Atualizações automáticas de nós de trabalho. Os node pools são atualizados um de cada vez. Num node pool, os nós são atualizados um de cada vez numa ordem indefinida. Pode alterar o número de nós atualizados de cada vez, mas este processo pode demorar várias horas, consoante o número de nós e as respetivas configurações de carga de trabalho.

Estratégia do ciclo de vida de atualização automática do GKE

Recomendamos a utilização da atualização automática do GKE sempre que possível. As atualizações automáticas do GKE dão prioridade à conveniência em detrimento do controlo. No entanto, as atualizações automáticas do GKE oferecem muitas formas de influenciar quando e como os seus clusters são atualizados dentro de determinados parâmetros. Pode influenciar os períodos de manutenção e as exclusões de manutenção. Os canais de lançamento influenciam a seleção de versões e as estratégias de atualização de nós influenciam a ordem e o momento das atualizações de nós. Apesar destes controlos e dos clusters regionais (com vários planos de controlo do Kubernetes), a atualização automática do GKE não garante o tempo de atividade dos serviços. Pode optar por não usar a funcionalidade de atualização automática do GKE se precisar de uma ou mais das seguintes opções:

• Controlo da versão exata dos clusters do GKE.
• Controlar a hora exata para atualizar o GKE.
• Controlar a estratégia de atualização (abordada na secção seguinte) para a sua frota do GKE.

Gestão do ciclo de vida de vários clusters do GKE

Esta secção descreve várias estratégias de gestão do ciclo de vida de vários clusters do GKE e como planear a sua utilização.

Considerações de planeamento e design

A arquitetura de vários clusters do GKE desempenha um papel na seleção de uma estratégia de gestão do ciclo de vida do cluster. Antes de abordar estas estratégias, é importante abordar determinadas decisões de design que podem afetar ou ser afetadas pela estratégia de gestão do ciclo de vida do cluster.

Tipo de clusters

Se estiver a usar a atualização automática do GKE como uma estratégia de gestão do ciclo de vida do cluster, o tipo de cluster pode ser importante. Por exemplo, os clusters regionais têm vários nós do painel de controlo, em que os nós do painel de controlo são atualizados automaticamente um de cada vez, enquanto os clusters zonais têm um único nó do painel de controlo. Se não estiver a usar a atualização automática do GKE e considerar todos os clusters do Kubernetes como infraestrutura descartável, o tipo de cluster que escolher pode não ser importante quando decidir sobre uma estratégia de gestão do ciclo de vida do cluster. Pode aplicar as estratégias abordadas na secção seguinte, Gestão do ciclo de vida de vários clusters do GKE, a qualquer tipo de cluster.

Posicionamento e pegada do cluster

Considere os seguintes fatores quando decidir o posicionamento e a área de cobertura do cluster:

• Zonas e regiões em que os clusters têm de estar.
• Número e tamanho dos clusters necessários.

Normalmente, é fácil resolver o primeiro fator, uma vez que as zonas e as regiões são determinadas pela sua empresa e pelas regiões onde presta serviços aos utilizadores.

A abordagem ao número e ao tamanho dos clusters enquadra-se normalmente nas seguintes categorias, cada uma com vantagens e desvantagens:

• Número reduzido de grandes clusters. Pode optar por usar a redundância e a resiliência fornecidas pelos clusters regionais e colocar um (ou dois) clusters regionais grandes por região. A vantagem desta abordagem é a redução dos custos operacionais da gestão de vários clusters. A desvantagem é que pode afetar um grande número de serviços em simultâneo devido à sua grande área de impacto.
• Grande número de pequenos clusters. Pode criar um grande número de pequenos clusters para reduzir a área de impacto do cluster, porque os seus serviços estão divididos em muitos clusters. Esta abordagem também funciona bem para clusters efémeros de curta duração (por exemplo, clusters que executam uma carga de trabalho em lote). A desvantagem desta abordagem é a maior sobrecarga operacional, uma vez que existem mais clusters para atualizar. Também podem existir custos adicionais associados a um número mais elevado de nós do plano de controlo. Pode compensar os custos e os elevados custos gerais operacionais com a automatização, uma estratégia e um horário previsíveis, e uma coordenação cuidadosa entre as equipas e os serviços afetados.

Este documento não recomenda uma abordagem em detrimento da outra. São opções. Em alguns casos, pode escolher ambos os padrões de design para diferentes categorias de serviços.

As seguintes estratégias funcionam com qualquer uma das opções de design.

Planeamento de capacidade

Ao planear a capacidade, é importante ter em conta a estratégia de ciclo de vida do cluster escolhida. O planeamento de capacidade tem de considerar os seguintes eventos normais de carga e manutenção do serviço:

• Eventos planeados, como atualizações de clusters
• Eventos não planeados, como falhas de clusters, por exemplo, implementações incorretas e implementações de reversão incorretas

Ao planear a capacidade, tem de considerar as indisponibilidades totais ou parciais. Se criar o design apenas para eventos de manutenção planeados, todos os serviços distribuídos têm de ter um cluster adicional ao necessário para que possa retirar um cluster da rotação de cada vez para atualizações sem degradar o serviço. Esta abordagem também é designada planeamento de capacidade de N+1. Se criar o design para eventos de manutenção planeados e não planeados, todos os serviços distribuídos têm de ter dois (ou mais) clusters adicionais do que os necessários para disponibilizar a capacidade pretendida: um para o evento planeado e outro para um evento não planeado, caso ocorra durante o período de manutenção planeado. Esta abordagem também é conhecida como planeamento de capacidade N+2.

Em arquiteturas com vários clusters, os termos drenar e transbordar são usados com frequência. Estes termos referem-se ao processo de remoção (ou esgotamento) do tráfego de um cluster e de redirecionamento (ou derrame) do tráfego para outros clusters durante atualizações e eventos de manutenção. Este processo é realizado através de soluções de rede, como o Ingress de vários clusters ou outros métodos de equilíbrio de carga. A utilização cuidadosa da drenagem e do derrame está no centro de algumas estratégias de gestão do ciclo de vida dos clusters. Quando planear a capacidade, tem de considerar a drenagem e o derrame. Por exemplo, quando um único cluster é esvaziado, tem de considerar se os outros clusters têm capacidade suficiente para processar o tráfego adicional derramado. Outras considerações incluem capacidade suficiente na zona ou região, ou a necessidade de enviar tráfego para uma região diferente (se usar um único cluster regional por região). O diagrama seguinte mostra o tráfego a ser removido (por vezes, denominado esgotamento de um cluster) de um cluster e enviado para outro cluster que executa o mesmo serviço distribuído.

Clusters e serviços distribuídos

O design de cluster baseado em serviços determina que a arquitetura de cluster (número, tamanho e localização) é determinada pelos serviços necessários para serem executados nos clusters. Por conseguinte, o posicionamento dos seus clusters é determinado pelo local onde os serviços distribuídos são necessários. Considere o seguinte ao decidir o posicionamento dos serviços distribuídos:

• Requisito de localização. Em que regiões tem de ser fornecido o serviço?
• Criticidade. Qual a importância da disponibilidade de um serviço para a empresa?
• SLO. Quais são os objetivos ao nível do serviço para o serviço (normalmente com base na criticidade)?
• Resiliência. Qual é o nível de resiliência que o serviço tem de ter? Precisa de resistir a falhas de clusters, zonais ou até regionais?

Ao planear atualizações de clusters, tem de considerar o número de serviços que um único cluster afeta quando é esvaziado e tem de ter em conta o transbordo de cada um destes serviços para outros clusters adequados. Os clusters podem ser de inquilino único ou multi-inquilino. Os clusters de inquilino único publicam apenas um único serviço ou um produto representado por um conjunto de serviços. Os clusters de inquilino único não partilham o cluster com outros serviços ou produtos. Os clusters multi-inquilinos podem executar muitos serviços e produtos que são normalmente divididos em espaços de nomes.

Impacto nas equipas

Um evento de cluster não afeta apenas os serviços, mas também pode afetar as equipas. Por exemplo, a equipa de DevOps pode ter de redirecionar ou interromper os respetivos pipelines de CI/CD durante uma atualização do cluster. Da mesma forma, as equipas de apoio técnico podem receber alertas sobre interrupções planeadas. A automatização e as ferramentas têm de estar implementadas para ajudar a reduzir o impacto em várias equipas. Uma atualização de um cluster ou de uma frota de clusters deve ser considerada rotineira e sem incidentes quando todas as equipas são informadas.

Tempo, agendamento e coordenação

O Kubernetes lança uma nova versão secundária trimestralmente e mantém os últimos três lançamentos. Tem de planear cuidadosamente a hora e o agendamento das atualizações de clusters. Tem de existir um acordo entre os proprietários dos serviços, os operadores dos serviços e os administradores da plataforma sobre quando estas atualizações ocorrem. Ao planear atualizações, considere as seguintes perguntas:

• Com que frequência faz atualizações? Atualiza o software todos os trimestres ou num cronograma diferente?
• Quando é que faz a atualização? Faz a atualização no início do trimestre quando a atividade empresarial abranda ou durante outros períodos de inatividade empresarial motivados pela sua indústria?
• Quando não deve fazer a atualização? Tem um planeamento claro sobre quando não fazer a atualização, por exemplo, evitar eventos de grande escala, como a Black Friday, a Cyber Monday ou durante conferências de alto perfil e outros eventos específicos da indústria.

É importante ter uma estratégia em vigor que seja comunicada claramente aos proprietários dos serviços, bem como às equipas de operações e apoio técnico. Não deve haver surpresas e todos devem saber quando e como os clusters são atualizados. Isto requer uma coordenação clara com todas as equipas envolvidas. Um único serviço tem várias equipas que interagem com ele. Normalmente, estas equipas podem ser agrupadas nas seguintes categorias:

• O programador de serviços, que é responsável pela criação e programação da lógica empresarial num serviço.
• O operador do serviço, que é responsável pela execução segura e fiável do serviço. Os operadores podem consistir em várias equipas, como o administrador de políticas ou de segurança, o administrador de rede e as equipas de apoio técnico.

Todos têm de estar em comunicação durante as atualizações de clusters para poderem tomar as ações adequadas durante este período. Uma abordagem consiste em planear as atualizações da mesma forma que planeia um incidente de indisponibilidade. Tem um responsável por incidentes, uma sala de chat e uma retrospetiva (mesmo que nenhum utilizador tenha sido afetado). Para mais informações, consulte Resposta a incidentes.

Estratégias de ciclo de vida do cluster do GKE

Esta secção aborda as principais estratégias de gestão do ciclo de vida do cluster usadas frequentemente na arquitetura de vários clusters do GKE. É importante ter em atenção que uma estratégia não funciona para todos os cenários e pode escolher várias estratégias para várias categorias de serviços e necessidades da empresa.

Atualizações contínuas

O diagrama seguinte mostra a estratégia de atualização contínua.

Usando um balanceador de carga, um cluster do GKE é esvaziado de todo o tráfego e atualizado. A carga de tráfego esgotada é transferida para um cluster do GKE diferente.

As atualizações contínuas são a estratégia mais simples e económica entre as estratégias abordadas neste documento. Começa com n clusters a executar a versão old_ver (ou de produção atual). Em seguida, esvazia os clusters m de cada vez, em que m é inferior a n. Em seguida, elimina e recria novos clusters com a nova versão ou atualiza os clusters esgotados.

A decisão entre eliminar e atualizar novos clusters depende do tamanho dos clusters, bem como se considera que os clusters são uma infraestrutura imutável. A infraestrutura imutável determina que, em vez de atualizar constantemente um cluster, o que pode produzir resultados indesejados ao longo do tempo, deve criar novos clusters e evitar qualquer desvio de configuração imprevisto.

Se usar o GKE, pode criar um cluster do GKE com um único comando ou uma chamada de API. A nova estratégia de cluster requer que tenha a configuração completa do cluster (manifestos do cluster) armazenada fora do cluster, normalmente no Git. Em seguida, pode usar o mesmo modelo de configuração no novo cluster. Se este for um novo cluster, certifique-se de que os pipelines de CI/CD estão a apontar para o cluster correto. Depois de o cluster estar configurado corretamente, pode enviar tráfego de volta para o cluster lentamente enquanto monitoriza os SLOs dos serviços.

O processo é repetido para todos os clusters. Consoante o planeamento da capacidade, pode atualizar vários clusters em simultâneo sem violar os SLOs de serviço.

Se valoriza a simplicidade e o custo em detrimento da resiliência, use a estratégia de atualizações contínuas. Durante esta estratégia, nunca excede a capacidade necessária da frota do GKE para todos os serviços distribuídos.

O diagrama seguinte compara a cronologia e o requisito de capacidade do serviço durante uma atualização do cluster do GKE numa arquitetura de vários clusters.

O diagrama anterior mostra que, ao longo do processo de atualização do GKE, a capacidade de suportar os serviços nunca fica abaixo do que é necessário. Quando o cluster do GKE a ser atualizado é retirado da rotação, os outros clusters são dimensionados para suportar a carga.

Atualizações azul/verde

O diagrama seguinte mostra uma estratégia de atualização azul/verde.

No diagrama anterior, é adicionado um novo cluster do GKE que executa a nova versão. Em seguida, é usado um balanceador de carga para enviar tráfego para o novo cluster enquanto esgota lentamente um dos clusters antigos até que nenhum tráfego seja enviado para o mesmo. Em seguida, pode remover o cluster antigo totalmente esgotado. Pode seguir o mesmo processo para os restantes clusters.

A estratégia de atualização azul/verde oferece alguma resiliência adicional. Esta estratégia é semelhante às atualizações contínuas, mas é mais dispendiosa. A única diferença é que, em vez de esgotar primeiro os clusters existentes, cria novos clusters m com a versão primeiro, em que m é inferior ou igual a n. Adiciona os novos clusters aos pipelines de CI/CD e, em seguida, transfere lentamente o tráfego enquanto monitoriza os SLOs de serviço. Quando os novos clusters estiverem a receber tráfego na totalidade, esvazie e elimine os clusters com a versão mais antiga.

A estratégia azul/verde para atualizar clusters é semelhante a uma estratégia azul/verde normalmente usada para serviços. A criação de vários novos clusters de uma só vez aumenta o custo geral, mas oferece a vantagem de acelerar o tempo de atualização da frota. O custo adicional aplica-se apenas durante a atualização quando são usados clusters adicionais. A vantagem de criar primeiro novos clusters é que, em caso de falha, pode reverter a ação. Também pode testar o novo cluster antes de lhe enviar tráfego de produção. Uma vez que estes clusters coexistem com as respetivas contrapartes da versão antiga durante um pequeno período, os custos adicionais são mínimos.

Se valorizar a simplicidade e a resiliência em detrimento do custo, use a estratégia de atualização azul/verde. Primeiro, são adicionados clusters adicionais que excedem a capacidade necessária da frota do GKE durante as atualizações.

No diagrama anterior, a adição de um novo cluster aumenta temporariamente a capacidade disponível acima da capacidade necessária enquanto outro cluster na frota é esgotado e removido da frota. No entanto, depois de remover um dos clusters antigos (totalmente esgotados), a capacidade volta ao que é necessário. Esta alteração da capacidade é realçada porque pode haver um aumento no custo com este modelo, consoante o número e o tamanho dos clusters na frota.

Atualizações de clusters Canary

A atualização de um cluster canary é a estratégia mais resiliente e complexa das que são abordadas neste documento. Esta estratégia abstrai completamente a gestão do ciclo de vida do cluster da gestão do ciclo de vida dos serviços, oferecendo assim o risco mais baixo e a resiliência mais elevada para os seus serviços. Nas estratégias de atualização contínua e azul/verde anteriores, mantém toda a sua frota do GKE numa única versão. Nesta estratégia, mantém duas ou talvez três frotas de clusters do GKE que estão a executar versões diferentes. Em vez de atualizar os clusters, migra os serviços de uma frota de clusters para a outra ao longo do tempo. Quando o dispositivo do GKE mais antigo é esvaziado (o que significa que todos os serviços foram migrados para o dispositivo do GKE com a versão seguinte), elimina o dispositivo.

Esta estratégia requer que mantenha um mínimo de duas frotas do GKE: uma para a produção atual e outra para a versão candidata à produção seguinte. Também pode manter mais de duas frotas do GKE. As frotas adicionais oferecem-lhe mais flexibilidade, mas os custos e os encargos operacionais também aumentam. Estas frotas adicionais não são o mesmo que ter clusters em ambientes diferentes, por exemplo, ambientes de desenvolvimento, teste e produção. Os ambientes de não produção são ideais para testar as funcionalidades e os serviços do Kubernetes com tráfego de não produção.

Esta estratégia de utilização de atualizações de clusters canary determina que mantenha várias versões da frota do GKE no ambiente de produção. Isto é semelhante às estratégias de lançamento canário que são frequentemente usadas pelos serviços. Com as implementações de serviços canary, o proprietário do serviço pode sempre identificar problemas numa versão específica do serviço. Com os clusters canários, o proprietário do serviço também tem de ter em conta as versões da frota do GKE em que os respetivos serviços estão a ser executados. Uma única versão de serviço distribuída pode ser executada em várias versões da frota do GKE. A migração de um serviço pode ocorrer gradualmente para que possa ver os efeitos do serviço na nova frota antes de enviar todo o tráfego do serviço para os novos clusters com versões.

O diagrama seguinte mostra que a gestão de diferentes frotas de clusters do GKE pode abstrair completamente o ciclo de vida do cluster do ciclo de vida dos serviços.

O diagrama anterior mostra um serviço distribuído frontend a ser migrado lentamente de uma frota de clusters do GKE para a frota seguinte que executa a nova versão até que a frota mais antiga seja completamente esvaziada ao longo do tempo. Depois de esgotar a frota, pode removê-la e criar uma nova. Todos os serviços são migrados para a frota seguinte, removendo as frotas mais antigas à medida que são esgotadas.

Se valoriza a resiliência acima de tudo, use a estratégia de atualização de cluster canary.

Escolha uma estratégia de atualização

O diagrama seguinte pode ajudar a determinar a melhor estratégia para si com base no serviço e nas necessidades da empresa.

O diagrama anterior é uma árvore de decisão para ajudar a escolher a estratégia de atualização adequada para si:

• Se não precisar de controlo total sobre a versão exata e a hora da atualização, pode escolher a funcionalidade de atualização automática disponível no GKE.
• Se a sua prioridade for o baixo custo, pode escolher a estratégia de atualização contínua.
• Se a sua prioridade for equilibrar o custo e a resiliência, pode escolher a estratégia azul/verde.
• Se a sua prioridade for a resiliência em vez do custo, pode escolher a estratégia de atualização do cluster canary.

Usar a entrada em vários clusters para a gestão do ciclo de vida do cluster do GKE

Quase todas as estratégias dependem da capacidade de drenar e reencaminhar o tráfego para outros clusters durante as atualizações. Uma solução que oferece esta capacidade de entrada em vários clusters é a entrada em vários clusters. A entrada em vários clusters é um controlador de entrada em vários clusters alojado pela Google para clusters do GKE que suporta a implementação de recursos de equilíbrio de carga partilhados em clusters e regiões. Google CloudA entrada em vários clusters é uma solução para direcionar o tráfego de clientes para um serviço distribuído executado em vários clusters em várias regiões. Tal como o Ingress para o GKE, usa o Cloud Load Balancing para enviar tráfego para um serviço de back-end. O serviço de back-end é o serviço distribuído. O serviço de back-end envia tráfego para vários back-ends, que são serviços do Kubernetes executados em vários clusters do GKE. Para o tráfego de serviço para serviço entre clusters, pode usar tecnologias de malha de serviços, como a malha de serviços do Google Cloud ou o Istio, que oferecem funcionalidades semelhantes em serviços distribuídos.

Para ambientes com vários clusters do GKE, pode usar a entrada em vários clusters para manipular o tráfego para vários clusters para as estratégias de gestão do ciclo de vida do cluster abordadas anteriormente. Pode seguir um tutorial para usar o Multi Cluster Ingress para atualizações do GKE através da estratégia azul-verde.

O que se segue?

• Saiba mais sobre o Multi Cluster Ingress.
• Saiba como implementar o Multi Cluster Ingress em vários clusters.