🥇De volta aos microsserviços com Istio. Parte 1

Nota do tradutor.: As service meshes definitivamente se tornaram uma solução relevante na infraestrutura moderna para aplicativos que seguem a arquitetura de microserviços. Embora o Istio possa estar na mente de muitos engenheiros de DevOps, é um produto relativamente novo que, sendo complexo em termos de funcionalidades oferecidas, pode exigir um tempo considerável para ser compreendido. O engenheiro alemão Rinor Maloku, responsável pela computação em nuvem para grandes clientes na empresa de telecomunicações Orange Networks, escreveu uma interessante série de materiais que permitem mergulhar rapidamente e em profundidade no Istio. Ele começa sua narrativa explicando o que o Istio realmente faz e como é possível vê-lo rapidamente com seus próprios olhos.

Istio — Um projeto Open Source, desenvolvido em colaboração entre equipes do Google, IBM e Lyft. Ele resolve as complexidades que surgem em aplicativos baseados em microserviços, como:

Gerenciamento de tráfego: timeouts, tentativas de repetição, balanceamento de carga;
Segurança: autenticação e autorização do usuário final;
Observabilidade: rastreamento, monitoramento, registro.

Todos eles podem ser resolvidos no nível do aplicativo, no entanto, após isso, seus serviços deixarão de ser "micro". Todo o esforço adicional para resolver esses problemas é um desperdício de recursos da empresa que poderiam ser usados diretamente para gerar valor comercial. Vamos considerar um exemplo:

Gerente de Projetos: Quanto tempo levará para adicionar a funcionalidade de feedback?
Desenvolvedor: Dois sprints.
GP: O que?.. Isso é apenas CRUD!
D: Fazer CRUD é a parte simples da tarefa, mas ainda precisamos autenticar e autorizar usuários e serviços. Como a rede é instável, será necessário implementar tentativas de repetição, além de padrão de circuit breaker nos clientes. Além disso, para garantir que todo o sistema não cairá, serão necessários timeouts e bulkheads (mais detalhes sobre ambos os padrões mencionados a seguir no artigo - nota do tradutor), e para detectar problemas, será necessário monitoramento, rastreamento, […]
GP: Ah, então vamos simplesmente inserir esse recurso no serviço Product.

Acredito que a ideia está clara: o volume de etapas e esforços necessários para adicionar um serviço é imenso. Neste artigo, vamos explorar como o Istio elimina todas as complexidades mencionadas (não relacionadas à lógica de negócios) dos serviços.

Nota: O artigo pressupõe que você possui conhecimentos práticos sobre Kubernetes. Caso contrário, recomendo a leitura de minha introdução ao Kubernetes e só então continuar com a leitura deste material.

A ideia do Istio

Em um mundo sem Istio, um serviço faz solicitações diretas a outro, e em caso de falha, o serviço deve lidar por conta própria: tentar novamente, considerar um timeout, abrir um circuit breaker, etc.

O tráfego de rede no Kubernetes

O Istio oferece uma solução especializada, totalmente independente dos serviços, funcionando através da intervenção na comunicação de rede. E assim, ele implementa:

Resiliência: baseado no código de status na resposta, ele entende se houve falha na solicitação e a repete.
Implantações canary: redireciona apenas uma proporção fixa de solicitações para a nova versão do serviço.
Monitoramento e métricas: quanto tempo o serviço levou para responder?
Rastreamento e observabilidade: adicione cabeçalhos especiais a cada solicitação e rastreie-os no cluster.
Segurança: extrai o token JWT, autentica e autoriza os usuários.

Estas são apenas algumas das capacidades (realmente apenas algumas!), para despertar seu interesse. E agora, vamos nos aprofundar nos detalhes técnicos!

Arquitetura do Istio

O Istio intercepta todo o tráfego de rede e aplica um conjunto de regras, inserindo um proxy inteligente em cada pod na forma de um contêiner sidecar. Os proxies que ativam todas as funcionalidades formam Data Plane, e podem ser configurados dinamicamente através de Control Plane.

Data Plane

Os proxies inseridos nos pods permitem que o Istio facilmente atenda aos requisitos necessários. Por exemplo, vamos verificar as funções de tentativas e circuit breaker.

Como retries e circuit breaking são implementados no Envoy

Resumindo:

Envoy (refere-se ao proxy localizado no contêiner sidecar, que também é distribuído como um produto separado — nota do tradutor.) envia uma solicitação para a primeira instância do serviço B e ocorre uma falha.
O Envoy Sidecar realiza uma nova tentativa (retry). (1)
A solicitação com falha é retornada ao proxy que a originou.
Assim se abre o Circuit Breaker e ocorre a chamada do próximo serviço para solicitações subsequentes. (2)

Isso significa que você não precisará usar mais uma biblioteca de Retry, não precisará fazer sua própria implementação de Circuit Breaking e Service Discovery na linguagem de programação X, Y ou Z. Tudo isso e muito mais está disponível pronto para uso no Istio e não requer nenhuma mudança no código.

Ótimo! Agora você pode querer embarcar em uma jornada com o Istio, mas ainda há algumas dúvidas, perguntas em aberto. Se essa é uma solução universal para todas as ocasiões, você começa a ter uma suspeita legítima: afinal, todas essas soluções acabam sendo inadequadas para algum caso.

E então finalmente você pergunta: "É configurável?"

Agora você está pronto para a viagem marítima — e vamos conhecer o Control Plane.

Control Plane

Ele consiste em três componentes: Pilot, Mixer e Citadel, — que juntos configuram os Envoys para roteamento de tráfego, aplicam políticas e coletam dados de telemetria. Esquematicamente, tudo isso se parece com isso:

Interação do Control Plane com o Data Plane

Os Envoys (ou seja, o data plane) são configurados usando Kubernetes CRD (Definições de Recursos Personalizados), definidos pelo Istio e especialmente projetados para esse propósito. Para você, isso significa que eles são apresentados como mais um recurso no Kubernetes com uma sintaxe familiar. Após a criação, esse recurso será associado ao control plane e aplicado aos Envoys.

Relação dos serviços com o Istio

Descrevemos a relação do Istio com os serviços, mas não o contrário: como os serviços se relacionam com o Istio?

Sinceramente, os serviços conhecem a presença do Istio tão bem quanto os peixes conhecem a água, quando se perguntam: "O que é água, afinal?".

Ilustração Victoria Dimitrakopoulos: — Como está a água? — O que é água, afinal?

Dessa forma, você pode pegar um cluster em funcionamento e, após a implantação dos componentes do Istio, os serviços nele continuarão a funcionar, e após a remoção desses componentes — tudo voltará a ser normal. É claro que, ao fazer isso, você perderá as funcionalidades oferecidas pelo Istio.

Chega de teoria — vamos levar esse conhecimento à prática!

Istio na prática

O Istio requer um cluster Kubernetes que pelo menos tenha 4 vCPU e 8 GB de RAM disponíveis. Para levantar rapidamente um cluster e seguir as instruções do artigo, recomendo usar o Google Cloud Platform, que oferece aos novos usuários. grátis $300.

Após criar o cluster e configurar o acesso ao Kubernetes através da ferramenta de linha de comando, você pode instalar o Istio usando o gerenciador de pacotes Helm.

Instalação do Helm

Instale o cliente Helm em seu computador, como descrito em documentação oficial. Nós o utilizaremos para gerar os templates para a instalação do Istio na próxima seção.

Instalação do Istio

Baixe os recursos do Istio de última versão (o link original da versão 1.0.5 foi atualizado para a atual, ou seja, 1.0.6 — nota do tradutor), extraia o conteúdo em um diretório que eu chamarei daqui para frente de [istio-resources].

Para simplificar a identificação dos recursos do Istio, crie um namespace no cluster K8s istio-system:

$ kubectl create namespace istio-system

Finalize a instalação navegando até o diretório [istio-resources] e executando o comando:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

Este comando exportará os principais componentes do Istio para o arquivo istio.yaml. Nós modificamos o template padrão para atender às nossas necessidades, especificando os seguintes parâmetros:

global.mtls.enabled configurada como falso (ou seja, a autenticação mTLS está desativada — nota do tradutor), para simplificar nosso processo de aprendizado;
tracing.enabled ativa a rastreabilidade das requisições com Jaeger;
kiali.enabled instala o Kiali no cluster para visualizar serviços e tráfego;
grafana.enabled instala o Grafana para visualizar as métricas coletadas.

Aplicaremos os recursos gerados com o comando:

$ kubectl apply -f istio.yaml

A instalação do Istio no cluster foi concluída! Aguarde até que todos os pods no namespace istio-system estejam no estado Em execução ou Completed, executando o comando abaixo:

$ kubectl get pods -n istio-system

Agora estamos prontos para continuar na próxima seção, onde levantaremos e executaremos o aplicativo.

Arquitetura do aplicativo Análise de Sentimento

Usaremos o exemplo do aplicativo de microserviços Análise de Sentimento, utilizado na já mencionada artigo de introdução ao Kubernetes. Ele é complexo o suficiente para demonstrar as capacidades do Istio na prática.

O aplicativo é composto por quatro microserviços:

Serviço SA-Frontend, que serve o frontend do aplicativo em Reactjs;
Serviço SA-WebApp, que lida com as requisições de Análise de Sentimento;
Serviço SA-Logic, que realiza a própria análise de sentimento;;
Serviço SA-Feedback, que recebe feedback dos usuários sobre a precisão da análise realizada.

Neste diagrama, além dos serviços, também vemos o Ingress Controller, que no Kubernetes roteia as solicitações de entrada para os serviços correspondentes. No Istio, uma conceito semelhante é usado no Ingress Gateway, cujos detalhes serão fornecidos a seguir.

Executando um aplicativo com o proxy do Istio

Para as operações subsequentes mencionadas neste artigo, clone o repositório istio-mastery. Ele contém o aplicativo e os manifestos para Kubernetes e Istio.

Inserção de sidecars

A inserção pode ser feita automaticamente ou manualmente. Para a inserção automática de contêineres sidecar, será necessário rotular o espaço de nomes istio-injection=enabled, o que pode ser feito com o seguinte comando:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

Agora, cada pod que for implantado no espaço de nomes padrão (padrão) receberá seu contêiner sidecar. Para verificar isso, vamos implantar um aplicativo de teste, navegando até o diretório raiz do repositório . Neste branch, o código do frontend foi alterado para redirecionar os usuários para o Auth0 para autenticação e usar o token JWT nas requisições para os outros serviços. Isso foi implementado da seguinte forma ( e executando o seguinte comando:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

Após o desdobramento dos serviços, vamos verificar se os pods têm dois contêineres (com o próprio serviço e seu sidecar), executando o comando kubectl get pods e confirmando que sob a coluna READY está indicado o valor 2/2, que simboliza que ambos os contêineres estão em execução:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

Visualmente, isso é apresentado assim:

Proxy Envoy em um dos pods

Agora que o aplicativo está em execução e funcionando, precisaremos permitir que o tráfego de entrada chegue ao aplicativo.

Ingress Gateway

A melhor prática para conseguir isso (permitir o tráfego no cluster) é através do Ingress Gateway no Istio, que está localizado na "fronteira" do cluster e permite habilitar funções Istio como roteamento, balanceamento de carga, segurança e monitoramento para o tráfego de entrada.

O componente Ingress Gateway e o serviço que o expõe externamente foram instalados no cluster durante a instalação do Istio. Para descobrir o endereço IP externo do serviço, execute:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NOME                   TIPO           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Vamos acessar a aplicação por este IP a partir de agora (eu me referirei a ele como EXTERNAL-IP), então, para facilitar, vamos armazenar o valor em uma variável:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

Se você tentar acessar este IP pelo navegador, receberá o erro Service Unavailable, pois por padrão, o Istio bloqueia todo o tráfego de entrada, até que um Gateway seja definido.

Recurso Gateway

Gateway é uma CRD (Definição de Recurso Personalizado) no Kubernetes, definida após a instalação do Istio no cluster e que ativa a capacidade de especificar portas, protocolos e hosts para os quais queremos permitir o tráfego de entrada.

No nosso caso, queremos permitir tráfego HTTP na porta 80 para todos os hosts. A tarefa é realizada pela seguinte definição (http-gateway.yaml):

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

Essa configuração não precisa de explicações, exceto pelo seletor istio: ingressgateway. Com esse seletor, podemos especificar a qual Ingress Gateway aplicar a configuração. No nosso caso, este é o controlador Ingress Gateway que foi instalado por padrão no Istio.

A configuração é aplicada chamando o seguinte comando:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

Agora o gateway permite acesso à porta 80, mas não tem noção de para onde direcionar as solicitações. Para isso, serão necessários Serviços Virtuais.

Recurso VirtualService

O VirtualService indica ao Ingress Gateway como direcionar as solicitações que são permitidas dentro do cluster.

As solicitações para a nossa aplicação, que chegam através do http-gateway, devem ser enviadas para os serviços sa-frontend, sa-web-app e sa-feedback:

Rotas que precisam ser configuradas com VirtualServices

Vamos considerar as solicitações que devem ser direcionadas ao SA-Frontend:

Uma correspondência exata pelo caminho / deve ser enviada ao SA-Frontend para obter index.html;
Caminhos com prefixo /static/* devem ser enviados ao SA-Frontend para obter arquivos estáticos usados no frontend, como CSS e JavaScript;
Caminhos que correspondem à expressão regular '^.*.(ico|png|jpg)$', devem ser enviados ao SA-Frontend, pois são imagens exibidas na página.

A implementação é alcançada pela seguinte configuração (sa-virtualservice-external.yaml):

kind: VirtualService metadata: name: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: \/ - uri: exact: \/callback - uri: prefix: \/static - uri: regex: '^.*.(ico|png|jpg) Pontos importantes: Este VirtualService se refere a requisições que chegam através de http-gateway; Em destino é determinado o serviço para onde as solicitações são enviadas. Nota: A configuração acima é armazenada em um arquivo sa-virtualservice-external.yaml, que também contém as configurações para roteamento no SA-WebApp e SA-Feedback, mas foi abreviado aqui no artigo para concisão. Aplicamos o VirtualService com a chamada: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services criado Nota: Quando aplicamos os recursos do Istio, o Servidor de API do Kubernetes cria um evento que é recebido pelo Planejamento de Controle do Istio, e somente depois disso a nova configuração é aplicada aos servidores proxy Envoy de cada pod. E o controlador de Ingress Gateway é representado por mais um Envoy, configurado no Planejamento de Controle. Tudo isso se apresenta na seguinte diagrama: Configuração do Istio-IngressGateway para roteamento de solicitações O aplicativo de Análise de Sentimento está disponível em http://{EXTERNAL-IP}/. Não se preocupe se você receber o status Not Found: às vezes leva um pouco mais de tempo para a configuração ter efeito e os caches do Envoy serem atualizados. Antes de continuar, trabalhe um pouco com o aplicativo para gerar tráfego (sua presença é necessária para clareza nas próximas ações — nota do tradutor). Kiali: observabilidade Para acessar a interface administrativa do Kiali, execute o seguinte comando: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … e abra http://localhost:20001/, logando como admin/admin. Aqui você encontrará muitas funcionalidades úteis, como verificar a configuração dos componentes do Istio, visualizar serviços com informações coletadas ao interceptar solicitações de rede, obter respostas para perguntas como "Quem se comunica com quem?", "Qual versão do serviço está falhando?" etc. Em resumo, explore as funcionalidades do Kiali antes de seguir em frente — para a visualização de métricas com o Grafana. Grafana: visualização de métricas As métricas coletadas no Istio vão para o Prometheus e são visualizadas com o Grafana. Para acessar a interface administrativa do Grafana, execute o comando abaixo e depois abra http://localhost:3000/: $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath={.items[0].metadata.name}) 3000 Clique no menu Home no canto superior esquerdo e selecione Istio Service Dashboard no canto superior esquerdo, comece a partir do serviço sa-web-app, para ver as métricas coletadas: Aqui temos uma apresentação vazia e completamente monótona — a equipe de redação nunca aprovaria algo assim. Vamos criar uma carga leve com o seguinte comando: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "Eu amo yogobella"}'; sleep .8; done Agora temos gráficos muito mais bonitos, além de ótimas ferramentas como Prometheus para monitoramento e Grafana para visualização de métricas, que nos permitirão conhecer a performance, o estado de saúde, e as melhorias/degradações nos serviços ao longo do tempo. Finalmente, vamos olhar para o rastreamento de solicitações nos serviços. Jaeger: rastreamento Precisamos de rastreamento, pois quanto mais serviços temos, mais difícil é identificar a causa de uma falha. Vamos ver um exemplo simples da imagem abaixo: Exemplo típico de uma solicitação falha aleatória A solicitação chega e falha — qual é a razão? O primeiro serviço? Ou o segundo? Ambos têm exceções — vamos olhar os logs de cada um. Com que frequência você se pegou fazendo isso? Nosso trabalho se assemelha mais ao de detetives de software do que ao de desenvolvedores… Esse é um problema comum em microserviços e é resolvido por sistemas de rastreamento distribuído, onde os serviços transmitem entre si um cabeçalho único, e essa informação é direcionada para o sistema de rastreamento, onde é associada aos dados da solicitação. Aqui está uma ilustração: O TraceId é utilizado para identificar a solicitação No Istio, usamos o Jaeger Tracer, que implementa uma framework OpenTracing independente de vendedores. Para acessar a interface do usuário do Jaeger, você pode usar o seguinte comando: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Agora, acesse http://localhost:16686/ e escolha o serviço sa-web-app. Se o serviço não aparecer no menu suspenso — gere alguma atividade na página e atualize a interface. Depois disso, clique no botão Find Traces, que mostrará os rastros mais recentes — escolha qualquer um — serão exibidas informações detalhadas sobre todos os rastros: Esse rastro mostra: A solicitação chega ao istio-ingressgateway (esta é a primeira interação com um dos serviços, e o Trace ID é gerado para a solicitação), após o que o gateway encaminha a solicitação para o serviço sa-web-app. No serviço sa-web-app a solicitação é capturada pelo Envoy sidecar, um 'filho' é criado no span (por isso o vemos nos rastros) e é encaminhada para o contêiner sa-web-app. (Span — uma unidade lógica de trabalho no Jaeger, contendo um nome, hora de início da operação e sua duração. Os spans podem ser aninhados e ordenados. Um grafo acíclico orientado de spans forma um trace. — nota do tradutor) Aqui a solicitação é processada pelo método sentimentAnalysis. Esses traces já foram gerados pelo aplicativo, ou seja, foram necessárias alterações no código. A partir deste momento, uma solicitação POST é iniciada em sa-logic. O ID do trace deve ser passado a partir de sa-web-app. … Nota: No passo 4, o aplicativo deve reconhecer os cabeçalhos gerados pelo Istio e passá-los nas solicitações subsequentes, como mostrado na imagem abaixo: (A) A passagem de cabeçalhos é responsabilidade do Istio; (B) Os cabeçalhos são responsabilidade dos serviços O Istio faz o trabalho principal, pois gera cabeçalhos para as solicitações de entrada, cria novos spans em cada sidecar e os transmite. No entanto, sem lidar com os cabeçalhos dentro dos serviços, o caminho completo da rastreabilidade da solicitação será perdido. É necessário considerar (transmitir) os seguintes cabeçalhos: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context Essa não é uma tarefa complicada, mas para simplificar sua implementação já existem várias bibliotecas — por exemplo, no serviço sa-web-app, o cliente RestTemplate transmite esses cabeçalhos se apenas adicionar as bibliotecas Jaeger e OpenTracing a suas dependências. Note que o aplicativo Sentiment Analysis demonstra implementações em Flask, Spring e ASP.NET Core. Agora, que ficou claro o que recebemos pronto para uso (ou quase ‘pronto para uso’), vamos considerar questões de roteamento ajustável, gerenciamento de tráfego de rede, segurança, etc.! Nota do tradutor.: sobre isso, leia na próxima parte dos materiais sobre Istio de Rinor Maloku, cujas traduções seguirão em nosso blog em breve. ATUALIZAÇÃO (14 de março): A segunda parte já foi publicada. P.S. do tradutor Confira também em nosso blog: «De Volta aos Microserviços com Istio»: parte 2 (roteamento, gerenciamento de tráfego), parte 3 (autenticação e autorização); «Conduit — um service mesh leve para Kubernetes»; «O que é um service mesh e por que eu preciso [para uma aplicação em nuvem com microserviços]?»; «Guia ilustrado para configuração de rede no Kubernetes. Parts 1 e 2»; «Como esse container sidecar chegou aqui [no Kubernetes]?». Fonte: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Pontos importantes:

Este VirtualService se refere a requisições que chegam através de http-gateway;
Em destino é determinado o serviço para onde as solicitações são enviadas.

Nota: A configuração acima é armazenada em um arquivo sa-virtualservice-external.yaml, que também contém configurações para roteamento no SA-WebApp e SA-Feedback, mas foi reduzido aqui no artigo para concisão.

Aplique o VirtualService chamando:

Nota: Quando aplicamos os recursos do Istio, o Kubernetes API Server cria um evento, que é recebido pelo Istio Control Plane, e só depois disso a nova configuração é aplicada aos proxies Envoy de cada pod. E o controlador Ingress Gateway é representado por mais um Envoy, configurado no Control Plane. Tudo isso na diagramação se apresenta assim:

Configuração do Istio-IngressGateway para roteamento de solicitações

O aplicativo de Análise de Sentimento está disponível em http://{EXTERNAL-IP}/. Não se preocupe se você receber o status Not Found: às vezes leva um pouco mais de tempo para a configuração ter efeito e os caches do Envoy serem atualizados.

Antes de continuar, trabalhe um pouco com o aplicativo para gerar tráfego (sua presença é necessária para clareza nas próximas ações — nota do tradutor).

Kiali: observabilidade

Para acessar a interface administrativa do Kiali, execute o seguinte comando:

… e abra http://localhost:20001/, logando como admin/admin. Aqui você encontrará muitas funcionalidades úteis, como verificar a configuração dos componentes do Istio, visualizar serviços com informações coletadas ao interceptar solicitações de rede, obter respostas para perguntas como "Quem se comunica com quem?", "Qual versão do serviço está falhando?" etc. Em resumo, explore as funcionalidades do Kiali antes de seguir em frente — para a visualização de métricas com o Grafana.

Grafana: visualização de métricas

As métricas coletadas no Istio vão para o Prometheus e são visualizadas com o Grafana. Para acessar a interface administrativa do Grafana, execute o comando abaixo e depois abra http://localhost:3000/:

Clique no menu Home no canto superior esquerdo e selecione Istio Service Dashboard no canto superior esquerdo, comece a partir do serviço sa-web-app, para ver as métricas coletadas:

Aqui temos uma apresentação vazia e completamente monótona — a equipe de redação nunca aprovaria algo assim. Vamos criar uma carga leve com o seguinte comando:

Agora temos gráficos muito mais bonitos, além de ótimas ferramentas como Prometheus para monitoramento e Grafana para visualização de métricas, que nos permitirão conhecer a performance, o estado de saúde, e as melhorias/degradações nos serviços ao longo do tempo.

Finalmente, vamos olhar para o rastreamento de solicitações nos serviços.

Jaeger: rastreamento

Precisamos de rastreamento, pois quanto mais serviços temos, mais difícil é identificar a causa de uma falha. Vamos ver um exemplo simples da imagem abaixo:

Exemplo típico de uma solicitação falha aleatória

A solicitação chega e falha — qual é a razão? O primeiro serviço? Ou o segundo? Ambos têm exceções — vamos olhar os logs de cada um. Com que frequência você se pegou fazendo isso? Nosso trabalho se assemelha mais ao de detetives de software do que ao de desenvolvedores…

Esse é um problema comum em microserviços e é resolvido por sistemas de rastreamento distribuído, onde os serviços transmitem entre si um cabeçalho único, e essa informação é direcionada para o sistema de rastreamento, onde é associada aos dados da solicitação. Aqui está uma ilustração:

O TraceId é utilizado para identificar a solicitação

No Istio, usamos o Jaeger Tracer, que implementa uma framework OpenTracing independente de vendedores. Para acessar a interface do usuário do Jaeger, você pode usar o seguinte comando:

Agora, acesse http://localhost:16686/ e escolha o serviço sa-web-app. Se o serviço não aparecer no menu suspenso — gere alguma atividade na página e atualize a interface. Depois disso, clique no botão Find Traces, que mostrará os rastros mais recentes — escolha qualquer um — serão exibidas informações detalhadas sobre todos os rastros:

Esse rastro mostra:

A solicitação chega ao istio-ingressgateway (esta é a primeira interação com um dos serviços, e o Trace ID é gerado para a solicitação), após o que o gateway encaminha a solicitação para o serviço sa-web-app.
No serviço sa-web-app a solicitação é capturada pelo sidecar Envoy, um "filho" é criado no span (é por isso que o vemos nos traços) e é redirecionado para o contêiner sa-web-app. (Span — uma unidade lógica de trabalho no Jaeger, que possui um nome, um horário de início da operação e sua duração. Os spans podem ser aninhados e organizados. Um grafo acíclico orientado de spans forma um trace. — nota do tradutor)
Aqui a solicitação é processada pelo método sentimentAnalysis. Esses traces já foram gerados pelo aplicativo, ou seja, foram necessárias alterações no código.
A partir deste momento, uma solicitação POST é iniciada em sa-logic. O ID do trace deve ser passado a partir de sa-web-app.
…

Nota: No passo 4, o aplicativo deve reconhecer os cabeçalhos gerados pelo Istio e passá-los nas solicitações subsequentes, como mostrado na imagem abaixo:

(A) A passagem de cabeçalhos é responsabilidade do Istio; (B) Os cabeçalhos são responsabilidade dos serviços

O Istio faz o trabalho principal, pois gera cabeçalhos para as solicitações de entrada, cria novos spans em cada sidecar e os repassa. No entanto, sem trabalhar com os cabeçalhos dentro dos serviços, todo o caminho de rastreamento da solicitação será perdido.

É necessário considerar (transmitir) os seguintes cabeçalhos:

Essa não é uma tarefa complicada, mas para simplificar sua implementação já existem várias bibliotecas — por exemplo, no serviço sa-web-app, o cliente RestTemplate transmite esses cabeçalhos se apenas adicionar as bibliotecas Jaeger e OpenTracing a suas dependências.

Note que o aplicativo Sentiment Analysis demonstra implementações em Flask, Spring e ASP.NET Core.

Agora, que ficou claro o que recebemos pronto para uso (ou quase ‘pronto para uso’), vamos considerar questões de roteamento ajustável, gerenciamento de tráfego de rede, segurança, etc.!

Nota do tradutor.: sobre isso, leia na próxima parte dos materiais sobre Istio de Rinor Maloku, cujas traduções seguirão em nosso blog em breve. ATUALIZAÇÃO (14 de março): A segunda parte já foi publicada.