Pontos Principais
- O Kubernetes se tornou o padrão para a orquestração de containers e muitas empresas executam vários de seus clusters. A comunicação dentro destes clusters é um problema que já foi solucionado, mas a comunicação entre clusters exige um design aprimorado e possui problemas de sobrecarga operacional.
- Antes de decidir se vamos implementar o suporte ao multicluster, devemos entender o caso de uso da comunicação.
- Também devemos identificar qual o resultado esperado da solução (um painel único de observação em tempo real, o domínio confiável unificado, etc.) e posteriormente criar um plano de como implementá-lo.
- Existem diversas abordagens para o service mesh multicluster, como o gerenciamento comum, roteamento de serviço com reconhecimento de clusters através de gateways, rede plana e serviço de descoberta de pontos de extremidade com horizonte dividido (EDS, Endpoints Discovery Service).
- O Istio possui suporte ao multicluster, uma nova funcionalidade adicionada na versão 1.1, e serão incluídas mais novidades no futuro.
O Kubernetes se tornou o padrão para a orquestração de containers nas empresas. E existe uma boa razão para isso: O serviço fornece uma série de recursos que tornam muito mais fácil o gerenciamento de aplicações nos containers.
O Kubernetes também cria alguns desafios, sendo o principal deles a necessidade de implantar e administrar vários clusters do Kubernetes para gerenciar efetivamente os sistemas de larga escala distribuídos.
Imagine que possuímos uma aplicação que foi projetada e codificada, e que tenhamos construído os containers, bastando apenas executá-los. Executar o código da aplicação é divertido, mas como qualquer pessoa que criou um programa para containers sabe, isto não é tão simples quanto parece. Antes de implementar na produção, existem vários ciclos de desenvolvimento, teste e fases Além disso, há um aspecto de redimensionamento, pois nossa aplicação em produção pode precisar ser executada em vários locais diferentes, por motivos como escalabilidade horizontal, resiliência ou proximidade com os usuários finais.
Mais ambientes, mais problemas (nos clusters)
Ao iniciarmos o desenvolvimento de um projeto greenfield, tipicamente, não iremos muito longe sem que seja necessário utilizar vários ambientes de implantação. Se estivermos migrando uma aplicação existente, teremos ainda mais desafios, como diferentes domínios de segurança, diferentes organizações e cobranças, além de afinidades diferentes para o kit de ferramentas do machine learning do fornecedor da nuvem.
A abordagem mais comum para resolver esse problema é criar vários clusters Kubernetes, cada um dedicado à execução dos componentes da aplicação em seu ambiente específico. Em um domínio de alta segurança, faremos uso extensivo do RBAC (Controle de Acesso Baseado em Função, Role-Based Access Control em inglês) do Kubernetes e teremos alguns recursos de auditoria. O ambiente de teste deve reproduzir muitos comportamentos da produção, mas deve ser adaptado para facilitar a depuração e a inspeção. Para o ambiente de desenvolvimento, talvez seja melhor deixar como se nós abríssemos as preferências do Docker e tivéssemos marcado a opção Kubernetes. Facilidade de uso e efemeridade são o foco neste caso.
Provavelmente terminaremos com alguns clusters Kubernetes, cada um hospedando alguns microservices. A comunicação entre os microservices em um cluster pode ser aprimorada por um service mesh. Dentro do cluster, o Istio fornece padrões de comunicação comuns para melhorar a resiliência, segurança e observabilidade. Mas e entre clusters diferentes?
A operação com vários clusters Kubernetes não precisa ser assustadora, todavia, é necessário que consideremos como os clusters irão se comunicar e interagir a fim de fornecer facilmente as ótimas aplicações que são executados. Um service mesh como o Istio pode tornar a comunicação multicluster indolor, pois possui suporte à multicluster, adicionados na versão 1.1 e estão planejando adicionar novas funcionalidades no futuro. As equipes devem pensar em empregar um service mesh para simplificar a comunicação entre clusters diferentes também.
Casos de uso comuns
Na Aspen Mesh, somos questionados sobre a execução de um service mesh multicluster para atender às seguintes necessidades dos usuários:
- Tenho vários clusters por causa do tamanho da minha empresa e quero observá-los e gerenciá-los em um único lugar. Meus clusters geralmente não fazem comunicação com uns com os outros, mas quando fazem, é por meio de APIs bem definidas.
- Tenho vários clusters de alta disponibilidade. Eles são clones um do outro e é muito importante que, se um cluster falhar, o outro possa assumir o controle.
- Tenho vários clusters que se combinam para formar uma aplicação de alto nível. Os microservices que estão dentro de um desses clusters precisam se comunicar com os microservices de outro cluster para fornecer a experiência completa de ponta a ponta da aplicação.
É o terceiro ponto onde o multicluster requer comunicação com outros clusters. Se desejamos suporte ao tráfego de dados entre clusters, nossa implementação dependerá da rede onde os clusters estão e dos requisitos de tolerância a falhas.
O que podemos conseguir com os multicluster
Quando estivermos pensando em multicluster e service mesh, precisamos começar identificando o que desejamos e, em seguida, mudar a pergunta para como conseguimos isso.
Painel unificado
Os diversos service meshes ( um para cada cluster) operam em um único local. Podemos visualizar as configurações, métricas e rastreamentos de todos os clusters em um painel unificado.
Domínio de confiança unificado
Usamos um service mesh para fornecer a identificação da carga de trabalho, protegida por forte criptografia de TLS mútua. Esse modelo de confiança zero é melhor do que confiar nas cargas de trabalho baseadas em informações topológicas como o IP de origem: Estamos confiando na prova criptográfica do que as cargas de trabalho são, e não em uma pilha de perímetros frágeis para controlar de onde vieram.
Em um domínio de confiança unificado, todas as cargas de trabalho podem se autenticar, ou seja, saber o que são, conectando-se a mesma raiz de confiança. Os planos de controle do service mesh são configurados para essa raiz comum de confiança, independentemente de existir um ou vários planos.
Domínios de falha independentes
Um cluster que não depende de outros para sua operação adequada, nem mesmo da infraestrutura associada à ele, é um domínio de falha independente. Estamos incluindo o service mesh como infraestrutura associada, se estivermos instalando um service mesh, estamos fazendo isso para mover a resiliência da comunicação para uma camada de infraestrutura abaixo da aplicação. Se uma falha do service mesh em um cluster puder interromper o service mesh em outro cluster, este não é qualificado como um domínio de falha independente.
Tráfego entre clusters
É necessário que o tráfego entre os clusters mantenha partes do service mesh, se desejarmos que os serviços em um cluster se comuniquem diretamente com os serviços em outro cluster e que essa comunicação tenha os benefícios do service mesh, como roteamento avançado, observabilidade ou criptografia transparente. Em outras palavras, queremos que nosso tráfego horizontal deixe um cluster, transite por uma rede intermediária como a Internet e chegue no outro cluster.
Este é provavelmente o primeiro pensamento para a maioria das pessoas quando elas pensam em um service mesh para multicluster, mas estou falando disso separadamente aqui porque há implicações na tolerância a falhas.
Rede heterogênea, não plana
Uma rede não plana oferece suporte a serviços em vários clusters, sem requisitos de rede plana. Isso significa que podemos fazer coisas como alocar IPs em um service mesh sem necessidade de considerar outros, não precisando de VPNs ou túneis de rede para comunicação entre os meshes.
Se a empresa já criou vários clusters diferentes, sem intervalos de endereços IP de pods conflitantes, ou se nunca mais desejamos configurar esse monstrinho novamente, isso pode ser uma boa propriedade para nós.
Abordagens de service mesh multicluster
Depois de apresentarmos as diferentes propriedades que possivelmente procuramos no multicluster, podemos explicar o que as abordagens oferecem.
Clusters independentes
Este não é um multicluster. Só porque temos vários clusters e cada um usa um service mesh, não significa que devemos adotar uma service mesh multicluster para unificar tudo. Em primeiro lugar, precisamos nos perguntar por que acabamos tendo vários clusters. Se desejamos que cada cluster seja o próprio domínio de falha independente, faz sentido isolar e remover dependências entre os clusters. Se isso atender às nossas necessidades, não há mal nenhum em tratar um service mesh como outro serviço de cluster, como agendamento de pods ou gerenciamento de disco persistente.
Gerenciamento comum
Uma etapa posterior da abordagem de clusters independentes é um sistema de gerenciamento comum para vários clusters. Nesse modelo, cada cluster opera independentemente, mas gerenciamos o conjunto dos meshes por meio de uma interface de gerenciamento unificada. É interessante ter a ferramenta que usamos para monitorar e depurar os sistemas localizada fora dos próprios sistemas. Assim, quando o sistema estiver com defeito, ainda podemos inspecioná-lo e corrigi-lo.
Se optarmos por utilizar uma raiz de confiança comum (autoridade de certificação ou certificado de assinatura) entre os clusters, também poderemos ter um domínio de confiança unificado.
Essa é uma boa opção se os domínios de falha independentes forem a principal prioridade, e é adequada para a utilização de software como um serviço, pois, podemos obter um painel de gerenciamento para unificar tudo, apoiado por um contrato de nível de serviço.
Por vermos valor na resiliência, garantimos que o Aspen Mesh dê suporte a esse caso de uso, mesmo que não ativemos nenhuma das abordagens entre diferentes clusters. Essa abordagem também suporta as outras, mas tomamos cuidado para não levar os usuários ao tráfego entre clusters quando não for necessário.
Roteamento de serviço com reconhecimento de cluster através de gateways
Essa abordagem no Istio envolve vários services meshes independentes, uma em cada cluster e alguns truques de configuração para permitir que os serviços em um cluster se comuniquem com os serviços em outros. Começamos criando um domínio de confiança unificado para todos os meshes. Em seguida, configuramos um gateway de entrada para aceitar um tráfego confiável proveniente de um serviço em outro cluster de mesmo nível. Por fim, configuramos as entradas de serviço para permitir que o tráfego de outros serviços sejam roteados de um cluster e enviado para outro.
Este é o primeiro método que permite que os serviços em diferentes clusters se comuniquem diretamente entre si. Além disso, cada cluster ainda é um plano de controle de mesh e um domínio de falha independente. Isso significa que, se a malha de serviço no cluster B falhar, o cluster A ainda irá funcionar. Apenas irá parecer que os serviços no cluster B não estão disponíveis. O ônus de configurar esse tráfego entre os clusters é colocado no usuário.
Rede plana
Este modelo determina um service mesh em todos os clusters. Nós organizamos o modelo de forma que os pods em cada cluster tenham endereços IP não sobrepostos, para que qualquer pod possa rotear o tráfego para qualquer outro pod em qualquer cluster. Podemos ter vários clusters atrás de um firewall comum ou podemos criar túneis VPN entre os clusters. Configuramos nosso service mesh para combinar os pods, serviços e configurações de cada cluster em uma visualização geral.
Uma rede plana faz com que tenhamos um super service mesh que abrange todos os clusters. Existem algumas desvantagens. Esse super service mesh é gerenciado por um plano de controle, portanto, se houver problemas, o service mesh em todos os clusters terá problemas. Se originalmente particionamos em vários clusters do Kubernetes para tolerância a falhas, essa abordagem irá negar essa configuração. Outra consideração é que o plano de controle precisa ser dimensionado para gerenciar todos os clusters. E precisamos fazer com que essa rede plana funcione bem o suficiente para lidar com o plano de controle e o tráfego entre clusters.
Serviço de descoberta de endpoints com horizonte dividido (EDS)
Essa abordagem também cria um service mesh entre os clusters, mas não requer uma rede plana. Ainda temos um plano de controle que descobre os pods, serviços e configurações de cada cluster, mas o EDS do Istio, que possui funcionalidade semelhante ao DNS de horizonte dividido, substitui a necessidade de uma rede plana.
O sidecar de um pod em um cluster é configurado com uma lista de endpoints para cada serviço com o qual desejamos conversar. Se um pod estiver no mesmo cluster, será exibido diretamente na lista EDS. Se um pod estiver em outro cluster, um gateway de entrada para o outro cluster será exibido. O pod escolhe um endpoint para conversar e envia os dados, se o endpoint for local, a comunicação será de pod para pod. Se o pod escolher um endpoint remoto, enviará o tráfego para o endereço do gateway de entrada relevante, marcado para o serviço com o qual o pod deseja conversar. O gateway de entrada pega o tráfego e o envia para um dos pods no seu cluster que implementa o serviço. O gateway de entrada usa o Server Name Indication (SNI) para saber para onde o tráfego é destinado.
Assim como a abordagem de rede plana, isso cria um plano de controle unificado do service mesh e adiciona um domínio de falha e um domínio de confiança, ambos sendo únicos. Não requer uma rede plana, exige apenas que um cluster possa enviar tráfego para o endereço público de gateways de entrada para os outros clusters.
É ou não é para multiclusters
Se estivermos executando vários clusters por motivos organizacionais ou de desenvolvimento, é importante entender os requisitos e decidir se desejamos conectá-los em um ambiente multicluster e, se houver a necessidade, entender as várias abordagens e contrapartidas associadas a cada opção.
Provavelmente se você leitor, chegou até este ponto do artigo, decidiu utilizar um multicluster. A verdadeira questão é saber qual o melhor método para implementar. Felizmente, a tabela abaixo o ajudará a decidir sobre a abordagem certa para você.
Um service mesh como o Istio pode ajudar e, quando usado corretamente, tornar a comunicação multicluster indolor. Se quiser entender mais sobre a minha opinião do por que e como as equipes devem pensar em empregar um service mesh para simplificar a comunicação entre vários clusters, ou a comunicação multicluster com um service mesh, ou sobre como empregar um service mesh, sinta-se à vontade para entrar em contato comigo pelo meu email andrew@aspenmesh.io.
Sobre o autor
Andrew Jenkins é CTO da Aspen Mesh, onde está construindo um service mesh corporativo para ajudar as empresas a diminuir o fardo do gerenciamento de microservices. Arquiteto de software e de rede para ambientes de containers como o Kubernetes, Jenkins tem um histórico de liderança técnica que leva as equipes em rápido movimento a alcançar resultados tangíveis. Sua experiência inclui desenvolvimento de software em C++, JavaScript (Node.js), Python, C, Go e Java. Jenkins também tem experiência em testes de software e hardware, FPGAs e design de placas para instrumentos científicos espaciais.