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

Observação. trad.: As malhas de serviço definitivamente se tornaram uma solução relevante em infraestrutura moderna para aplicações que seguem arquitetura de microsserviços. Embora o Istio possa estar na boca de muitos engenheiros de DevOps, é um produto relativamente novo que, embora abrangente em termos dos recursos que oferece, pode exigir uma quantidade significativa de tempo para se familiarizar. O engenheiro alemão Rinor Maloku, responsável pela computação em nuvem para grandes clientes da empresa de telecomunicações Orange Networks, escreveu uma série maravilhosa de materiais que permitem que você mergulhe rápida e profundamente no Istio. Ele começa sua história contando o que o Istio pode fazer em geral e como você pode ver isso rapidamente com seus próprios olhos.

Istio — Um projeto Open Source desenvolvido em colaboração com equipes do Google, IBM e Lyft. Ele resolve complexidades que surgem em aplicações baseadas em microsserviços, como:

• Gestão de tráfego: timeouts, novas tentativas, balanceamento de carga;
• segurança: autenticação e autorização do usuário final;
• Observabilidade: rastreamento, monitoramento, registro.

Tudo isso pode ser resolvido no nível da aplicação, mas depois disso seus serviços não serão mais “micro”. Todo o esforço extra para resolver esses problemas é um desperdício de recursos da empresa que poderiam ser usados ​​diretamente para gerar valor comercial. Vejamos um exemplo:

Gerente de Projeto: Quanto tempo leva para adicionar um recurso de feedback?
Desenvolvedor: Dois sprints.

MP: O quê?.. É simplesmente CRUD!
R: Fazer CRUD é a parte fácil, mas ainda precisamos autenticar e autorizar usuários e serviços. Como a rede não é confiável, será necessário implementar solicitações repetidas, bem como padrão de disjuntor em clientes. Além disso, para garantir que todo o sistema não trave, você precisará de tempos limite e anteparas (para obter mais detalhes sobre os dois padrões mencionados, consulte mais adiante no artigo - tradução aproximada), e para detectar problemas, monitorar, rastrear, [...]

MP: Ah, então vamos inserir esse recurso no serviço Produto.

Acho que a ideia é clara: a quantidade de passos e de esforço necessários para adicionar um serviço é enorme. Neste artigo, veremos como o Istio remove toda a complexidade mencionada acima (que não pretende ser lógica de negócios) dos serviços.

Nota: este artigo pressupõe que você tenha conhecimento prático do Kubernetes. Caso contrário, recomendo a leitura minha introdução ao Kubernetes e só depois continue lendo este material.

Ideia do Istio

Em um mundo sem Istio, um serviço faz solicitações diretas a outro e, em caso de falha, o próprio serviço deve cuidar disso: fazer uma nova tentativa, fornecer um tempo limite, abrir um disjuntor, etc.

Tráfego de rede no Kubernetes

O Istio oferece uma solução especializada, totalmente separada dos serviços e que funciona interferindo na comunicação da rede. E assim implementa:

• tolerância ao erro: com base no código de status da resposta, ele entende se a solicitação falhou e a executa novamente.
• Lançamentos canário: redireciona apenas uma porcentagem fixa de solicitações para a nova versão do serviço.
• Monitoramento e métricas: Quanto tempo demorou para o serviço responder?
• Rastreamento e Observabilidade: adiciona cabeçalhos especiais a cada solicitação e os rastreia no cluster.
• segurança: recupera o token JWT, autentica e autoriza usuários.

Estas são apenas algumas das possibilidades (na verdade, apenas algumas!) Para intrigar você. Agora vamos mergulhar nos detalhes técnicos!

Arquitetura do Istio

O Istio intercepta todo o tráfego de rede e aplica um conjunto de regras a ele, inserindo um proxy inteligente na forma de um contêiner secundário em cada pod. Proxies que ativam todos os recursos formam um Plano de Dados, e eles podem ser configurados dinamicamente usando Avião de Controle.

Plano de Dados

Os proxies inseridos nos pods permitem que o Istio atenda facilmente aos requisitos de que precisamos. Por exemplo, vamos verificar as funções de nova tentativa e disjuntor.

Como novas tentativas e quebras de circuito são implementadas no Envoy

Para resumir:

1. Enviado (estamos falando de um proxy localizado em um contêiner sidecar, que é distribuído como produto separado - Aproximadamente. trad.) envia uma solicitação para a primeira instância do serviço B e falha.
2. Envoy Sidecar tenta novamente (tentar novamente). (1)
3. A solicitação falha e é retornada ao proxy que a chamou.
4. Isso abre o Circuit Breaker e chama o próximo serviço para solicitações subsequentes. (2)

Isso significa que você não precisa usar outra biblioteca Retry, não precisa 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 imediatamente. no Istio e não exige não mudanças no código.

Ótimo! Agora você pode querer fazer uma viagem com o Istio, mas ainda tem algumas dúvidas, perguntas em aberto. Se esta é uma solução universal para todas as ocasiões da vida, então você tem uma suspeita natural: afinal, todas essas soluções na realidade acabam sendo inadequadas para qualquer caso.

E finalmente você pergunta: “É personalizável?”

Agora que você está pronto para a viagem marítima, vamos conhecer o Avião de Controle.

Avião de Controle

Consiste em três componentes: Piloto, Mixer и Citadela, que trabalham juntos para configurar Envoys para rotear tráfego, aplicar políticas e coletar dados de telemetria. Esquematicamente, tudo se parece com isto:

Interação do plano de controle com o plano de dados

Envoys (ou seja, plano de dados) são configurados usando CRD do Kubernetes (Definições de recursos personalizados) definidas pelo Istio e especificamente destinadas a essa finalidade. O que isso significa para você é que eles parecem ser apenas mais um recurso do Kubernetes com uma sintaxe familiar. Uma vez criado, este recurso será captado pelo plano de controle e aplicado aos Envoys.

Relacionamento de 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?

Para ser honesto, os serviços estão tão conscientes da presença do Istio quanto os peixes estão da água quando se perguntam: “Afinal, o que é água?”

Ilustração Victoria Dimitrakopoulos: - Como você gosta da água? - Afinal, o que é água?

Assim, você pode pegar um cluster funcional e após implantar os componentes do Istio, os serviços nele localizados continuarão funcionando, e após a remoção desses componentes, tudo ficará bem novamente. É claro que neste caso você perderá os recursos fornecidos pelo Istio.

Chega de teoria - vamos colocar esse conhecimento em prática!

Istio na prática

O Istio requer um cluster Kubernetes com pelo menos 4 vCPUs e 8 GB de RAM disponíveis. Para configurar 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.

Depois de criar um cluster e configurar o acesso ao Kubernetes por meio do utilitário de console, você pode instalar o Istio por meio do gerenciador de pacotes Helm.

Instalação do leme

Instale o cliente Helm em seu computador, conforme descrito em documentação oficial. Usaremos isso para gerar modelos para instalação do Istio na próxima seção.

Instalando o Istio

Baixe recursos do Istio em Último lançamento (o link do autor original para a versão 1.0.5 foi alterado para o atual, ou seja, 1.0.6 - tradução aproximada), extraia o conteúdo em um diretório, que doravante chamarei [istio-resources].

Para identificar facilmente os recursos do Istio, crie um namespace no cluster K8s istio-system:

$ kubectl create namespace istio-system

Conclua a instalação acessando 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 gerará os principais componentes do Istio em um arquivo istio.yaml. Modificamos o modelo padrão para nos adequar, especificando os seguintes parâmetros:

• global.mtls.enabled instalado em false (ou seja, a autenticação mTLS está desativada - aprox.)para simplificar nosso processo de namoro;
• tracing.enabled inclui rastreamento de solicitação usando Jaeger;
• kiali.enabled instala o Kiali em um cluster para visualizar serviços e tráfego;
• grafana.enabled instala o Grafana para visualizar as métricas coletadas.

Vamos usar 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 estejam no namespace istio-system será capaz de Running ou Completedexecutando o comando abaixo:

$ kubectl get pods -n istio-system

Agora estamos prontos para continuar na próxima seção, onde colocaremos o aplicativo em funcionamento.

Arquitetura do aplicativo Sentiment Analysis

Vamos usar o exemplo da aplicação de microsserviço Sentiment Analysis usada no já mencionado Artigo de introdução ao Kubernetes. É complexo o suficiente para mostrar as capacidades do Istio na prática.

O aplicativo consiste em quatro microsserviços:

1. Serviço Front-end SA, que serve como frontend de um aplicativo Reactjs;
2. Serviço SA-WebApp, que atende consultas de Análise de Sentimento;
3. Serviço Lógica SA, que se realiza análise de sentimentos;
4. Serviço SA-Feedback, que recebe feedback dos usuários sobre a precisão da análise.

Neste diagrama, além dos serviços, vemos também o Ingress Controller, que no Kubernetes roteia as solicitações recebidas para os serviços apropriados. O Istio usa um conceito semelhante em seu Ingress Gateway, mais detalhes a seguir.

Executando um aplicativo com um proxy do Istio

Para outras operações mencionadas no artigo, clone seu repositório domínio do istio. Ele contém o aplicativo e os manifestos do Kubernetes e do Istio.

Inserindo sidecars

A inserção pode ser feita automaticamente ou manualmente. Para inserir contêineres secundários automaticamente, você precisará definir um rótulo para o namespace istio-injection=enabled, o que é feito com o seguinte comando:

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

Agora, cada pod que será implantado no namespace padrão (default) receberá seu contêiner sidecar. Para verificar isso, vamos implantar a aplicação de teste acessando o diretório raiz do repositório [istio-mastery] 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

Tendo implantado os serviços, vamos verificar se os pods possuem dois contêineres (com o próprio serviço e seu sidecar) executando o comando kubectl get pods e certificando-se de que sob a coluna READY valor especificado 2/2, simbolizando 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 fica assim:

Proxy Envoy em um dos pods

Agora que o aplicativo está instalado e funcionando, precisaremos permitir que o tráfego de entrada entre no aplicativo.

Gateway de entrada

A melhor prática para conseguir isso (permitir tráfego no cluster) é através Gateway de entrada no Istio, que está localizado na “borda” do cluster e permite habilitar recursos do Istio como roteamento, balanceamento de carga, segurança e monitoramento de tráfego de entrada.

O componente Ingress Gateway e o serviço que o encaminha 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
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Continuaremos acessando a aplicação usando este IP (vou me referir a ele como EXTERNAL-IP), então por conveniência escreveremos 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 através de um navegador agora, receberá um erro de Serviço Indisponível, pois por padrão, o Istio bloqueia todo o tráfego de entrada, O gateway ainda não foi definido.

Recurso de gateway

Gateway é um CRD (Custom Resource Definition) no Kubernetes, definido após a instalação do Istio no cluster e permitindo a capacidade de especificar as portas, protocolo e hosts para os quais queremos permitir o tráfego de entrada.

No nosso caso, queremos permitir o tráfego HTTP na porta 80 para todos os hosts. A tarefa é implementada 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:
- "*"

Esta configuração não precisa de explicação exceto para o seletor istio: ingressgateway. Com este 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

O gateway agora permite acesso à porta 80, mas não tem ideia de para onde encaminhar as solicitações. Para isso você vai precisar Serviços Virtuais.

Recurso VirtualService

O VirtualService informa ao Ingress Gateway como rotear solicitações permitidas no cluster.

As solicitações para nosso aplicativo provenientes 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

Vejamos as solicitações que devem ser enviadas ao SA-Fronend:

• Correspondência exata ao longo do caminho / deve ser enviado ao SA-Frontend para obter index.html;
• Caminhos prefixados /static/* deve ser enviado ao SA-Fronend para receber arquivos estáticos utilizados no frontend, como CSS e JavaScript;
• Caminhos correspondidos por expressão regular '^.*.(ico|png|jpg)$', deve ser enviado para SA-Fronend, porque Estas são as fotos 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)

Важные моменты:



 	
 Этот VirtualService относится к запросам, приходящим через http-gateway;


 	
 В destination определяется сервис, куда отправляются запросы.




Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности.

Применим VirtualService вызовом:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created
Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod'а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так:


Конфигурация Istio-IngressGateway для маршрутизации запросов
Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились.
Перед тем, как продолжить, поработайте немного с приложением, чтобы сгенерировать трафик (его наличие необходимо для наглядности в последующих действиях — прим. перев.).
Kiali : наблюдаемость
Чтобы попасть в административный интерфейс Kiali, выполните следующую команду:
$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001
… и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana.

Grafana: визуализация метрик
Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте 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
Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики:

Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой:
$ while true; do 
    curl -i http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done
Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени.
Наконец, посмотрим на трассировку запросов в сервисах.
Jaeger : трассировка
Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже:


Типовой пример случайного неудачного запроса
Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков…
Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация:


Для идентификации запроса используется TraceId
В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой:
$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686
Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам:

Этот трейс показывает:

 Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app.
 В сервисе sa-web-app запрос подхватывается Envoy sidecar'ом, создаётся «ребёнок» в span'е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span'ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span'ов образует trace. — прим. перев.)
 Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде.
 С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app.
 …

Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже:


(A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы
Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span'ы в каждом sidecare'е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян.
Необходимо учитывать (пробрасывать) следующие заголовки:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context
Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости.
Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core.
Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.!
Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована.
P.S. от переводчика
Читайте также в нашем блоге:

 «Назад к микросервисам вместе с Istio»: часть 2 (маршрутизация, управление трафиком), часть 3 (аутентификация и авторизация);
 «Conduit — легковесный service mesh для Kubernetes»;
 «Что такое service mesh и почему он мне нужен [для облачного приложения с микросервисами]?»;
 «Иллюстрированное руководство по устройству сети в Kubernetes. Части 1 и 2»;
 «Как этот sidecar-контейнер оказался здесь [в Kubernetes]?».

Источник: habr.com
route:

- destination:

host: sa-frontend             # 2

port:

number: 80

Pontos importantes:

 Este VirtualService refere-se a solicitações provenientes gateway http;
 В destination O serviço para o qual as solicitações são enviadas é determinado.

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 abreviado aqui no artigo por questões de brevidade.
Vamos aplicar o VirtualService chamando:

Nota: Quando consumimos recursos do Istio, o Kubernetes API Server cria um evento que é recebido pelo Istio Control Plane, e depois disso a nova configuração é aplicada aos proxies Envoy de cada pod. E o controlador do Ingress Gateway parece ser outro Envoy configurado no Control Plane. Tudo isso se parece com isto no diagrama:


Configuração do Istio-IngressGateway para roteamento de solicitação
O aplicativo Análise de Sentimento já está disponível em http://{EXTERNAL-IP}/. Não se preocupe se você receber o status Não encontrado: Às vezes, leva um pouco mais de tempo para que a configuração entre em vigor e os caches do Envoy sejam atualizados.
Antes de continuar, brinque um pouco com o aplicativo para gerar tráfego. (sua presença é necessária para maior clareza nas ações subsequentes - tradução aproximada).
Kiali: observabilidade
Para acessar a interface administrativa do Kiali, execute o seguinte comando:

... e abra http://localhost:20001/, fazendo login como admin/admin. Aqui você encontrará muitos recursos úteis, por exemplo, para verificar a configuração dos componentes do Istio, visualizar serviços usando informações coletadas na interceptação de solicitações de rede, obter respostas para as perguntas “Quem está contatando quem?”, “Qual versão do serviço está enfrentando fracassos?” e assim por diante. Em geral, explore os recursos do Kiali antes de passar 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 abra http://localhost:3000/:

Clicando no cardápio Início canto superior esquerdo e selecionando Painel de serviço do Istio no canto superior esquerdo, comece com serviço sa-web-apppara observar as métricas coletadas:

O que nos espera aqui é uma atuação vazia e completamente enfadonha - a administração nunca aprovará isso. Vamos criar uma pequena carga com o seguinte comando:

Agora temos gráficos muito mais bonitos e, além deles, maravilhosas ferramentas Prometheus para monitoramento e Grafana para visualização de métricas que nos permitirão aprender sobre desempenho, saúde, melhorias/degradação nos serviços ao longo do tempo.
Finalmente, vejamos o rastreamento de solicitações em serviços.
Jaeger: rastreamento
Precisaremos de rastreamento porque quanto mais serviços tivermos, mais difícil será chegar à causa da falha. Vejamos um caso simples da imagem abaixo:


Exemplo típico de uma solicitação aleatória com falha
O pedido vem, cai - qual é a razão? Primeiro serviço? Ou o segundo? Há exceções em ambos - vejamos os logs de cada um. Quantas vezes você se pegou fazendo isso? Nosso trabalho é mais de detetive de software do que de desenvolvedor...
Este é um problema comum em microsserviços e é resolvido por sistemas de rastreamento distribuído, nos quais os serviços passam um cabeçalho único entre si, após o qual essas informações são encaminhadas para o sistema de rastreamento, onde são comparadas com os dados da solicitação. Aqui está uma ilustração:


TraceId é usado para identificar a solicitação
O Istio usa Jaeger Tracer, que implementa a estrutura de API OpenTracing independente do fornecedor. Você pode acessar a interface de usuário do Jaeger com o seguinte comando:

Agora vá para http://localhost:16686/ e selecione um serviço sa-web-app. Caso o serviço não apareça no menu suspenso, mostre/gere atividade na página e atualize a interface. Depois disso, clique no botão Encontrar vestígios, que mostrará os rastreamentos mais recentes - selecione qualquer - informações detalhadas sobre todos os rastreamentos aparecerão:

Este rastreamento mostra:

 O pedido chega istio-ingressgateway (esta é a primeira interação com um dos serviços, e um Trace ID é gerado para a solicitação), após o qual o gateway envia a solicitação ao serviço sa-web-app.
 Em serviço sa-web-app a solicitação é captada pelo sidecar do Envoy, um “filho” é criado no span (é por isso que o vemos nos traces) e redirecionado para o contêiner sa-web-app. (palmo - uma unidade lógica de trabalho em Jaeger, que possui nome, horário de início da operação e sua duração. Os spans podem ser aninhados e ordenados. Um gráfico acíclico direcionado de spans forma um traço. - Aproximadamente. trad.)
 Aqui a solicitação é processada pelo método análise de sentimentos. Esses rastreamentos já são gerados pelo aplicativo, ou seja, eles exigiram mudanças de código.
 A partir deste momento, uma solicitação POST é iniciada em sa-lógica. O ID de rastreamento deve ser encaminhado de sa-web-app.
 ...

Nota: Na etapa 4, o aplicativo deverá ver os cabeçalhos gerados pelo Istio e passá-los para solicitações subsequentes conforme mostrado na imagem abaixo:


(A) O Istio é responsável pelo encaminhamento de cabeçalhos; (B) Os serviços são responsáveis ​​pelos cabeçalhos
O Istio faz a maior parte do trabalho porque... gera cabeçalhos para solicitações recebidas, cria novos spans em cada sidecare e os encaminha. No entanto, sem trabalhar com cabeçalhos dentro dos serviços, o caminho completo do rastreamento da solicitação será perdido.
Os seguintes cabeçalhos devem ser levados em consideração:

Esta não é uma tarefa difícil, mas para simplificar a sua implementação já existe muitas bibliotecas - por exemplo, no serviço sa-web-app, o cliente RestTemplate encaminha esses cabeçalhos se você simplesmente adicionar as bibliotecas Jaeger e OpenTracing a seus vícios.
Observe que o aplicativo Sentiment Analysis demonstra implementações em Flask, Spring e ASP.NET Core.
Agora que está claro o que sai da caixa (ou quase sai da caixa), vamos dar uma olhada no roteamento ajustado, gerenciamento de tráfego de rede, segurança, etc.!
Observação. trad.: Leia sobre isso na próxima parte dos materiais do Istio de Rinor Maloku, cujas traduções serão publicadas em nosso blog em um futuro próximo. ATUALIZAÇÃO (14 de março): A segunda parte já foi publicado.
PS do tradutor
Leia também em nosso blog:

 "Voltar aos microsserviços com o Istio": parte 2 (roteamento, controle de tráfego), parte 3 (autenticação e autorização);
 «Conduit – malha de serviço leve para Kubernetes";
 «O que é uma malha de serviço e por que preciso dela [para uma aplicação em nuvem com microsserviços]?";
 «Um guia ilustrado para redes no Kubernetes. Partes 1 e 2";
 «Como esse contêiner sidecar acabou aqui [no Kubernetes]?".

Fonte: habr.com