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 o Ingress de vários clusters para fazer upgrades, os conceitos podem ser aplicados a outras soluções. Este documento destina-se a administradores do Google Cloud responsáveis por manter frotas para clusters do GKE.
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.
Para mais informações sobre como gerenciar a versão do GKE de um cluster, consulte Sobre os upgrades de cluster do GKE. Para mais informações sobre como gerenciar todos os tipos de mudanças durante o ciclo de vida de um cluster, consulte Gerenciar mudanças no ciclo de vida do cluster para minimizar interrupções.
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.
Gerenciamento de tráfego de vários clusters para o ciclo de vida do cluster do GKE
Para manter a disponibilidade do serviço durante upgrades de vários clusters, é necessário drenar e redirecionar o tráfego entre os clusters. É possível gerenciar esse tráfego usando o gateway de vários clusters (recomendado) ou Entrada em vários clusters. O gateway de vários clusters é o sucessor do Entrada em vários clusters e oferece uma abordagem mais expressiva e orientada a funções para a rede de serviços.
Usar o gateway de vários clusters para gerenciamento do ciclo de vida do cluster
O gateway de vários clusters (MCG) usa a API Gateway para gerenciar o tráfego de serviços implantados em vários clusters do GKE em uma frota.
O controlador do Gateway do GKE é um serviço hospedado pelo Google que monitora recursos de gateway e HTTPRoute em um cluster de configuração designado. O controlador provisiona e mantém automaticamente a infraestrutura de balanceamento de carga, fornecendo um único ponto de entrada unificado para aplicativos em clusters na frota. Essa arquitetura permite desacoplar o ciclo de vida do balanceador de carga dos clusters individuais do GKE em que as cargas de trabalho residem.
Para o gerenciamento do ciclo de vida do cluster do GKE, o gateway de vários clusters permite estratégias avançadas de controle de tráfego:
- Upgrades azul-verde: implante um novo cluster "verde" e transfira gradualmente o tráfego do cluster "azul" modificando os pesos no recurso HTTPRoute.
- Balanceamento de carga com base na capacidade: redireciona automaticamente o tráfego quando um serviço em um cluster atinge o limite de capacidade definido, o que ajuda a proteger contra sobrecarga durante upgrades contínuos.
- Failover com base na integridade: monitora a integridade dos back-ends em todos os clusters e redireciona automaticamente o tráfego de um cluster que está sendo consumido ou apresentando problemas.
Para mais informações, siga o tutorial para implantar um gateway de vários clusters para divisão de tráfego ponderada.
Usar o Ingress de vários clusters para gerenciamento do ciclo de vida do cluster
Outra solução para o gerenciamento de tráfego de vários clusters é o Ingress de vários clusters. Entrada em vários clusters é um controlador de entrada de vários clusters hospedado pelo Google Cloud para clusters do GKE que permite implantar 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 a 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 Cloud Service Mesh ou Istio, que oferecem funcionalidades semelhantes nos Serviços distribuídos.
Para mais informações, siga o tutorial para fazer upgrade de um ambiente do GKE de vários clusters com o Ingress de vários clusters.
A seguir
- Saiba mais sobre o gateway de vários clusters.
- Saiba mais sobre o Ingress de vários clusters.