Service Mesh com Istio

Se você busca criar uma arquitetura de microsserviços moderna, que é altamente escalável, observável, segura e resiliente, faria sentido considerar algumas das tecnologias de service mesh que estão evoluindo rapidamente agora. No momento em que este texto foi escrito, o Istio é um dos frameworks mais adotados e é um concorrente chave na corrida de service mesh.

Esse texto é uma tradução autorizada do artigo escrito por Anuradha Weeraman. Para acessar a versão original em inglês, clique aqui.

Para aqueles que são novos no assunto, uma service mesh é uma camada de infraestrutura entre um serviço e uma rede que libera os desenvolvedores das considerações de políticas e de rede e fornece aos operadores controles para monitoramento, aplicação de políticas, networking e considerações sobre resiliência.

A service mesh faz isso pegando o padrão existente do proxy reverso central, que fica na frente de um grande número de serviços, e coloca uma variante dele mais leve com cada serviço individual. Além de ser um proxy reverso, esse proxy de “sidecar” (assim chamado devido ao fato de que ele fica ao lado de cada serviço em uma configuração fortemente ligada) é capaz de executar roteamento de tráfego, comunicação entre serviços, aplicação de políticas, controle de fluxo e uma miríade de outros recursos que tornam esse padrão muito poderoso.

Fonte: https://www.infoq.com/presentations/istio-service-mesh

Toda a comunicação dentro e fora do serviço é mediada por meio do sidecar, que agora é capaz de realizar vários recursos de cross cutting que tanto liberam o desenvolvedor dos aspectos de rede quanto capacitam os operadores para aplicarem uniformemente os recursos que lhes dizem respeito.

O Istio se baseia em um sidecar testado em campo conhecido como Envoy, desenvolvido e usado em produção na Lyft por muitos anos. Construído usando C++, possui baixo consumo de memória e suporta atualizações dinâmicas de configuração, balanceamento de carga com reconhecimento de zona, divisão de tráfego, roteamento, circuit breakers, timeouts, repetições, injeção de falhas, HTTP / 2, gRPC e orquestrados através da rede por um “Pilot”.

Fonte: https://www.infoq.com/presentations/istio-service-mesh

O Pilot, o Mixer e o CA constituem o plano de controle através do qual todos os fluxos de configuração, aplicação de políticas e controle acontecem. O plano de dados consiste de todos os Envoy proxies que mediam todas as solicitações de serviço e comunicações de dados.

Cada Envoy publica métricas para um “Mixer”, que possui adaptadores para backends populares de monitoramento, um bem conhecido é o prometheus. O Mixer também é usado para avaliação de políticas, implementação de cotas e limitação de taxas.

Fonte: https://www.infoq.com/presentations/istio-service-mesh

O Envoy, sendo um proxy reverso tanto de Camada 4 quanto de Camada 7, é capaz de realizar controle de tráfego complexo com base em regras colocadas pelos operadores e pode ser construído para funcionar imediatamente, sem reinicialização. Isso torna a infraestrutura extremamente ágil para a equipe de operações. Por exemplo, abaixo está um exemplo de como 1% do tráfego pode ser roteado para uma rota alternativa para teste A/B:

Fonte: https://www.infoq.com/presentations/istio-service-mesh

Isso seria possível forçando a seguinte mudança de política para o Envoy:

Fonte: https://www.infoq.com/presentations/istio-service-mesh

O Envoy também pode realizar roteamento L7 para direcionamento de tráfego com base em cabeçalhos HTTP, como no cenário abaixo:

Fonte: https://www.infoq.com/presentations/istio-service-mesh

O Envoy também cuida da geração de spans e da sua integração com ferramentas como Zipkin que fornece recursos de rastreamento distribuído, o que torna a observação uma interação distribuída complicada e a correlação de causalidade um recurso da service mesh e não algo que os desenvolvedores devem se responsabilizar individualmente e incorporar em seus serviços.

As métricas capturadas pelos backends de monitoramento podem ser visualizadas por meio de muitas das ferramentas existentes disponíveis, como Grafana, para uma visualização em tempo real do estado e da saúde da service mesh.

Uma das principais diferenças nesse modelo, em comparação com o middle proxy centralizado é que o sidecar está vinculado ao mesmo domínio de confiança que o serviço individual e, no caso de um acordo, isso reduz a superfície de ataque. Em segundo lugar, essa arquitetura também permite que os serviços implementem políticas de granularidade fina em torno da comunicação entre serviços que usa identidades verificáveis ​​por meio de criptografia em vez de elementos que podem ser falsificados por um usuário experiente.

Por exemplo, o serviço A pode ser configurado para ter permissão apenas para chamar o serviço B, e a interação será regida e determinada pelo proxy por meio do uso de certificados TLS mútuos com a Istio CA. Anteriormente, esse tipo de aplicação de política era complicado em ambientes altamente dinâmicos, como plataformas de orquestração, onde os endereços IP mudam com frequência e a carga de trabalho tende a ser altamente móvel. Isso tornou os sistemas muito difíceis de proteger contra ataques internos, pois não havia identidade inerente vinculada ao serviço que pudesse ser criptograficamente assegurada no momento da execução.

Fonte: https://www.infoq.com/presentations/istio-service-mesh

No caso de um possível comprometimento da segurança, os certificados vinculados às identidades podem ser revogados individualmente, proporcionando um controle de granularidade fina sobre o “raio da explosão”.

No momento em que o artigo foi escrito, o Istio está na versão 0.6 e não atingiu o GA. Contudo, é definitivamente uma tecnologia para ficar de olho.

Autor: Anuradha Weeraman

fique atualizado

Assine nossa newsletter e acompanhe as nossas novidades.

© 2019 Opus Software. Todos os direitos reservados. All rights reserved.