“A ideia do microserviço é desacoplar tudo o que for possível desacoplar… então o pattern sonhado é ter microserviços com um banco de dados próprio. Mas, nem sempre dá pra fazer isso”, comenta Andre Rocha, CTO do Reclame Aqui. Desenvolvedor há 18 anos, Andre conta que se “encantou” com o Kubernetes há um ano e meio. Fuçando seus recursos, porém, ele se deu conta de que, afinal, nem tudo é possível fazer usando “apenas” Kubernetes ou microserviços.
E é aí que surgiu o service mesh como um componente crítico da cloud nativa: usando Kubernetes, é muito mais fácil integrar o service mesh ao ambiente. A ideia do service mesh é fazer com que um pod se comunique com outro pod, sem depender de uma camada de serviços para o balanceamento. “Dentro da nossa aplicação, não preciso mais de todas as implementações de service discovery, tracing, circuit breaker etc”, explica Andre Rocha. E porque isso importa?
Entre as principais vantagens de usar o Service Mesh com Kubernetes, de acordo com André Rocha:
“Ao invés de se basear em métricas do container ou métricas de consumo de resource do pod, o desenvolvedor pode se basear em quantidade de requests, características dessas requests e outras que a aplicação é capaz de entregar (e não o nó)”.
“Para quem trabalha com aplicação baseada em evento, isso é muito crítico”.
“É possível implementar uma camada de serviços misturada entre aplicações Node.JS com Java, PHP, e outras, que todas vão compartilhar dos mesmos recursos que o Service Mesh oferece”.
“Basicamente, quando você tem todos esses módulos acoplados à sua aplicação, vai precisar refatorar todas as suas aplicações. Se você tem 30 aplicações para refatorar, fazer o upgrade do protocolo é bastante trabalhoso. Então você pode fazer isso na camada de infraestrutura”.
“Só o fato de instalar um serviço de service mesh no seu cluster te capacita a entender a característica das requisições que estão trafegando dentro do seu cluster. Sem precisar implementar um agente, nem nada: só o fato de ter o service mesh dentro do Kubernetes, ele já resolverá isso para você”.
“Você não precisa cuidar mais disso na camada de aplicação”.
“Todos os projetos de service mesh estão dentro dela. O que vai acontecer é que o sistema do Kubernetes vai acabar indo nessa direção, no fim das contas. Tudo o que se for fazer em termos de metrificação, rastreabilidade, escalabilidade, tudo vai convergir para isso, se continuarem nesse caminho, logicamente”.
Os dois mais populares são Istio e Linkerd; André focou sua palestra nos recursos do Istio, conforme descrito abaixo:
Envoy
Negocia todas as requisições entre os serviços
Negocia TLS
Suporta http1/2 e gRPC
Orquestração dinâmica de deploy
Ativa e inativa regras de Circuit Breaker
Fornece métricas para rastreabilidade e observabilidade
Implantação via Sidecar
Trabalha em conjunto com Pilot para SD/SR
Mixer
Coleta métricas do ecossistema do Istio
Coleta métricas de telemetria dos serviços
Coleta métricas de observabilidade
Aplica regras de QoS
Suporta http1/2 e gRPC
Gerencia enforce de políticas de acesso
Fornece interface de integração via plugin
Pilot
Fornece o mecanismo de Service Discovery para os Sidecars (Envoy)
Orquestra o tráfego entre os serviços para capacitar fluxos de deploy canario, teste A/B etc.
Indica, balanceia e estimula as políticas de Circuit Breaker
É equivalente ao Eureka Server da Netflix
Citadel
Fornece o mecanismo de autenticação/autorização entre os serviços
Oferece integração com o RBAC para enforcement baseado em contas de serviço do cluster
André palestrou no meetup Linuxtips na semana passada, que teve o Kubernetes como tema central: https://www.meetup.com/LINUXtips/events/251182387/
Abaixo, você assiste à íntegra da palestra no evento:
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.