Uma comparação de malha de serviço do Kubernetes

Ao discutir a arquitetura de microsserviços e a conteinerização, um conjunto de ferramentas comprovadas em produção capturou a maior parte da atenção nos últimos anos: a malha de serviço.

De fato, a arquitetura de microsserviços e o Kubernetes (muitas vezes estilizados como “K8s”) rapidamente se tornaram a norma para aplicativos escaláveis, tornando o problema de gerenciamento de comunicações entre serviços um tópico importante – e as malhas de serviços uma solução atraente. Eu mesmo usei malhas de serviço na produção, especificamente Linkerd, Istio e uma forma anterior de Ambassador. Mas o que as malhas de serviço fazem exatamente? Qual deles é o melhor para usar? Como você sabe se você deve usar um em tudo?

Para responder a essas perguntas, ajuda a entender por que as malhas de serviço foram desenvolvidas. Historicamente, a infraestrutura de TI tradicional tinha aplicativos rodando como monólitos. Um serviço foi executado em um servidor; se ela precisasse de mais capacidade, a solução era escalá-la verticalmente provisionando uma máquina maior.

Atingindo os limites dessa abordagem, as grandes empresas de tecnologia adotaram rapidamente uma arquitetura de três camadas, separando um balanceador de carga de servidores de aplicativos e uma camada de banco de dados. Embora essa arquitetura tenha permanecido um pouco escalável, eles decidiram dividir a camada de aplicativos em microsserviços. A comunicação entre esses serviços tornou-se crítica para monitorar e proteger para que os aplicativos possam ser dimensionados.

Para permitir a comunicação entre serviços, essas empresas desenvolveram bibliotecas internas: Finagle no Twitter, Hystrix na Netflix e Stubby no Google (que se tornou gRPC em 2016). Essas bibliotecas visavam corrigir problemas levantados pela arquitetura de microsserviços: segurança entre serviços, latência, monitoramento e balanceamento de carga. Mas gerenciar uma grande biblioteca como uma dependência – em vários idiomas – é complexo e demorado.

No final, esse tipo de biblioteca foi substituído por um proxy leve e fácil de usar. Esses proxies eram externamente independentes da camada do aplicativo — potencialmente transparentes para o aplicativo — e mais fáceis de atualizar, manter e implantar. Assim nasceu a malha de serviço.

O que é uma malha de serviço?

Uma malha de serviço é uma camada de infraestrutura de software para controlar a comunicação entre serviços; geralmente é feito de dois componentes:

1. O plano de dados , que trata das comunicações próximas ao aplicativo. Normalmente, isso é implantado com o aplicativo como um conjunto de proxies de rede, conforme ilustrado anteriormente.
2. O plano de controle, que é o “cérebro” da malha de serviço. O plano de controle interage com proxies para enviar configurações, garantir a descoberta de serviços e centralizar a observabilidade.

As malhas de serviço têm três objetivos principais em torno da comunicação entre serviços:

1. Conectividade
2. Segurança
3. Observabilidade

Conectividade

Esse aspecto da arquitetura de malha de serviço permite descoberta de serviço e roteamento dinâmico. Ele também abrange a resiliência de comunicação , como novas tentativas, tempos limite, interrupção de circuito e limitação de taxa.

Um recurso básico das malhas de serviço é o balanceamento de carga. Todos os serviços que estão sendo mesclados por proxies permitem a implementação de políticas de balanceamento de carga entre serviços, como round robin, random e less requests. Essas políticas são a estratégia usada pela malha de serviço para decidir qual réplica receberá a solicitação original, como se você tivesse pequenos balanceadores de carga na frente de cada serviço.

Finalmente, as malhas de serviço oferecem controle de roteamento na forma de deslocamento e espelhamento de tráfego.

Segurança

Na arquitetura tradicional de microsserviços, os serviços se comunicam entre si com tráfego não criptografado. O tráfego interno não criptografado é hoje considerado uma má prática em termos de segurança, principalmente para infraestrutura de nuvem pública e redes de confiança zero.

Além de proteger a privacidade dos dados do cliente onde não há controle direto sobre o hardware, a criptografia do tráfego interno adiciona uma camada bem-vinda de complexidade extra em caso de violação do sistema. Assim, todas as malhas de serviço usam criptografia TLS mútua (mTLS) para comunicação entre serviços, ou seja, toda comunicação interproxy.

As malhas de serviço podem até impor matrizes complexas de política de autorização , permitindo ou rejeitando tráfego com base em políticas que visam ambientes e serviços específicos.

Observabilidade

O objetivo das malhas de serviço é trazer visibilidade às comunicações entre serviços. Ao controlar a rede, uma malha de serviço reforça a observabilidade, fornecendo métricas de camada sete , que por sua vez permitem alertas automáticos quando o tráfego atinge algum limite personalizável.

Geralmente suportado por ferramentas de terceiros ou plug-ins como Jaeger ou Zipkin, esse controle também permite o rastreamento injetando cabeçalhos de rastreamento HTTP .

Benefícios da malha de serviço

A malha de serviço foi criada para compensar parte da carga operacional criada por uma arquitetura de microsserviços. Aqueles com experiência em arquiteturas de microsserviços sabem que exigem uma quantidade significativa de trabalho para operar diariamente. Aproveitar ao máximo o potencial dos microsserviços normalmente requer ferramentas externas para lidar com logs centralizados, gerenciamento de configuração e mecanismos de escalabilidade, entre outros. O uso de uma malha de serviço padroniza esses recursos e sua configuração e integração .

A observabilidade da malha de serviço, em particular, fornece métodos de depuração e otimização extremamente versáteis. Graças à visibilidade granular e completa das trocas entre serviços, os engenheiros, principalmente os SREs, podem solucionar mais rapidamente possíveis bugs e configurações incorretas do sistema. Com o rastreamento de malha de serviço, eles podem seguir uma solicitação desde sua entrada no sistema (em um balanceador de carga ou proxy externo) até os serviços privados dentro da pilha. Eles podem usar o log para mapear uma solicitação e registrar a latência encontrada em cada serviço. O resultado final: insights detalhados sobre o desempenho do sistema .

O gerenciamento de tráfego oferece possibilidades poderosas antes de lançar uma versão completa de uma nova versão de um serviço:

1. Redirecione pequenas porcentagens de solicitações.
2. Melhor ainda, espelhe as solicitações de produção em uma nova versão para testar seu comportamento com tráfego em tempo real.
3. Teste A/B de qualquer serviço ou combinação de serviços.

As malhas de serviço simplificam todos os cenários acima, tornando mais fácil evitar e/ou mitigar quaisquer surpresas na produção.

Comparação de malha de serviço do Kubernetes

De muitas maneiras, as malhas de serviço são o conjunto definitivo de ferramentas para arquitetura de microsserviços; muitos deles são executados em uma das principais ferramentas de orquestração de contêineres, o Kubernetes. Selecionamos três das principais malhas de serviço em execução no Kubernetes hoje: Linkerd (v2), Istio e Consul Connect. Também discutiremos algumas outras malhas de serviço: Kuma, Traefik Mesh e AWS App Mesh. Embora atualmente menos proeminentes em termos de uso e comunidade, eles são promissores o suficiente para revisar aqui e manter o controle geral.

Uma nota rápida sobre proxies sidecar

Nem todas as malhas de serviço do Kubernetes adotam a mesma abordagem de arquitetura, mas uma abordagem comum é aproveitar o padrão sidecar. Isso envolve anexar um proxy (sidecar) ao aplicativo principal para interceptar e regular o tráfego de rede de entrada e saída do aplicativo. Na prática, isso é feito no Kubernetes por meio de um contêiner secundário em cada pod de aplicativo que seguirá o ciclo de vida do contêiner do aplicativo.

Existem duas vantagens principais na abordagem sidecar para malhas de serviço:

• Os proxies sidecar são independentes do tempo de execução e até mesmo da linguagem de programação do aplicativo.
  • Isso significa que é fácil habilitar todos os recursos de uma malha de serviço onde quer que ela seja usada, em toda a pilha.
• Um sidecar tem o mesmo nível de permissões e acesso a recursos que o aplicativo.
  • O sidecar pode ajudar a monitorar os recursos usados ​​pelo aplicativo principal, sem a necessidade de integrar o monitoramento na base de código do aplicativo principal.

Mas os sidecars são uma benção mista por causa de como eles afetam diretamente um aplicativo:

• A inicialização do sidecar pode travar o mecanismo de partida de um aplicativo.
• Os proxies sidecar adicionam latência potencial em cima do seu aplicativo.
• Os proxies sidecar também adicionam uma pegada de recursos que pode custar uma quantia significativa de dinheiro em escala.

Dadas essas vantagens e desvantagens, a abordagem de sidecar é frequentemente um assunto de debate na comunidade de service mesh. Dito isso, quatro das seis malhas de serviço comparadas aqui usam o proxy sidecar Envoy, e o Linkerd usa sua própria implementação de sidecar; O Traefik Mesh não usa sidecars em seu design.

Revisão do Linker

O Linkerd, que estreou em 2017, é o service mesh mais antigo do mercado. Criado pela Buoyant (uma empresa iniciada por dois ex-engenheiros do Twitter), o Linkerd v1 foi baseado em Finagle e Netty.

O Linkerd v1 foi descrito como estando à frente de seu tempo, pois era uma malha de serviço completa e pronta para produção. Ao mesmo tempo, era um pouco pesado em termos de uso de recursos. Além disso, lacunas significativas na documentação dificultavam a configuração e a execução em produção.

Com isso, a Buoyant teve a chance de trabalhar com um modelo de produção completo, ganhar experiência com ele e aplicar essa sabedoria. O resultado foi Conduit, a reescrita completa do Linkerd que a empresa lançou em 2018 e renomeou Linkerd v2 no final daquele ano. O Linkerd v2 trouxe várias melhorias interessantes; desde que o desenvolvimento ativo do Linkerd v1 pela Buoyant cessou há muito tempo, nossas menções de “Linkerd” no restante deste artigo referem-se à v2.

Totalmente de código aberto, o Linkerd conta com um proxy caseiro escrito em Rust para o plano de dados e no código-fonte escrito em Go para o plano de controle.

Conectividade

Os proxies do Linkerd têm recursos de repetição e tempo limite, mas não têm interrupção de circuito ou injeção de atraso no momento da redação deste artigo. O suporte ao ingresso é amplo; O Linkerd possui integração com os seguintes controladores de ingresso:

• Traefik
• Nginx
• ECG
• Embaixador
• Gloo
• Contorno
• Kong

Os perfis de serviço no Linkerd oferecem recursos de roteamento aprimorados, fornecendo ao usuário métricas, ajuste de repetição e configurações de tempo limite, tudo por rota. Quanto ao balanceamento de carga, o Linkerd oferece injeção automática de proxy, painel próprio e suporte nativo ao Grafana.

Segurança

O suporte mTLS no Linkerd é conveniente, pois sua configuração inicial é automática, assim como sua rotação diária automática de chaves.

Observabilidade

Fora da caixa, as estatísticas e rotas do Linkerd são observáveis ​​por meio de uma CLI. No lado da GUI, as opções incluem painéis Grafana pré-fabricados e um painel nativo do Linkerd.

O Linkerd pode se conectar a uma instância do Prometheus.

O rastreamento pode ser ativado por meio de um complemento com OpenTelemetry (anteriormente OpenCensus) como coletor e Jaeger fazendo o rastreamento em si.

Instalação

A instalação do Linkerd é feita injetando um proxy sidecar, que é feito adicionando uma anotação aos seus recursos no Kubernetes. Há duas maneiras de fazer isso:

1. Usando um gráfico Helm. (Para muitos, o Helm é o gerenciador de configuração e modelo para recursos do Kubernetes.)
2. Instalando a CLI do Linkerd e usando-a para instalar o Linkerd em um cluster.

O segundo método começa com o download e a execução de um script de instalação:

 curl -sL https://run.linkerd.io/install | sh

A partir daí, a ferramenta Linkerd CLI do linkerd fornece um kit de ferramentas útil que ajuda a instalar o restante do Linkerd e interagir com o cluster de aplicativos e o plano de controle.

linkerd check --pre executará todas as verificações preliminares necessárias para sua instalação do Linkerd, fornecendo registros claros e precisos sobre por que uma possível instalação do Linkerd pode não funcionar ainda. Sem --pre , este comando pode ser usado para depuração pós-instalação.

A próxima etapa é instalar o Linkerd no cluster executando:

 linkerd install | kubectl apply -f -

O Linkerd então instalará muitos componentes diferentes com uma pegada de recursos muito pequena; portanto, eles próprios têm uma abordagem de microsserviços:

• linkerd-controller , que fornece a API pública com a qual a CLI e o painel interagem
• linkerd-identity , que fornece a autoridade de certificação para implementar o mTLS
• linkerd-proxy-injector , que lida com a injeção do proxy alterando a configuração de um pod
• linkerd-web , que oferece um painel que permite o monitoramento de implantações e pods, bem como componentes internos do Linkerd

O Linkerd baseia a maior parte de sua configuração em CustomResourceDefinitions (CRDs). Essa é considerada a melhor prática ao desenvolver software complementar do Kubernetes — é como instalar de forma durável um plug-in em um cluster do Kubernetes.

Adicionar rastreamento distribuído - que pode ou não ser o que os usuários do Linkerd estão realmente procurando, devido a alguns mitos comuns - requer outra etapa com o linkerd-collector e o linkerd-jaeger. Para isso, primeiro criaríamos um arquivo de configuração:

 cat >> config.yaml << EOF tracing: enabled: true EOF

Para habilitar o rastreamento, executaríamos:

 linkerd upgrade --config config.yaml | kubectl apply -f -

Como acontece com qualquer malha de serviço baseada em proxies sidecar, você precisará modificar o código do aplicativo para habilitar o rastreamento. A maior parte disso é simplesmente adicionar uma biblioteca cliente para propagar cabeçalhos de rastreamento; ele então precisa ser incluído em cada serviço.

O recurso de divisão de tráfego do Linkerd, exposto por meio de sua API compatível com Service Mesh Interface (SMI), já permite versões canary. Mas para automatizá-los e gerenciar o tráfego, você também precisará de ferramentas externas como o Flagger.

O Flagger é uma ferramenta de entrega progressiva que avaliará o que o Linkerd chama de métricas “de ouro” : “volume de solicitações, taxa de sucesso e distribuições de latência”. (Originalmente, os SREs do Google usavam o termo sinais dourados e incluíam um quarto — saturação —, mas o Linkerd não o cobre porque isso exigiria métricas que não são diretamente acessíveis, como uso de CPU e memória.) O Flagger os rastreia enquanto divide o tráfego usando um loop de feedback; portanto, você pode implementar versões canary automatizadas e com reconhecimento de métricas.

Depois de mergulhar no processo de instalação, fica claro que para ter uma malha de serviço do Linkerd operacional e explorar os recursos comumente desejados, é fácil acabar com pelo menos uma dúzia de serviços em execução. Dito isto, mais deles são fornecidos pelo Linkerd na instalação do que com outras malhas de serviço.

Resumo da malha de serviço do Linkerd

Vantagens:

O Linkerd se beneficia da experiência de seus criadores, dois ex-engenheiros do Twitter que trabalharam na ferramenta interna, Finagle, e mais tarde aprenderam com o Linkerd v1. Como uma das primeiras malhas de serviço, o Linkerd tem uma comunidade próspera (seu Slack tem mais de 5.000 usuários, além de uma lista de discussão ativa e servidor Discord) e um extenso conjunto de documentação e tutoriais. O Linkerd está maduro com o lançamento da versão 2.9, como evidenciado por sua adoção por grandes corporações como Nordstrom, eBay, Strava, Expedia e Subspace. O suporte de nível empresarial pago da Buoyant está disponível para o Linkerd.

Desvantagens:

Há uma curva de aprendizado bastante forte para usar as malhas de serviço do Linkerd em todo o seu potencial. O Linkerd é suportado apenas em contêineres do Kubernetes (ou seja, não há modo “universal”) baseado em VM). O proxy sidecar do Linkerd não é o Envoy. Embora isso permita que o Buoyant o ajuste como acharem melhor, ele remove a extensibilidade inerente que o Envoy oferece. Isso também significa que o Linkerd não tem suporte para interrupção de circuito, injeção de atraso e limitação de taxa. Nenhuma API específica é exposta para controlar facilmente o plano de controle do Linkerd. (No entanto, você pode encontrar a vinculação da API gRPC.)

O Linkerd fez grandes progressos desde a v1 em usabilidade e facilidade de instalação. A falta de uma API oficialmente exposta é uma omissão notável. Mas graças à documentação bem pensada, a funcionalidade pronta para uso no Linkerd é fácil de testar.

Revisão do Consul Connect

Nosso próximo concorrente do service mesh, o Consul Connect, é um híbrido exclusivo. A Consul da HashiCorp é mais conhecida por seu armazenamento de valor-chave para arquiteturas distribuídas, que existe há muitos anos. Após a evolução do Consul em um conjunto completo de ferramentas de serviço, a HashiCorp decidiu construir uma malha de serviço em cima dele: Consul Connect.

Para ser preciso sobre sua natureza híbrida:

O plano de dados do Consul Connect é baseado no Envoy, que é escrito em C++. O plano de controle do Consul Connect é escrito em Go. Esta é a parte que é apoiada pelo Consul KV, um armazenamento de chave-valor.

Como a maioria das outras malhas de serviço, o Consul Connect funciona injetando um proxy sidecar dentro do seu pod de aplicativo. Em termos de arquitetura, o Consul Connect é baseado em agentes e servidores . Pronto para uso, o Consul Connect deve ter alta disponibilidade (HA) usando três ou cinco servidores como um StatefulSet especificando a antiafinidade do pod. A antiafinidade de pod é a prática de garantir que os pods de um sistema de software distribuído não acabem no mesmo nó (servidor), garantindo assim a disponibilidade caso qualquer nó único falhe.

Conectividade

Não há muito que faça Consul Connect se destacar nesta área; ele fornece o que qualquer malha de serviço faz (o que é bastante), além de recursos de camada sete para roteamento baseado em caminho, deslocamento de tráfego e balanceamento de carga.

Segurança

Assim como as outras malhas de serviço, o Consul Connect fornece recursos básicos de mTLS. Ele também possui integração nativa entre Consul e Vault (também da HashiCorp), que pode ser usado como provedor de CA para gerenciar e assinar certificados em um cluster.

Observabilidade

O Consul Connect adota a abordagem de observabilidade mais comum ao incorporar o Envoy como um proxy sidecar para fornecer recursos de camada sete. Configurar a interface do usuário do Consul Connect para buscar métricas envolve alterar um arquivo de configuração integrado e também habilitar um provedor de métricas como o Prometheus. Também é possível configurar alguns painéis do Grafana para mostrar métricas relevantes específicas do serviço.

Instalação

O Consul Connect é instalado em um cluster Kubernetes usando um gráfico Helm:

 helm repo add hashicorp https://helm.releases.hashicorp.com

Você precisará modificar os values.yaml se quiser habilitar a interface do usuário ou fazer com que o módulo Consul Connect injete seu proxy sidecar:

 helm install -f consul-values.yml hashicorp hashicorp/consul

Para consultar os membros e verificar os vários nós, a Consul recomenda exec em um dos containers e depois usar a ferramenta CLI consul .

Para fornecer a interface do usuário da Web pronta para uso fornecida pelo Consul, execute kubectl port-forward service/hashicorp-consul-ui 18500:80 .

Resumo da malha de serviço do Consul Connect

Vantagens:

• A Consul é apoiada pela HashiCorp; como um produto freemium, há também uma versão empresarial com recursos adicionais que oferece suporte de nível empresarial. Em termos de experiência da equipe de desenvolvimento, o Consul é uma das ferramentas mais antigas do mercado.
• A Consul tem uma comunidade empresarial sólida e é conhecida por rodar em infraestrutura com 50.000 nós. Além disso, existe desde 2014, tornando-o um produto maduro em relação ao mercado.
• O Consul Connect funciona bem dentro de uma VM, graças ao suporte nativo.
• Com o Consul Connect, é possível obter integrações de aplicativos tão profundas quanto as implementações de malha de pré-serviço em empresas de tecnologia de primeira linha. Isso se deve à exposição de uma API de nível de biblioteca totalmente documentada.

Desvantagens:

• O Consul Connect tem uma curva de aprendizado mais acentuada do que as outras malhas de serviço e precisará de mais ajustes para executar painéis e métricas visuais.
• A documentação da HashiCorp não é direta, deixando os usuários cavar e experimentar para configurá-la corretamente.
• A documentação de gerenciamento de tráfego é difícil de encontrar e consiste principalmente em links para a documentação do Envoy, que não fornece detalhes sobre o gerenciamento de tráfego do Consul Connect em particular.
• A interface SMI do Consul Connect ainda é experimental.

O Consul Connect pode ser uma ótima opção para quem busca um produto de nível empresarial. A HashiCorp é conhecida pela qualidade de seus produtos, e a Consul Connect não é exceção. Posso ver duas fortes vantagens aqui em comparação com outras malhas de serviço: forte suporte da empresa com a versão corporativa e uma ferramenta pronta para todos os tipos de arquiteturas (não apenas Kubernetes).

Revisão do Istio

Em maio de 2017, Google, IBM e Lyft anunciaram o Istio. Quando o Istio entrou na corrida das ferramentas de malha de serviço, ganhou uma exposição muito boa no espaço de tecnologia. Seus autores adicionaram recursos com base no feedback do usuário até a versão 1.9.

O Istio prometia novos recursos importantes sobre seus concorrentes na época: balanceamento de carga automático, injeção de falhas e muito mais. Isso rendeu muita atenção da comunidade, mas como detalharemos abaixo, usar o Istio está longe de ser trivial: o Istio foi reconhecido como particularmente complexo para colocar em produção.

Historicamente, o projeto Istio saltou com frequência em termos de alterações no código-fonte. Depois de adotar uma arquitetura de microsserviço para o plano de controle, o Istio agora (desde a versão 1.5) voltou para uma arquitetura monolítica. A justificativa do Istio para retornar à centralização era que os microsserviços eram difíceis de monitorar pelos operadores, a base de código era muito redundante e o projeto havia atingido a maturidade organizacional - não precisava mais ter muitas equipes pequenas trabalhando em silos.

No entanto, ao longo do caminho, o Istio ganhou notoriedade por ter um dos maiores volumes de problemas abertos do GitHub. No momento da redação deste artigo, a contagem é de cerca de 800 questões abertas e cerca de 12.000 fechadas. Embora as contagens de problemas possam enganar, nesse caso, elas representam uma melhoria significativa em termos de recursos quebrados anteriormente e uso de recursos fora de controle.

Conectividade

O Istio é bastante forte no gerenciamento de tráfego em comparação com o Consul Connect e o Linkerd. Isso se deve a uma ampla oferta de sub-recursos: roteamento de solicitação, injeção de falhas, deslocamento de tráfego, tempos limite de solicitação, interrupção de circuito e controle de tráfego de entrada e saída para a malha de serviço. A noção de serviços virtuais e regras de destino o torna muito completo em termos de gerenciamento de tráfego.

No entanto, todas essas possibilidades vêm com uma curva de aprendizado, além do gerenciamento desses novos recursos em seu cluster Kubernetes.

Segurança

O Istio possui um conjunto abrangente de ferramentas relacionadas à segurança, com dois eixos principais: autenticação e autorização. O Istio pode aplicar diferentes níveis de políticas em diferentes escopos: específicos da carga de trabalho, em todo o namespace ou em toda a malha. Todos esses recursos de segurança são gerenciados por meio de CRDs do Istio, como AuthorizationPolicy ou PeerAuthentication .

Além do suporte mTLS padrão, o Istio também pode ser configurado para aceitar ou rejeitar tráfego não criptografado.

Observabilidade

Aqui, o Istio é bastante avançado, com vários tipos de telemetria oferecendo informações sólidas sobre a malha de serviço. As métricas são baseadas nos quatro sinais dourados (latência, tráfego, erros e, até certo ponto, saturação).

Notavelmente, o Istio fornece métricas para o próprio plano de controle. Ele também atende rastreamentos distribuídos e logs de acesso, apresentando compatibilidade explícita com Jaeger, Lightstep e Zipkin para permitir o rastreamento.

Não há painel nativo, mas há suporte oficial para o console de gerenciamento Kiali.

Instalação

A instalação é tão simples quanto seguir as etapas oficiais. O Istio também é integrado nativamente ao GKE como um recurso beta, mas o GKE usa o Istio 1.4.X, a versão de microsserviços mais antiga, em vez da versão monolítica mais recente.

Uma instalação nativa começa com o download da versão mais recente:

 curl -L https://istio.io/downloadIstio | sh -

Depois de fazer cd na pasta istio-* recém-criada, você pode adicioná-la ao seu caminho para poder usar a ferramenta de utilitário istioctl :

 export PATH=$PWD/bin:$PATH

A partir daí, você pode instalar o Istio em seu cluster Kubernetes via istioctl :

 istioctl install

Isso instalará o Istio com um perfil default . Os perfis istioctl permitem que você crie diferentes configurações de instalação e alterne entre elas, se necessário. Mas mesmo em um cenário de perfil único, você pode personalizar profundamente a instalação do Istio modificando alguns CRDs.

Os recursos do Istio serão mais difíceis de gerenciar, pois você precisará gerenciar vários tipos de CRDs — VirtualService , DestinationRule e Gateway no mínimo — para garantir que o gerenciamento de tráfego esteja em vigor.

• Um recurso VirtualService é uma configuração que declara um serviço e as diferentes regras de roteamento aplicadas às solicitações.
• Um recurso DestinationRule é usado para agrupar e impor políticas de tráfego específicas de destino.
• Um recurso Gateway é criado para gerenciar o tráfego de malha de serviço de entrada e saída (ou seja, proxies Envoy adicionais, mas executados na borda e não como sidecars).

Os detalhes semânticos estão além do escopo desta revisão, mas vejamos um exemplo rápido que mostra cada um deles trabalhando juntos. Suponha que temos um site de comércio eletrônico com um serviço chamado products . Nosso VirtualService pode ficar assim:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: products-route namespace: ecommerce spec: hosts: - products # interpreted as products.ecommerce.svc.cluster.local http: - match: - uri: prefix: "/listv1" - uri: prefix: "/catalog" rewrite: uri: "/listproducts" route: - destination: host: products # interpreted as products.ecommerce.svc.cluster.local subset: v2 - route: - destination: host: products # interpreted asproducts.ecommerce.svc.cluster.local subset: v1

A DestinationRule correspondente poderia então ser:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: products spec: host: products trafficPolicy: loadBalancer: simple: RANDOM # or LEAST_CONN or ROUND_ROBIN subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 - name: v3 labels: version: v3

Por fim, nosso Gateway :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: cert-manager-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*"

Com esses três arquivos no lugar, uma instalação do Istio estaria pronta para lidar com o tráfego básico.

Resumo da malha de serviço do Istio

Vantagens:

• Entre as diferentes malhas de serviço, o Istio é aquele com a maior comunidade online até o momento. Com mais de 10 vezes os resultados do Stack Overflow como qualquer um de seus principais concorrentes, é o service mesh mais falado na web; seus contribuidores do GitHub também são uma ordem de magnitude além dos do Linkerd.
• O Istio oferece suporte aos modos Kubernetes e VM; o último está em beta a partir da versão 1.9.

Desvantagens:

• O Istio não é gratuito, em dois sentidos:
  • Seus requisitos são altos em termos de tempo necessário para ler a documentação, configurá-la, fazê-la funcionar corretamente e mantê-la. Dependendo do tamanho da infraestrutura e do número de serviços, o Istio levará várias semanas a vários meses de trabalho em tempo integral para ser totalmente funcional e integrado à produção.
  • Ele também adiciona uma quantidade significativa de sobrecarga de recursos: serão necessários 350 milicores (mCPU) para o contêiner Envoy por 1.000 solicitações por segundo (RPS). Até mesmo o próprio plano de controle pode consumir recursos. (Anteriormente, o uso de recursos seria difícil de prever, mas depois de algum esforço, istiod se estabilizou usando 1 vCPU e 1,5 GB de memória.)
• Não possui painel de administração nativo, ao contrário do Linkerd.
• O Istio requer o uso de seu próprio gateway de entrada.
• O plano de controle do Istio só é compatível com os contêineres do Kubernetes (ou seja, não há modo VM, ao contrário do plano de dados do Istio).

O Istio é um ótimo exemplo de gigantes da tecnologia se unindo para criar um projeto de código aberto para enfrentar um desafio que todos estão enfrentando. Levou algum tempo para o projeto Istio como um todo se estruturar (lembrando a mudança de arquitetura de microsserviços para monolito) e resolver seus muitos problemas iniciais. Hoje, o Istio está fazendo absolutamente tudo o que se espera de uma malha de serviço e pode ser bastante estendido. Mas todas essas possibilidades vêm com grandes requisitos em termos de conhecimento, horas de trabalho e recursos de computação para suportar seu uso em um ambiente de produção.

Revisão rápida de Kuma

Criado por Kong e depois de código aberto, o Kuma atingiu 1.0 no final de 2020. Até certo ponto, foi criado em resposta às primeiras malhas de serviço serem bastante pesadas e difíceis de operar.

Sua lista de recursos sugere que seja muito modular; a ideia por trás do Kuma é orientá-lo para a integração com aplicativos já executados no Kubernetes ou outra infraestrutura.

• Na área de gerenciamento de tráfego , o Kuma oferece recursos comuns de malha de serviço, como injeção de falhas e interrupção de circuito.
• Além da criptografia mTLS entre serviços, as trocas entre o plano de dados e o plano de controle são protegidas no Kuma por meio de um token proxy de plano de dados .
• A observabilidade é definida no Kuma por meio de diferentes políticas de tráfego em torno de métricas, rastreamento e registro.
• A descoberta de serviço está disponível por meio do Kuma graças ao seu próprio resolvedor de DNS em execução na porta 5653 do plano de controle.
• O Kuma tem uma forte ênfase na funcionalidade multimesh : você pode combinar facilmente vários clusters Kubernetes ou ambientes de VM em um cluster Kuma comum com seu tipo de implantação multizona.
• O Kuma integra-se facilmente ao Kong Gateway para usuários existentes do Kong.

A versão universal (não-Kubernetes) do Kuma requer o PostgreSQL como uma dependência, e o CTO de Kong tem sido notavelmente contra o suporte ao SMI. Mas o Kuma foi desenvolvido com a ideia de implantações multicloud e multicluster desde o início, e seu painel reflete isso.

Embora Kuma ainda seja jovem no espaço do service mesh, com poucos casos de uso em produção até agora, é um concorrente interessante e promissor.

Revisão rápida da malha de Traefik

Originalmente chamado de Maesh, o Traefik Mesh (por Traefik Labs) é outro recém-chegado na corrida de ferramentas de malha de serviço. A missão do projeto é democratizar o service mesh tornando-o fácil de usar e configurar; a experiência dos desenvolvedores com o bem pensado Traefik Proxy os colocou em uma posição privilegiada para conseguir isso.

• Os recursos de gerenciamento de tráfego no Traefik Mesh incluem interrupção de circuito e limitação de taxa.
• Em termos de observabilidade , o Traefik Mesh possui suporte nativo ao OpenTracing e métricas prontas para uso (a instalação padrão inclui automaticamente o Prometheus e o Grafana), o que economiza tempo de configuração.
• Para segurança, além do mTLS, as especificações são compatíveis com SMI e o Traefik Mesh permite o ajuste fino das permissões de tráfego por meio do controle de acesso.

O Traefik Mesh precisa que o CoreDNS seja instalado no cluster. (Embora o Azure tenha usado CoreDNS por padrão desde a versão 1.12, o GKE adota como padrão kube-dns no momento da redação deste artigo, o que significa que há uma etapa extra significativa envolvida nesse caso.) Ele também não possui recursos de multicluster.

Dito isto, o Traefik Mesh é único em nossa comparação de malha de serviço, pois não usa injeção de sidecar. Em vez disso, ele é implantado como um DaemonSet em todos os nós para atuar como um proxy entre os serviços, tornando-o não invasivo. No geral, o Traefik Mesh é simples de instalar e usar.

Revisão rápida do AWS App Mesh

No mundo dos provedores de nuvem, a AWS é a primeira a ter implementado uma malha de serviço nativa conectável com Kubernetes (ou EKS em particular), mas também seus outros serviços. O AWS App Mesh foi lançado em novembro de 2018 e a AWS tem feito iterações nele desde então. A principal vantagem do AWS App Mesh é o ecossistema AWS preexistente e a posição de mercado; a grande comunidade por trás da AWS em geral continuará a impulsionar seu uso e usabilidade.

• O gerenciamento de tráfego no AWS App Mesh inclui interrupção de circuito além de recursos comuns.
• Since AWS App Mesh is hosted by AWS, it's a fully managed service , which means not having to worry about resource usage or control plane availability.
• Observability in AWS App Mesh can be done through Prometheus or AWS X-Ray.

The project is not open source, doesn't support SMI, and there's not much info online about HA standards for the control plane. AWS App Mesh is more complex to set up than other Kubernetes-native service meshes and has very little community online (24 answers on Stack Overflow, 400 stars on GitHub) but that's because users are meant to benefit from AWS support.

AWS App Mesh has native integration with AWS, starting with EKS and extending to other AWS services like ECS (Fargate) and EC2. Unlike Traefik Mesh, it has multicluster support. Plus, like most service meshes, it's based on injecting Envoy, the battle-tested sidecar proxy.

Kubernetes Service Mesh Comparison Tables

The six Kubernetes service mesh options presented here have a few things in common:

• Protocol support : They all work with HTTP, HTTP/2, gRPC, TCP, and WebSockets.
• They all have basic security in the form of mTLS between proxies by default.
• Service meshes, by design, provide some form of load balancing .
• These six, at least, also include a request retrying option among their traffic management features.
• Lastly, service discovery is a core feature of any service mesh.

But there are certainly differences worth highlighting when it comes to service mesh infrastructure, traffic management, observability, deployment, and other aspects.

A infraestrutura

Traffic Management

Observability

* OpenCensus and OpenTracing merged into OpenTelemetry in 2019, but you might find Linkerd articles referring to OpenCensus, as well as Istio and Traefik Mesh articles referring to OpenTracing.

Desdobramento, desenvolvimento

Other Service Mesh Considerations

Should We Use a Kubernetes Service Mesh?

Now that we have seen what service meshes are, how they work, and the multitude of differences between them, we can ask: Do we need a service mesh?

That's the big question for SREs and cloud engineers these past few years. Indeed, microservices bring operational challenges in network communication that a service mesh can solve. But service meshes, for the most part, bring their own challenges when it comes to installation and operation.

One problem we can see emerging in many projects is that with service meshes, there is a gap between the proof-of-concept stage and the production stage. That is, it's unfortunately rare for companies to achieve staging environments that are identical to production in every aspect; with service meshes involving crucial infrastructure, scale- and edge-related effects can bring deployment surprises.

Service meshes are still under heavy development and improvement. This could actually be attractive for teams with high deployment velocities—those who have mastered “the art of staying state-of-the-art” and can closely follow the development cycle of cloud-native tools.

For others, though, the pace of service mesh evolution could be more of a pitfall. It would be easy enough to set up a service mesh but then forget about the need to maintain it. Security patches may go unapplied or, even if remembered, may carry with them unplanned issues in the form of deprecated features or a modified set of dependencies.

There's also a notable cost in terms of manpower to set up a service mesh in production. It would be a sensible goal for any team to evaluate this and understand if the benefits from a service mesh would outweigh the initial setup time. Service meshes are hard, no matter what the “easy” demo installations show.

In short, service meshes can solve some of the problems typical to projects deployed at scale but may introduce others, so be prepared to invest time and energy. In a hypothetical infrastructure involving 25 microservices and load of five queries per second, I would recommend having at least one person (preferably two) dedicated for at least a month to preparing a proof of concept and validating key aspects before thinking about running it in production. Once it's set up, anticipate the need for frequent upgrades—they will impact a core component of your infrastructure, namely network communications.

Kubernetes Service Meshes: A (Complex) Evolution in Scalable App Architecture

We've seen what service meshes are: a suite of tooling to answer new challenges introduced by microservices architecture. Through traffic management, observability, service discovery, and enhanced security, service meshes can reveal deep insights into app infrastructure.

There are multiple actors on the market, sometimes promoted by GAFAM et al., that have in some cases open-sourced or promoted their own internal tooling. Despite two different implementation types, service meshes will always have a control plane—the brain of the system—and a data plane, made of proxies that will intercept the requests of your application.

Reviewing the three biggest service meshes (Linkerd, Consul Connect, and Istio) we have seen the different strategies they've chosen to implement and the advantages they bring. Linkerd, being the oldest service mesh on the market, benefits from its creators' experience at Twitter. HashiCorp, for its part, offers the enterprise-ready Consul Connect, backed by a high level of expertise and support. Istio, which initially garnered ample attention online, has evolved into a mature project, delivering a feature-complete platform in the end.

But these actors are far from being the only ones, and some less-talked-about service meshes have emerged: Kuma, Traefik Mesh, and AWS App Mesh, among others. Kuma, from Kong, was created with the idea of making the service mesh idea “simple” and pluggable into any system, not just Kubernetes. Traefik Mesh benefited from experience with the preexisting Traefik Proxy and made the rare decision to eschew sidecar proxies. Last but not least, AWS decided to develop its own version of the service mesh, but one that relies on the dependable Envoy sidecar proxy.

In practice, service meshes are still hard to implement. Although service mesh benefits are compelling, their impact, critically, cuts both ways: Failure of a service mesh could render your microservices unable to communicate with each other, possibly bringing down your entire stack. A notorious example of this: Incompatibility between a Linkerd version and a Kubernetes version created a complete production outage at Monzo, an online bank.

Nonetheless, the whole industry is structuring itself around Kubernetes and initiatives like the Microsoft-spearheaded SMI, a standard interface for service meshes on Kubernetes. Among numerous other projects, the Cloud Native Computing Foundation (CNCF) has the Envoy-based Open Service Mesh (OSM) initiative, which was also originally introduced by Microsoft. The service mesh ecosystem remains abuzz, and I predict a champion emerging in the coming years, the same way Kubernetes became the de facto container orchestration tool.