Observabilidade: entendendo melhor o funcionamento de um sistema de microserviços com o Istio em um cluster Kubernetes

Objetivo: executar um “hello world” de monitoramento com o Istio, em um cluster na minha própria máquina usando o Minikube, pegando um projeto de microserviços de exemplo fornecido pelo Github do kodekloudhub e tentando trazer um destaque aos conceitos envolvidos.

Motivação: com base em uma experiência recente do nosso time em tentar buscar facilitar o monitoramento de um sistema em microserviços, o Istio demostrou ser muito poderoso e útil. E claro, sempre é bom ter a chance de poder compartilhar algum tipo de conhecimento com a comunidade.

Ok, bora lá. Antes de mais nada, vamos tentar analisar juntos o título:

“Observabilidade: entendendo melhor o funcionamento de um sistema de microserviços com o Istio em um cluster Kubernetes”

Basicamente, a ideia é entendermos um pouco melhor o sistema de microserviços como um todo, podendo responder algumas perguntas, como:

• Quais requisições foram enviadas por qual microserviço?
• Como cada requisição foi processada por cada microserviço?
• Quais foram os gargalos ?
• Qual foi o fluxo percorrido por uma requisição ?

Tudo isso é possível com o Istio.

“Nossa Ensley, mas eu tenho uma dúvida, o que é esse Istio? Ele só traz essa vantagem de observabilidade ?”

Muita calma jovem padawan. No site da própria Google Cloud, podemos ver uma boa definição do que é o Istio:

“O Istio é uma malha de serviço de código aberto que ajuda as organizações a executar aplicativos distribuídos baseados em microsserviços em qualquer lugar. Por que usar o Istio? Com o Istio, as organizações podem proteger, conectar e monitorar microsserviços para modernizar os aplicativos empresariais com mais rapidez e segurança.”

E sobre ele nos ajudar “somente” sobre a questão de observabilidade, a resposta é: não. Ele nos ajuda bastante a realmente visualizar melhor o tráfego entre os microserviços, mas além disso, existem outros três tópicos ele pode nos auxiliar bastante, sendo eles: Segurança, Controle e Conexão.

Para podermos ver um exemplo disso na prática, irei demostrar através de um exemplo de uma aplicação de microserviços, instalando-a em um cluster do Kubernetes (k8s), que tem se demonstrado uma ferramenta muito poderosa para automação e orquestração das operações de aplicativos em containers.

Preparando o ambiente

Para podermos subir um cluster no Kubernetes, poderíamos usar vários serviços de cloud como Google Cloud, Azure, AWS (fica a critério do “cliente”), mas afins de exemplo, vou usar o Minikube. Ele possibilidade subir um cluster de k8s local. Nesse link, tem um passo a passo de como instalar e quais requisitos são necessários para fazer usando seu computador. No meu caso, vou usar o Minikube junto com o VirtualBox.

Vamos precisar instalar mais algumas coisas, sendo elas:

• Kubectl: é a ferramenta que permite a gente executar comandos no terminal para o cluster do Kubernetes.
• make (opcional): basicamente, a gente vai executar algumas comandos já pré-configurados, pra facilitar nosso teste. Caso você não queria usar o make, pode abrir o Makefile do projeto e ver o que está sendo executado.
• Projeto do Github: podemos baixar ou clonar esse projeto que eu subi no meu repositório, que já tem uma configuração básica para podermos subir uma aplicação de microserviços no Kubernetes e ja instalar o Istio. Para ser possível acessar o Kiali (UI de telemetria do Istio) e vermos tudo funcionando.

Passo a passo

1. Vou clonar o projeto do Github:

git clone https://github.com/EnsleyEC/k8s-microservices-example

2. No diretório raiz do projeto k8s-microservices-example, podemos executar o comando make help e ver as opções para usarmos com o make.

3. Nesse momento, vou dar um start no cluster com o Minikube (e Virtualbox, no meu caso):

4. E agora, vou executar o comando para fazer deploy da aplicação de microserviços e do setup do Istio:

 make deploy-app

5. Depois de aguardar alguns minutos, vou executar o comando para checarmos o status de todos os pods do cluster:

Todos parecem estarem rodando (Running), que é o nosso esperado.

Ensley, uma dúvida, é normal todos os pods estarem com dois containers rodando (2/2) ?

Resposta: nesse caso, sim. Pois, um container está sendo da aplicação, e outro é um proxy do Istio (você pode ver dando um describe no Pod). Em que nesse momento, está coletando as métricas do tráfego entre os serviços, para que possamos analisar posteriormente. Podemos dizer que o “jump of the cat” do Istio, é ele. Portando, ele tem vários poderes. Esse container, ele sobe depois de fazermos o deploy da stack de microserviços no namespace que tem a seguinte label: istio-injection=enabled. No qual, estamos habilitando dentro do Makefile com o seguinte comando:

kubectl label namespace default istio-injection=enabled

6. E agora, vamos brincar com a aplicação que está rodando. Com o objetivo de simular uma requisição no sistema e depois observarmos os resultados com o Istio. Basicamente, temos duas telas de frontend: uma pra poder votar (entre cats ou dogs) e a outra para ver o resultado dos votos contabilizados.

Nesse caso, vou executar um voto clicando em um dos botões de Cats ou Dogs, para podermos simular uma requisição ao sistema.

Resultado:

7. Agora, pegando a URL do Kiali, vamos acessar ele no navegador e ver como ficou algumas das telemetrias do sistema:

No Kiali, você pode ir navegando e conhecendo a aplicação. Mas dando ênfase na tela de Graph, podemos ver o fluxo que foi feito pela requisição através dos serviços.

Observação: caso tenha dúvida dos ícones, basta clicar no botão de “Legend”.

E na aba Applications, podemos ver métricas mais detalhadas por aplicação.

Conclusão

Podemos ver claramente que o Istio com o Kiali, podem facilitar bastante, desde a etapa de entender qual serviço está rodando e com quem ele está comunicando no sistema. Até o fato de conseguirmos olhar de forma mais detalhada as métricas de tráfego coletadas. Na situação atual, em que grande parte das aplicações estão na arquitetura de microserviços, isso ajuda muito.