Neste documento, descrevemos como projetar, planejar e implementar upgrades em um ambiente do Google Kubernetes Engine (GKE) com vários clusters. Embora usemos neste documento a Entrada de vários clusters para fazer upgrades, os conceitos podem ser aplicados a outras soluções, por exemplo, configurando manualmente um balanceador de carga externo. Há um tutorial complementar a este documento que mostra como fazer upgrade de um ambiente GKE de vários clusters com a Entrada de vários clusters. Este documento destina-se a administradores do Google Cloud responsáveis por manter frotas para clusters do GKE.
Necessidade de arquitetura com vários clusters
Nesta seção, abordamos vários motivos pelos quais você pode precisar de uma arquitetura do Kubernetes de vários clusters.
Kubernetes como infraestrutura
Neste documento, os clusters do Kubernetes são componentes de infraestrutura. A infraestrutura é descartável. Nenhum tratamento especial precisa ser dado a qualquer componente da infraestrutura porque os componentes existem para atender a uma finalidade. O objetivo do Kubernetes é oferecer automação e orquestração aos desenvolvedores e operadores para oferecer aplicativos e serviços baseados em contêineres aos consumidores. Os consumidores podem ser equipes internas, outros serviços ou clientes externos.
Cenários comuns de vários clusters
Além do argumento do Kubernetes como infraestrutura, há vários motivos para se ter um ambiente de vários clusters:
- Geografia. Muitos serviços precisam estar em várias regiões. Colocar um serviço mais próximo do consumidor (na região dele) proporciona uma experiência melhor devido à latência mais baixa do que se o serviço for disponibilizado a partir de uma única região. Um cluster do Kubernetes é executado em uma única região. Para implantações multirregionais, é necessário ter vários clusters do Kubernetes em várias regiões. Ambientes de nuvem híbrida ou de várias nuvens também exigem vários clusters em cada ambiente. Os clusters do Kubernetes geralmente também estão localizados com as fontes de dados dos serviços (com estado). Alguns aplicativos podem precisar estar no mesmo local (região e zona) do back-end, por exemplo, um sistema de gerenciamento de banco de dados relacional (RDBMS, na sigla em inglês).
- Locação e ambientes. Os clusters do Kubernetes foram projetados para multilocação. Várias equipes podem compartilhar um único cluster para os respectivos serviços. O Kubernetes fornece recursos padrão, como namespaces, controle de acesso baseado em papéis (RBAC, na sigla em inglês), políticas de rede e autenticação, para configurar corretamente os controles de acesso em ambientes multilocatários. Em alguns casos, determinados serviços podem não conseguir coresidir em um cluster com outros Serviços devido à política da empresa, à privacidade, à segurança ou à regulamentação do setor. Nesses casos, são necessários vários clusters para separar determinados locatários nos próprios clusters. Ambientes (desenvolvimento, preparação e produção) também são frequentemente criados como clusters separados. O escopo de acesso e os tipos de aplicativos instalados em diferentes ambientes variam bastante e precisam ser mantidos como clusters separados.
- Composição e função. Às vezes, um cluster é criado para executar uma função específica. Por exemplo, fluxos de trabalho de machine learning usam Kubeflow ou jobs de análise de dados que podem exigir nós com GPUs ou outros requisitos de hardware para clusters de instâncias formados por Spot VMs para fins de cargas de trabalho de análise em lote. Esses requisitos de hardware podem não se aplicar a outros Serviços. Esses fluxos de trabalho podem não ser essenciais para administrar a empresa e podem exigir clusters efêmeros (clusters de curta duração). Os serviços compartilhados, como de observação (geração de registros, métricas e traces) e ferramentas de CI/CD, são mais adequados no próprio cluster de administração da plataforma. Clusters separados específicos de funções geralmente são vistos para fluxos de trabalho críticos não empresariais.
- Resiliência. Vários clusters costumam ser usados para aumentar a resiliência em um ambiente. Cada cluster tem uma área de impacto. Nesse contexto, uma área de impacto é o número de serviços afetados negativamente por uma falha de configuração ou funcionamento inadequado do cluster, um erro de configuração ou um cluster que está off-line devido à manutenção planejada ou não planejada. Se você tiver um grande número de clusters menores, terá um grande número de áreas de impacto menores. Se houver um serviço em dois clusters, os clusters compartilham a carga igualmente. Se um cluster ficar off-line, 50% do tráfego será afetado. Se o mesmo Serviço for disponibilizado por um único cluster, qualquer evento nesse cluster causa 100% de interrupção para esse serviço. Por esse motivo, vários clusters também são frequentemente usados para recuperação de desastres.
Neste documento, o foco é o aspecto de resiliência de implantações de vários clusters.
Serviços distribuídos e de vários clusters
Um serviço distribuído é um serviço do Kubernetes implantado em vários clusters do Kubernetes. Os serviços distribuídos são serviços sem estado e atuam de maneira idêntica em vários clusters. Isso significa que um serviço distribuído tem o mesmo nome de serviço do Kubernetes e é implementado no mesmo namespace em vários clusters. Os serviços do Kubernetes estão vinculados ao cluster do Kubernetes em que são executados. Se um cluster do Kubernetes ficar off-line, o serviço do Kubernetes também ficará. 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 poderá ficar on-line e dentro do objetivo de nível de serviço (SLO, na sigla em inglês).
No diagrama a seguir, frontend é um serviço distribuído em execução em
vários clusters com o mesmo nome de serviço e namespace.
Com essa arquitetura, o serviço frontend não está vinculado a um único cluster
e é representado conceitualmente no diagrama como uma camada que abrange a
camada de infraestrutura do cluster do Kubernetes. Se algum dos clusters individuais que
estiverem executando o serviço frontend ficar inativo, o frontend permanecerá on-line.
Há mais serviços em execução em clusters individuais: Serviço
accounts e Serviço ledger. O tempo de atividade e a disponibilidade dependem do
tempo de atividade do cluster do Kubernetes em que residem.
A resiliência é uma das razões para as implantações de vários clusters. Os serviços distribuídos criam serviços resilientes em uma arquitetura de vários clusters. Os serviços sem estado são os principais candidatos para serviços distribuídos em um ambiente de vários clusters. Os requisitos e considerações a seguir se aplicam ao trabalhar com serviços distribuídos:
Rede de vários clusters. É possível enviar o tráfego destinado a um serviço distribuído aos clusters que estão executando esse serviço usando uma tecnologia de entrada de vários clusters, como Entrada de vários clusters, ou usando seu próprio balanceador de carga externo ou solução de proxy. Independentemente da opção usada, ela precisa fornecer controle sobre quando, onde e quanto tráfego é roteado para uma instância específica de um serviço distribuído. O diagrama a seguir mostra um balanceador de carga que envia tráfego para um serviço distribuído
frontendem execução em dois clusters do GKE.
Observabilidade. Use ferramentas para medir seus SLOs, normalmente disponibilidade e latência, coletivamente para um serviço distribuído. Essa configuração fornece uma visão global do desempenho de cada serviço em vários clusters. O Serviço distribuído não é um recurso bem definido na maioria das soluções de observabilidade, mas é possível coletar e combinar métricas individuais do serviço do Kubernetes. Soluções como o Cloud Monitoring ou ferramentas de código aberto como o Grafana fornecem métricas do serviço do Kubernetes. As soluções de malha de serviço, como Istio e Anthos Service Mesh, também fornecem métricas de serviço sem nenhuma instrumentação necessária.
Posicionamento do serviço. Os serviços do Kubernetes oferecem uma tolerância a falhas no nível do nó em um único cluster do Kubernetes. Isso significa que um serviço do Kubernetes pode suportar falhas de nó. Durante as falhas do nó, um nó do plano de controle do Kubernetes reprograma automaticamente os pods para nós íntegros. Um serviço distribuído fornece tolerância a falhas no nível do cluster. Isso significa que um serviço distribuído pode suportar falhas de cluster. Ao planejar a capacidade de um serviço distribuído, considere este posicionamento de serviço. Um serviço distribuído não precisa ser executado em cada cluster. Os clusters em que um serviço distribuído é executado depende dos seguintes requisitos:
- Onde ou em quais regiões o Serviço é necessário?
- Qual é o SLO necessário para o Serviço distribuído?
- Que tipo de tolerância a falhas é necessário para o serviço distribuído (cluster, zonal ou regional?) Por exemplo, você precisa de vários clusters em uma única zona ou vários clusters em zonas em uma única região ou várias regiões?
Qual nível de interrupções o serviço distribuído deverá suportar no pior cenário? As seguintes opções estão disponíveis na camada do cluster:
- N+1 (em que N representa o número de clusters necessários para atender às necessidades de capacidade do serviço). Um serviço distribuído pode suportar uma única falha de cluster.
- N+2. Um serviço distribuído pode suportar duas falhas simultâneas. Por exemplo, uma interrupção planejada e não planejada de um serviço do Kubernetes em dois clusters ao mesmo tempo.
Lançamentos e reversão. Serviços distribuídos, como os Serviços do Kubernetes, permitem lançamentos 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 implantação como meio de alteração gradual. Os lançamentos e reversões também dependem do requisito de serviço. Em alguns casos, pode ser necessário fazer upgrade do serviço em todos os clusters ao mesmo tempo, por exemplo, uma correção de bug. Em outros casos, pode ser necessário lançar (ou distribuir) lentamente a alteração em um cluster por vez. Esse lançamento gradual reduz o risco para o serviço distribuído introduzindo gradualmente alterações ao serviço. No entanto, isso pode levar mais tempo, dependendo do número de clusters. Nenhuma estratégia de upgrade é a melhor opção. Muitas vezes, várias estratégias de lançamento e reversão são usadas dependendo dos requisitos de serviço distribuído. O ponto importante aqui é que os serviços distribuídos precisam permitir alterações graduais e controladas no ambiente.
Continuidade dos negócios e recuperação de desastres (BCDR, na sigla em inglês). Esses termos são frequentemente usados juntos. A continuidade dos negócios se refere à continuação de serviços essenciais no caso de um evento grande (planejado ou não planejado), enquanto a recuperação de desastres se refere às etapas executadas ou necessárias para retornar as operações comerciais ao estado normal após esses eventos. Há muitas estratégias para o BCDR que estão além do escopo deste documento. O BCDR requer certo nível de redundância em sistemas e serviços. A principal premissa dos serviços distribuídos é que eles são executados em vários locais (clusters, zonas e regiões).
As estratégias de BCDR geralmente dependem das estratégias mencionadas anteriormente de lançamento e de reversão. Por exemplo, se os lançamentos forem realizados de maneira escalonada ou controlada, o efeito de um bug ou de um push de configuração ruim poderá ser detectado rapidamente sem afetar um grande número de usuários. Em grande escala e junto com uma rápida taxa de alteração (por exemplo, nas práticas modernas de CI/CD), é comum que nem todos os usuários recebam a mesma versão de um serviço distribuído. O planejamento e as estratégias de BCDR em sistemas e serviços distribuídos são diferentes das arquiteturas monolíticas tradicionais. Nos sistemas tradicionais, uma mudança é feita em grande escala, o que afeta muitos, ou talvez todos, usuários. Portanto, ela precisa ter um sistema redundante ou de backup no lugar em caso de efeitos indesejados de um lançamento. Em sistemas e serviços distribuídos, quase todas as alterações são feitas de maneira gradual para afetar apenas um pequeno número de usuários.
Gerenciamento do ciclo de vida do cluster. Assim como lançamentos e reversões, os Serviços distribuídos permitem o gerenciamento do ciclo de vida do cluster controlado. Os serviços distribuídos oferecem resiliência no nível do cluster, para que os clusters possam ser retirados da rotação para manutenção. O gerenciamento do ciclo de vida do cluster é um princípio de serviços distribuídos que não se aplica aos serviços do Kubernetes.
O restante deste documento se concentra no aspecto do ciclo de vida do cluster dos serviços distribuídos.
Gerenciamento do ciclo de vida do cluster do GKE
O gerenciamento do ciclo de vida do cluster pode ser definido como as estratégias e o planejamento necessários para manter uma frota íntegra e atualizada dos clusters do Kubernetes sem violar os SLOs de serviço. Com estratégias e planejamento adequados, o gerenciamento do ciclo de vida do cluster precisa ser uma rotina, esperada e sem incidentes.
Este documento se concentra no gerenciamento do ciclo de vida do GKE. No entanto, é possível aplicar esses conceitos a outras distribuições do Kubernetes.
Controle de versão e upgrades do GKE
Antes de discutir as estratégias e planejar o gerenciamento do ciclo de vida do cluster, é importante entender o que constitui um upgrade do cluster.
Um cluster tem dois componentes: nós de plano de controle e nós de trabalho. Para
fazer um upgrade de cluster do Kubernetes, é necessário que todos os nós sejam atualizados para a mesma
versão. O Kubernetes segue um
esquema de controle de versão semântico.
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
menores ocorrem aproximadamente a cada
três meses (trimestral), e o projeto do Kubernetes mantém ramificações de versão
para as três versões secundárias mais recentes. Isso significa que uma versão secundária de nove meses
do Kubernetes não é mais mantida e pode exigir alterações na API
quando você fizer o upgrade para a versão mais recente. Os upgrades
do Kubernetes precisam ser planejados em uma frequência regular. Recomendamos fazer upgrades
planejados do GKE trimestralmente ou a cada dois trimestres.
Os clusters do GKE aceitam a execução de versões do Kubernetes a partir de qualquer versão secundária compatível. Pelo menos duas versões secundárias estão disponíveis a qualquer momento.
O GKE tem os seguintes tipos de disponibilidade de cluster:
- Clusters de zona única. Um único nó do plano de controle ,e todos os pools de nós estão em uma única zona em uma única região.
- Clusters com várias zonas. Um único nó do plano de controle está em uma zona e os pools de nós estão em várias zonas em uma única região.
- Clusters regionais. Vários nós do plano de controle e pools de nós em várias zonas em uma única região.
O GKE é um serviço gerenciado e oferece upgrades automáticos para ambos nós do plano de controle e nós de trabalho.
Upgrade automático do GKE
O upgrade automático do GKE é uma estratégia de ciclo de vida de cluster muito usada e popular. O upgrade automático do GKE fornece uma maneira totalmente gerenciada de manter seus clusters do GKE atualizados para versões compatíveis. O GKE faz o upgrade automático dos nós do plano de controle e dos nós de trabalho separadamente:
Upgrades automáticos do mestre. Por padrão, os nós do plano de controle do GKE recebem upgrade automaticamente. Os clusters de zona única e de várias zonas têm um único plano de controle (nó do plano de controle). Durante os upgrades de nó do plano de controle, as cargas de trabalho continuam em execução. No entanto, não é possível implantar novas cargas de trabalho, modificar as atuais ou fazer outras alterações na configuração do cluster até que o upgrade seja concluído.
Os clusters regionais têm várias réplicas do plano de controle e apenas uma é atualizada por vez. Durante o upgrade, o cluster permanece altamente disponível, e cada réplica do plano de controle fica indisponível apenas durante a atualização.
Upgrades automáticos de nós de trabalho. Os pools de nós são atualizados um de cada vez. Em um pool de nós, os nós são atualizados individualmente, em uma ordem indefinida. É possível alterar o número de nós que são atualizados por vez, mas esse processo pode levar muitas horas dependendo do número de nós e das configurações de carga de trabalho deles.
Estratégia de ciclo de vida do upgrade automático do GKE
Recomendamos o uso do upgrade automático do GKE sempre que possível. Os upgrades automáticos do GKE priorizam a conveniência ao controle. No entanto, os upgrades automáticos do GKE oferecem várias maneiras de influenciar quando e como seus clusters são atualizados dentro de determinados parâmetros. É possível influenciar as janelas de manutenção e as exclusões de manutenção. Os canais de lançamento influenciam a seleção de versão e as estratégias de upgrade de pools de nós influenciam a ordem e o tempo dos upgrades de nós. Apesar desses controles e clusters regionais (com vários planos de controle do Kubernetes), o upgrade automático do GKE não garante o tempo de atividade dos serviços. É possível optar por não usar o recurso de upgrade automático do GKE se você precisar de um ou mais dos seguintes itens:
- Controle da versão exata dos clusters do GKE.
- Controle do momento exato para fazer upgrade do GKE.
- Controle da estratégia de upgrade (discutida na próxima seção) para sua frota do GKE.
Gerenciamento do ciclo de vida de vários clusters do GKE
Nesta seção, descrevemos várias estratégias de gerenciamento do ciclo de vida de vários clusters do GKE e como planejar cada uma delas.
Considerações de planejamento e design
A arquitetura de vários clusters do GKE desempenha um papel na seleção de uma estratégia de gerenciamento do ciclo de vida do cluster. Antes de discutir essas estratégias, é importante discutir determinadas decisões de design que podem afetar ou ser afetadas pela estratégia de gerenciamento do ciclo de vida do cluster.
Tipo de clusters
Se você estiver usando o upgrade automático do GKE como uma estratégia de gerenciamento do ciclo de vida do cluster, o tipo de cluster poderá ser importante. Por exemplo, os clusters regionais têm vários nós do plano de controle em que os nós do plano de controle são automaticamente atualizados um de cada vez, enquanto os clusters zonais têm um único nó do plano de controle. Se você não estiver usando o upgrade automático do GKE e considerar todos os clusters do Kubernetes como infraestrutura descartável, pode ser que não importa o tipo de cluster que você escolhe ao escolher uma estratégia de gerenciamento do ciclo de vida do cluster. É possível aplicar as estratégias discutidas na próxima seção, gerenciamento de ciclo de vida de vários clusters do GKE, a qualquer tipo de cluster.
Posicionamento e abrangência de cluster
Considere os seguintes fatores ao decidir sobre o posicionamento e abrangência do cluster:
- Zonas e regiões em que os clusters precisam estar.
- Número e tamanho dos clusters necessários.
O primeiro fator costuma ser fácil de resolver porque as zonas e regiões são ditas pela empresa e pelas regiões em que você atende aos usuários.
Solucionar o número e o tamanho dos clusters normalmente se enquadra nas categorias a seguir, cada um com vantagens e desvantagens:
- Número pequeno de clusters grandes. Escolha a redundância e a resiliência fornecidas por clusters regionais e coloque um, ou dois, grandes clusters regionais por região. O benefício dessa abordagem é a baixa sobrecarga operacional do gerenciamento de vários clusters. O lado negativo é que isso pode afetar um grande número de serviços de uma só vez devido à grande área de impacto.
- Grande número de clusters pequenos. É possível criar um grande número de clusters pequenos para reduzir a área de impacto do cluster porque seus serviços são divididos em vários clusters. Essa 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 dessa abordagem é a sobrecarga operacional maior, porque há mais clusters para fazer upgrade. Também pode haver custos extras associados a um número maior de nós do plano de controle. É possível compensar os custos e a sobrecarga de operação com a automação, programação e estratégia previsíveis e coordenação cuidadosa entre as equipes e os serviços afetados.
Este documento não recomenda uma abordagem em vez da outra, elas são opções. Em alguns casos, é possível escolher ambos os padrões de design para diferentes categorias de serviços.
As estratégias a seguir funcionam com qualquer uma das opções de design.
Planejamento de capacidade
Ao planejar a capacidade, é importante considerar a estratégia de ciclo de vida do cluster escolhida. O planejamento de capacidade precisa considerar os seguintes eventos normais de carga e manutenção de serviço:
- Eventos planejados, como upgrades de cluster
- Eventos não planejados, como interrupções de cluster, por exemplo, configuração de push ruim e lançamentos ruins
Ao planejar a capacidade, você precisa considerar as interrupções totais ou parciais. Se você projetar somente para eventos de manutenção planejadas, todos os Serviços distribuídos precisarão ter um cluster extra do que o necessário para que seja possível tirar um cluster de rotação por vez para upgrades sem prejudicar o serviço. Essa abordagem também é chamada de planejamento de capacidade de N+1. Se você projetar para eventos de manutenção planejados e não planejados, todos os serviços distribuídos precisarão ter dois ou mais clusters adicionais do que o necessário para atender à capacidade pretendida: um para o evento planejado e outro para um evento não planejado caso isso ocorra durante a janela de manutenção planejada. Essa abordagem também é conhecida como Planejamento de capacidade N+2.
Em arquiteturas de vários clusters, os termos drenagem e espalhamento são usados com frequência. Esses termos referem-se ao processo de remover (ou diminuir) o tráfego de um cluster e redirecionar (ou espalhar) tráfego para outros clusters durante upgrades e eventos de manutenção. Esse processo é realizado usando soluções de rede como o Ingress de vários clusters ou outros métodos de balanceamento de carga. O uso cuidadoso de drenagem e espalhamento é a base de algumas estratégias de gerenciamento do ciclo de vida do cluster. Ao planejar a capacidade, você precisa considerar a drenagem e o espalhamento. Por exemplo, quando um único cluster é reduzido, é preciso considerar se os outros clusters têm capacidade suficiente para lidar com o tráfego adicional espalhado. Outras considerações incluem capacidade suficiente na zona ou região ou necessidade de enviar tráfego para uma região diferente (se estiver usando um único cluster regional por região). No diagrama a seguir, veja o tráfego que está sendo removido (às vezes mencionado como drenagem de um cluster) de um cluster e enviado para outro cluster executando 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 local) é determinada pelos serviços necessários para serem executados nos clusters. Portanto, o posicionamento dos clusters é determinado de acordo com o local em que os serviços distribuídos são necessários. Considere o seguinte ao decidir o posicionamento dos serviços distribuídos:
- Requisito de local. Quais regiões precisam ser atendidas pelo Serviço?
- Necessidade. O quão necessária é a disponibilidade de um serviço para a empresa?
- SLO. Quais são os objetivos de nível de serviço para o serviço (geralmente com base na necessidade)?
- Resiliência. O quão resiliente o Serviço precisa ser? Ele precisa suportar falhas de cluster, zona ou até mesmo regionais?
Ao planejar upgrades de cluster, você precisa considerar o número de Serviços afetados por um único cluster quando ele for esvaziado e considerar espalhar cada um desses serviços em outros clusters apropriados. Os clusters podem ser de locatário único ou multilocatário. Os clusters de locatário único atendem apenas um Serviço ou um produto representado por um conjunto de Serviços. Os clusters de locatário único não compartilham o cluster com outros Serviços ou produtos. Os clusters multilocatários podem executar vários Serviços e produtos que normalmente são particionados em namespaces.
Impacto para as equipes
Um evento de cluster não apenas afeta os serviços, mas também pode afetar as equipes. Por exemplo, a equipe de DevOps pode precisar redirecionar ou interromper os pipelines de CI/CD durante um upgrade de cluster. Da mesma forma, as equipes de suporte podem receber alertas sobre interrupções planejadas. A automação e as ferramentas precisam estar em vigor para facilitar o impacto em várias equipes. Um cluster ou um upgrade de frota de cluster precisa ser considerado como rotina e sem incidentes quando todas as equipes forem informadas.
Agendamento, programação e coordenação
O Kubernetes lança uma nova versão secundária trimestralmente e mantém as últimas três versões. É preciso planejar cuidadosamente o agendamento e a programação de upgrades de cluster. É necessário haver um contrato entre os proprietários do serviço, os operadores de serviço e os administradores da plataforma quando esses upgrades forem realizados. Ao planejar upgrades, considere as seguintes perguntas:
- Com que frequência você faz upgrade? Você faz upgrade a cada trimestre ou em um cronograma diferente?
- Quando você faz upgrade? Você faz o upgrade no início do trimestre, quando a empresa diminui o ritmo ou durante outros períodos de inatividade da empresa impulsionados pelo setor?
- Quando você não deve fazer o upgrade? Você tem um planejamento claro de quando não fazer upgrade? Por exemplo, evitar eventos de grande escala, como Black Friday, Cyber Monday ou durante uma conferência de perfil de alto nível e outros eventos específicos do setor.
É importante ter uma estratégia em vigor que seja claramente comunicada aos proprietários do serviço, bem como às equipes de operações e suporte. Não haverá surpresas e todos saberão quando e como os clusters serão atualizados. Isso requer uma coordenação clara com todas as equipes envolvidas. Um único serviço tem várias equipes que interagem com ele. Normalmente, essas equipes podem ser agrupadas nas seguintes categorias:
- O desenvolvedor do serviço, que é responsável por criar e codificar a lógica de negócios em um serviço.
- O operador do Serviço, responsável por executar o Serviço com segurança e confiabilidade. Os operadores podem consistir em várias equipes, como administrador de política ou segurança, administrador de rede e equipes de suporte.
Todos os membros precisam estar em comunicação durante os upgrades do cluster para poder realizar ações adequadas durante esse período. Uma abordagem é planejar os upgrades da mesma maneira que você planeja um incidente de interrupção. Você tem um comando de incidentes, uma sala de bate-papo e uma retrospectiva, mesmo que nenhum usuário tenha sido afetado. Para mais informações, consulte Resposta a incidentes.
Estratégias de ciclo de vida do cluster do GKE
Nesta seção, discutiremos as principais estratégias de gerenciamento do ciclo de vida do cluster usadas com frequência na arquitetura de vários clusters do GKE. É importante observar que uma estratégia não funciona para todos os cenários e que você talvez escolha várias estratégias para várias categorias de serviços e necessidades da empresa.
Upgrades graduais
No diagrama a seguir, mostramos a estratégia de upgrade contínuo.
Usando um balanceador de carga, um cluster do GKE é drenado de todo o tráfego e atualizado. A carga de tráfego drenada é espalhada para um cluster diferente do GKE.
Os upgrades graduais são a estratégia mais simples e mais econômica das
estratégias discutidas neste documento. Você começa com n número de clusters
que executam a versão old_ver (ou produção atual). Em seguida, você drena m
clusters por vez, em que m é menor que n. Depois, exclua e recrie novos
clusters com a nova versão ou faça upgrade dos clusters drenados.
A decisão entre excluir e fazer upgrade de novos clusters depende do tamanho dos clusters e se você considera que eles são uma infraestrutura imutável. A infraestrutura imutável determina que, em vez de atualizar constantemente um cluster, que pode produzir resultados indesejados ao longo do tempo, você cria novos clusters e evita qualquer desvio de configuração imprevisto.
Se você usa o GKE, é possível criar um cluster do GKE com um único comando ou uma chamada de API. A nova estratégia de cluster requer que você tenha toda a configuração do cluster (manifestos de cluster) armazenados fora do cluster, geralmente no Git. Use o mesmo modelo de configuração no novo cluster. Se esse for um cluster novo, verifique se os pipelines de CI/CD estão direcionando para o cluster correto. Depois que o cluster estiver configurado corretamente, será possível enviar o tráfego de volta para o cluster lentamente enquanto monitora os SLOs dos serviços.
O processo é repetido para todos os clusters. Dependendo do seu planejamento de capacidade, é possível fazer upgrade de vários clusters por vez sem violar os SLOs dos serviços.
Se você valoriza mais a simplicidade e o custo do que a resiliência, use a estratégia de upgrades contínuos. Durante essa estratégia, você nunca ultrapassa a capacidade de frotas exigidas do GKE para todos os serviços distribuídos.
O diagrama a seguir compara o cronograma e o requisito de capacidade do serviço durante um upgrade de cluster do GKE em uma arquitetura de vários clusters.
No diagrama anterior, mostramos que, durante o processo de upgrade do GKE, a capacidade de oferecer suporte aos serviços nunca fica abaixo do que é necessário. Quando o cluster do GKE a ser atualizado for retirado da rotação, os outros clusters serão escalonados para suportar a carga.
Upgrades azuis/verdes
No diagrama a seguir, mostramos uma estratégia de upgrade azul/verde.
No diagrama anterior, um novo cluster do GKE executando a nova versão foi adicionado. Em seguida, um balanceador de carga é usado para enviar tráfego para o novo cluster e diminuir lentamente um dos clusters antigos até que nenhum tráfego seja enviado para ele. O cluster antigo totalmente drenado poderá ser removido. O mesmo processo pode ser seguido para os clusters restantes.
A estratégia de upgrade azul/verde oferece mais resiliência.
Essa estratégia é semelhante aos upgrades graduais, mas é mais cara. A única
diferença é que, em vez de drenar clusters existentes,
primeiro você cria novos clusters m com a versão, em que m é
menor ou igual a n. Adicione os novos clusters aos pipelines de CI/CD e
espalhe lentamente o tráfego enquanto monitora os SLOs de serviço. Quando os novos
clusters recebem todo o tráfego, você esvazia e exclui os clusters com a versão
mais antiga.
A estratégia azul/verde para fazer upgrade de clusters é semelhante a uma estratégia azul/verde normalmente usada para Serviços. A criação de vários novos clusters por vez aumenta o custo geral, mas oferece a vantagem de acelerar o tempo de upgrade da frota. O custo extra é apenas durante o upgrade quando outros clusters são usados. O benefício de criar novos clusters primeiro é que, no caso de uma falha, é possível reverter. Também é possível testar o novo cluster antes de enviar tráfego de produção para ele. Como esses clusters coexistem com suas contrapartes da versão antiga por um curto período, os custos extras são mínimos.
Se você valoriza mais a simplicidade e a resiliência do que o custo, use a estratégia de upgrade azul/verde. Outros clusters são adicionados primeiro e excedem a capacidade exigida da frota do GKE durante a realização dos upgrades.
No diagrama anterior, adicionar um novo cluster primeiro aumenta temporariamente a capacidade disponível em relação à capacidade necessária, enquanto outro cluster na frota é drenado e removido da frota. No entanto, depois de remover um dos clusters antigos (totalmente esvaziados), a capacidade volta ao que é necessário. Essa alteração de capacidade é destacada porque pode haver um aumento no custo com esse modelo, dependendo do número e do tamanho dos clusters na frota.
Upgrades de cluster Canary
Um upgrade do cluster Canary é a estratégia mais resiliente e complexa das discutidas neste documento. Essa estratégia abstrai completamente o gerenciamento do ciclo de vida do cluster do gerenciamento do ciclo de vida de serviços, oferecendo o menor risco e a maior resiliência para seus serviços. Nas estratégias anteriores de upgrade gradual e azul/verde, você mantém toda a sua frota do GKE em uma única versão. Nessa estratégia, você mantém duas ou três frotas de clusters do GKE que executam versões diferentes. Em vez de fazer upgrade dos clusters, você migra os Serviços de uma frota de clusters para a outra ao longo do tempo. Quando a frota mais antiga do GKE é esvaziada (ou seja, todos os serviços foram migrados para a próxima frota do GKE com versão), você exclui a frota.
Essa estratégia requer a manutenção de, pelo menos, duas frotas do GKE: uma para a produção atual e outra para a próxima versão candidata a produção. Também é possível manter mais de duas frotas do GKE. As frotas extras proporcionam mais flexibilidade, mas o custo e a sobrecarga operacional também aumentam. Essas frotas adicionais não são iguais aos clusters em ambientes diferentes, como os ambientes de desenvolvimento, preparação e produção, por exemplo. Ambientes de não produção são ótimos para testar os recursos e serviços do Kubernetes com tráfego de não produção.
Essa estratégia de uso dos upgrades de cluster canário determina que você mantenha várias versões de frotas do GKE no ambiente de produção. Isso é semelhante às estratégias de versão canário usadas com frequência pelos Serviços. Com implantações de serviço canário, o proprietário do serviço pode sempre identificar problemas em uma versão específica do serviço. Com os clusters canário, o proprietário do serviço também precisa considerar as versões da frota do GKE em que os serviços estão sendo executados. Uma única versão de serviço distribuído pode ser executada em várias versões de frota do GKE. A migração de um serviço pode ocorrer gradualmente para que você veja os efeitos do serviço na nova frota antes de enviar todo o tráfego do serviço para os novos clusters com versão.
No diagrama a seguir, mostramos que o gerenciamento 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 sendo migrado lentamente
de uma frota de clusters do GKE para a próxima frota que está executando
a nova versão até que a frota mais antiga esteja completamente drenada com o passar do tempo. Depois que a
frota é drenada, ela pode ser removida e uma nova frota é criada. Todos os serviços são
migrados para a próxima frota, removendo as frotas mais antigas à medida que são drenadas.
Se você valoriza mais a resiliência do que qualquer outra coisa, use a estratégia de upgrade do cluster Canary.
Escolher uma estratégia de upgrade
O diagrama a seguir pode ajudar a determinar a melhor estratégia para você com base nas necessidades do serviço e de negócios.
O diagrama anterior é uma árvore de decisão para ajudar você a escolher a estratégia de upgrade certa:
- Se você não precisa de controle total sobre a versão e o horário exatos do upgrade, escolha o recurso de upgrade automático disponível no GKE.
- Se sua prioridade for o baixo custo, é possível escolher a estratégia de upgrade contínuo.
- Se sua prioridade for equilibrar custo e resiliência, você poderá escolher a estratégia azul/verde.
- Se a prioridade for resiliência e não custo, você poderá escolher a estratégia de upgrade do cluster Canary.
Como usar o Ingress de vários clusters para o gerenciamento do ciclo de vida do cluster do GKE
Praticamente todas as estratégias dependem da capacidade de drenar e redirecionar o tráfego para outros clusters durante os upgrades. Uma solução que fornece esse recurso de entrada de vários clusters é o Ingresso de vários clusters. O Ingress de vários clusters é um controlador do Ingress de vários clusters hospedado pelo Google Cloud para clusters do GKE que dá suporte à implantação de recursos de balanceamento de carga compartilhados em clusters e regiões. A Entrada de vários clusters é uma solução para levar o tráfego do cliente a um serviço distribuído em execução em muitos clusters em muitas regiões. Assim como o Ingress for GKE, ele 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 em execução em vários clusters do GKE. Para o tráfego de serviço a serviço em clusters, é possível usar tecnologias de malha de serviço como Malha de serviço Anthos ou Istio, que oferecem funcionalidades semelhantes nos Serviços distribuídos.
Em ambientes de vários clusters do GKE, é possível usar a Entrada de vários clusters para manipular o tráfego em vários clusters para as estratégias de gerenciamento de ciclo de vida do cluster discutidas anteriormente. Siga um tutorial para usar os upgrades de vários clusters para o GKE com a estratégia azul-verde.
A seguir
- Saiba mais sobre a entrada de vários clusters.
- Saiba como implantar a entrada de vários clusters nos clusters.