🥇Volver aos microservizos con Istio. Parte 1

Nota. transl.: As mallas de servizo convertéronse definitivamente nun tema candente na infraestrutura actual para aplicacións que seguen a arquitectura de microservizos. Aínda que Istio pode estar no radar de moitos enxeñeiros de DevOps, é un produto bastante novo que, aínda que é complexo en canto a funcións que ofrece, pode levar moito tempo coñecelo. O enxeñeiro alemán Rinor Maloku, que se encarga do cloud computing para grandes clientes da empresa de telecomunicacións Orange Networks, escribiu unha marabillosa serie de materiais que permiten mergullarse de xeito rápido e profundo en Istio. Comeza a súa historia co que Istio pode facer e como podes velo rapidamente cos teus propios ollos.

Istio — Proxecto de código aberto, desenvolvido en colaboración con equipos de Google, IBM e Lyft. Resolve as complexidades que xorden en aplicacións baseadas en microservizos, por exemplo, como:

xestión do tráfico: tempo de espera, reintentos, balance de carga;
Безопасность: autenticación e autorización do usuario final;
observabilidade: rastrexo, seguimento, rexistro.

Todos eles pódense resolver a nivel de aplicación, pero despois diso os teus servizos deixarán de ser "micro". Todo o esforzo adicional para abordar estes problemas é un desperdicio de recursos da empresa que se poderían utilizar directamente para obter valor comercial. Considere un exemplo:

Xefe de proxecto: canto tempo leva engadir unha función de comentarios?
Desenvolvedor: dous sprints.

MP: Que?... É só CRUD!
R: Facer CRUD é a parte doada da tarefa, pero aínda necesitamos autenticar e autorizar usuarios e servizos. Dado que a rede non é fiable, terás que implementar solicitudes repetidas, así como patrón de interruptor en clientes. Ademais, para asegurarse de que todo o sistema non fallase, tempo de espera e mamparas (Consulte máis adiante no artigo para obter máis detalles sobre os dous patróns mencionados)., e para detectar problemas, seguimento, rastrexo, […]
MP: Ah, imos poñer esta función no servizo de produtos entón.

Creo que a idea está clara: a cantidade de pasos e esforzo necesarios para engadir un único servizo é enorme. Neste artigo, daremos unha ollada a como Istio elimina toda a complexidade mencionada anteriormente (non dirixida pola lóxica empresarial) dos servizos.

Nota: O artigo supón que tes coñecementos prácticos de Kubernetes. En caso contrario, recomendo ler a miña introdución a Kubernetes e só entón seguir lendo este material.

Istio idea

Nun mundo sen Istio, un servizo fai solicitudes directas a outro e, en caso de falla, o servizo debe xestionalo por si mesmo: facer un novo intento, prever un tempo de espera, abrir un interruptor automático, etc.

Tráfico de rede en Kubernetes

Istio, pola súa banda, ofrece unha solución especializada que está completamente separada dos servizos e funcións ao interferir coa interacción da rede. E así implementa:

tolerancia a fallos: baseándose no código de estado da resposta, entende se fallou a solicitude e volve enviara.
Lanzamentos de Canarias: redirixe só unha porcentaxe fixa de solicitudes á nova versión do servizo.
Monitorización e Métricas: canto tempo tardou en responder o servizo?
Trazado e observabilidade: Engade cabeceiras especiais a cada solicitude e rastrexaos no clúster.
Безопасность: recupera un token JWT, autentica e autoriza aos usuarios.

Estas son só algunhas das posibilidades (realmente só algunhas!) para intrigalo. Agora imos mergullo nos detalles técnicos!

Arquitectura

Istio intercepta todo o tráfico de rede e aplícalle un conxunto de regras, inserindo un proxy intelixente en forma de contedor sidecar en cada pod. Os proxies que activan todas as posibilidades forman a Plano de datos, e pódense axustar dinámicamente con Plano de control.

Plano de datos

Os proxies que se introducen nos pods permiten a Istio acadar facilmente os requisitos que necesitamos. Por exemplo, comprobemos os reintentos e as funcións do interruptor.

Como se implementan os reintentos e a interrupción do circuito en Envoy

Para resumir:

enviado (estamos a falar dun proxy situado nun contenedor sidecar, que se distribúe e como produto separado - aprox. transl.) envía unha solicitude á primeira instancia do servizo B e falla.
Envoy Sidecar está tentando de novo (reintento). (1)
A solicitude fallida devólvese ao proxy que a chamou.
Isto abre o Circuit Breaker e chama ao seguinte servizo para as solicitudes posteriores. (2)

Isto significa que non tes que usar a seguinte biblioteca Retry, non tes que facer a túa propia implementación de Circuit Breaking e Service Discovery na linguaxe de programación X, Y ou Z. Todo isto e moito máis está dispoñible fóra da caixa en Istio e non precisa non cambios de código.

Genial! Agora pode querer ir de viaxe con Istio, pero aínda quedan algunhas dúbidas, preguntas abertas. Se esta é unha solución universal para todas as ocasións da vida, entón tes unha sospeita lexítima: despois de todo, todas estas solucións non son adecuadas para ningún caso.

E finalmente preguntas: "É personalizable?"

Agora estás preparado para unha viaxe marítima e imos familiarizarnos con Control Plane.

Plano de control

Consta de tres compoñentes: Piloto, Batedeira и Citadela, que en conxunto configuran Envoys para enrutar o tráfico, aplicar políticas e recompilar datos de telemetría. Esquemáticamente, todo semella así:

Interacción do plano de control co plano de datos

Os enviados (é dicir, o avión de datos) están configurados con Kubernetes CRD (Definicións de recursos personalizadas) definidas por Istio e deseñadas especificamente para este fin. O que isto significa para ti é que son só un recurso máis en Kubernetes cunha sintaxe familiar. Unha vez creado, este recurso será recollido polo avión de control e aplicado a Envoys.

Relación de servizos con Istio

Describimos a relación de Istio cos servizos, pero non ao revés: como se relacionan os servizos con Istio?

Sinceramente, os servizos saben da presenza de Istio, así como os peixes saben da auga, cando se preguntan: "Que é a auga de todos os xeitos?".

Ilustración Victoria Dimitrakopoulos: Como che gusta a auga? - De todos os xeitos, que é a auga?

Así, pode tomar un clúster de traballo e despois de implantar os compoñentes de Istio, os servizos nel seguirán funcionando e, despois de eliminar estes compoñentes, todo estará ben de novo. Está claro que neste caso perderás as oportunidades que ofrece Istio.

Abonda con teoría: poñamos este coñecemento en práctica!

Istio na práctica

Istio require un clúster de Kubernetes con polo menos 4 vCPU e 8 GB de RAM dispoñibles. Para aumentar rapidamente o clúster e seguir as instrucións do artigo, recoméndoche utilizar a plataforma Google Cloud, que ofrece novos usuarios gratuíto $300.

Despois de crear o clúster e configurar o acceso a Kubernetes a través da utilidade da consola, podes instalar Istio a través do xestor de paquetes Helm.

Instalación de Helm

Instale o cliente Helm no seu ordenador como se describe en documentación oficial. Usarémolo para xerar modelos para instalar Istio na seguinte sección.

Instalación

Descargar recursos de Istio de último lanzamento (a ligazón do autor orixinal á versión 1.0.5 foi modificada pola actual, é dicir, 1.0.6 - tradución aprox.), extrae o contido nun único directorio, ao que me referirei como [istio-resources].

Para facilitar a identificación dos recursos de Istio, cree un espazo de nomes no clúster K8s istio-system:

$ kubectl create namespace istio-system

Complete a instalación navegando ata o directorio [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 mostrará os compoñentes clave de Istio nun ficheiro istio.yaml. Modificamos o modelo estándar para nós especificando os seguintes parámetros:

global.mtls.enabled instalado en false (é dicir, a autenticación mTLS está desactivada - aprox. tradución)para simplificar o noso proceso de citas;
tracing.enabled permite o rastrexo de solicitudes con Jaeger;
kiali.enabled instala Kiali nun clúster para visualizar servizos e tráfico;
grafana.enabled instala Grafana para visualizar as métricas recollidas.

Aplique os recursos xerados co comando:

$ kubectl apply -f istio.yaml

A instalación de Istio no clúster está completa! Agarde ata que todos os pods no espazo de nomes istio-system poderá Running ou Completedexecutando o seguinte comando:

$ kubectl get pods -n istio-system

Agora estamos preparados para continuar coa seguinte sección, onde levantaremos e executaremos a aplicación.

Arquitectura de aplicacións de análise de sentimentos

Usemos o exemplo da aplicación de microservizo Sentiment Analysis utilizada no xa mencionado Artigo de introdución a Kubernetes. É o suficientemente complexo como para mostrar as posibilidades de Istio na práctica.

A aplicación consta de catro microservizos:

Servizo SA-Frontend, que serve á aplicación front-end en Reactjs;
Servizo Aplicación web SA, que atende consultas de análise de sentimentos;
Servizo SA Lóxicaque se realiza por si mesma análise de sentimentos;
Servizo Comentarios de SA, que recibe comentarios dos usuarios sobre a precisión da análise realizada.

Neste diagrama, ademais dos servizos, tamén vemos o Controlador de entrada, que en Kubernetes encamiña as solicitudes entrantes aos servizos correspondentes. Istio usa un concepto similar como parte do Ingress Gateway, cuxo detalle seguirá.

Lanzamento dunha aplicación cun proxy de Istio

Para outras operacións mencionadas no artigo, clona o teu repositorio istio-dominio. Contén a aplicación e os manifestos para Kubernetes e Istio.

Inserción de sidecars

Pódese facer a inserción automaticamente ou a man. Para inserir automaticamente contedores sidecar, cómpre definir a etiqueta no espazo de nomes istio-injection=enabled, que se fai co seguinte comando:

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

Agora cada pod que se despregará no espazo de nomes predeterminado (default) recibirá o seu contenedor sidecar. Para verificalo, implementemos unha aplicación de proba indo ao directorio raíz do repositorio [istio-mastery] e executa 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

Despois de implantar os servizos, verifique que os pods teñan dous contedores cada un (co servizo en si e o seu sidecar) executando o comando kubectl get pods e asegurándose de que debaixo da columna READY valor especificado 2/2, simbolizando que ambos contedores están funcionando:

$ 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 ten o seguinte aspecto:

Envoy proxy nun dos módulos

Agora que a aplicación está en funcionamento, necesitamos permitir que o tráfico entrante entre na aplicación.

Pasarela de entrada

A mellor práctica para conseguilo (permitir o tráfico no clúster) é via Pasarela de entrada en Istio, que está situado no "borde" do clúster e permítelle activar funcións de Istio como o enrutamento, o equilibrio de carga, a seguridade e o seguimento do tráfico entrante.

O compoñente Ingress Gateway e o servizo que o reenvía ao exterior instaláronse no clúster durante a instalación de Istio. Para descubrir o enderezo IP externo dun servizo, 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

Seguiremos accedendo á aplicación usando esta IP (referireime a ela como EXTERNAL-IP), polo que por comodidade, escribiremos o valor nunha variable:

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

Se tentas acceder a esta IP a través dun navegador agora, obterás un erro Servizo non dispoñible, porque por defecto Istio bloquea todo o tráfico entranteata que se defina a pasarela.

Recurso de pasarela

Gateway é un CRD (Custom Resource Definition) en Kubernetes, definido despois de instalar Istio nun clúster e habilitar a posibilidade de especificar portos, protocolos e hosts para os que queremos permitir o tráfico entrante.

No noso caso, queremos permitir o tráfico HTTP no porto 80 para todos os hosts. O problema realízase coa seguinte definición (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 configuración non necesita explicación, excepto para o selector istio: ingressgateway. Con este selector, podemos especificar a que pasarela de entrada aplicar a configuración. No noso caso, este é o controlador Ingress Gateway, que estaba instalado por defecto en Istio.

A configuración aplícase chamando ao seguinte comando:

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

A pasarela agora permite o acceso ao porto 80 pero non ten idea de onde dirixir as solicitudes. Para iso necesitarás Servizos virtuais.

Recurso do servizo virtual

O VirtualService indica ao Ingress Gateway como enrutar as solicitudes permitidas no clúster.

As solicitudes para a nosa aplicación a través da pasarela http deben enviarse aos servizos sa-frontend, sa-web-app e sa-feedback:

Rutas a configurar con VirtualServices

Considere as solicitudes que deben enviarse a SA-Frontend:

Coincidencia exacta no camiño / debe enviarse a SA-Frontend para obter index.html;
Camiños con prefixo /static/* debe enviarse a SA-Frontend para que se usen ficheiros estáticos no frontend, como CSS e JavaScript;
Camiños que coinciden coa expresión regular '^.*.(ico|png|jpg)$', debe enviarse a SA-Frontend, porque Estas son as imaxes que aparecen na páxina.

A implementación conséguese coa seguinte configuración (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
P'p ° R¶RЅS <Rμ RјRѕRјRμRЅS, S <:

Este Servizo Virtual refírese ás solicitudes recibidas http-gateway;
В destination define o servizo ao que se envían as solicitudes.

Nota: A configuración anterior gárdase nun ficheiro sa-virtualservice-external.yaml, que tamén contén configuracións para o enrutamento a SA-WebApp e SA-Feedback, pero acurtouse aquí no artigo para que sexa breve.

Solicite VirtualService chamando a:

Nota: Cando aplicamos recursos Istio, o servidor API de Kubernetes desencadea un evento que recibe o Istio Control Plane e, despois diso, aplícase a nova configuración ao proxy Envoy de cada pod. E o controlador Ingress Gateway parece ser outro Envoy configurado no plano de control. Todo isto vese así no diagrama:

Configuración de Istio-IngressGateway para o enrutamento de solicitudes

A análise de sentimentos xa está dispoñible en http://{EXTERNAL-IP}/. Non te preocupes se obtén o estado Non atopado: ás veces leva un pouco máis de tempo para que a configuración teña efecto e para que as cachés de Envoy se actualicen.

Antes de continuar, xoga coa aplicación un pouco para xerar tráfico. (a súa presenza é necesaria para a claridade nas accións posteriores - aprox. transl.).

Kiali: observabilidade

Para acceder á interface de administración de Kiali, execute o seguinte comando:

...e aberto http://localhost:20001/iniciando sesión como admin/admin. Aquí atoparás moitas funcións útiles, por exemplo, para comprobar a configuración dos compoñentes de Istio, visualizar os servizos a partir da información recollida interceptando solicitudes de rede, obter respostas ás preguntas "Quen está en contacto con quen?", "Que versión do servizo está a experimentar". fracasos?" etcétera. En xeral, explora as posibilidades de Kiali antes de pasar á visualización de métricas con Grafana.

Grafana: visualización de métricas

As métricas recollidas en Istio acaban en Prometheus e visualízanse con Grafana. Para acceder á interface de administración de Grafana, executa o comando a continuación e ábreo http://localhost:3000/:

Premendo no menú casa arriba á esquerda e selecciona Panel de control do servizo Istio na esquina superior esquerda, comeza co servizo sa-web-apppara ver as métricas recollidas:

Aquí estamos esperando unha actuación baleira e completamente aburrida - a dirección nunca aprobará isto. Imos crear unha pequena carga co seguinte comando:

Agora temos gráficos moito máis bonitos, e ademais deles, as marabillosas ferramentas Prometheus para monitorizar e Grafana para visualizar métricas, que nos permitirán coñecer o rendemento, o estado de saúde, as melloras/degradación dos servizos ao longo do tempo.

Finalmente, vexamos o rastrexo de solicitudes nos servizos.

Jaeger: rastrexo

Necesitaremos rastrexo, porque cantos máis servizos teñamos, máis difícil é chegar á causa do fallo. Vexamos un caso sinxelo da imaxe de abaixo:

Exemplo típico dunha solicitude aleatoria errada

A petición chega, cae - cal é a razón? Primeiro servizo? Ou segundo? Hai excepcións en ambos: vexamos os rexistros de cada un. Cantas veces te sorprendeches facendo isto? O noso traballo parécese máis aos detectives de software que aos desenvolvedores...

Este é un problema moi estendido nos microservizos e resólvese mediante sistemas de rastrexo distribuídos, nos que os servizos pasan uns encabezados únicos entre si, despois de que esta información se redirixe ao sistema de rastrexo, onde se compara cos datos da solicitude. Velaquí unha ilustración:

TraceId úsase para identificar a solicitude

Istio usa Jaeger Tracer, que implementa un marco de API OpenTracing independente do provedor. Podes acceder á interface de usuario de Jaeger co seguinte comando:

Agora vai a http://localhost:16686/ e seleccione un servizo sa-web-app. Se o servizo non aparece no menú despregable, mostra/xera actividade na páxina e actualiza a interface. Despois diso, fai clic no botón Atopar rastros, que mostrará os trazos máis recentes - seleccione calquera - aparecerá información detallada sobre todos os trazos:

Este trazo mostra:

A solicitude chega istio-ingressgateway (esta é a primeira interacción cun dos servizos e xérase un ID de rastrexo para a solicitude), despois de que a pasarela envía a solicitude ao servizo sa-web-app.
En servizo sa-web-app a solicitude é recollida polo sidecar Envoy, créase un "neno" no tramo (por iso o vemos en trazos) e redirixido ao contedor sa-web-app. (palmo - unha unidade lóxica de traballo en Jaeger, que teña un nome, a hora de inicio da operación e a súa duración. Os tramos pódense aniñar e ordenar. Un gráfico acíclico dirixido de tramos forma unha traza. - aprox. trad.)
Aquí a solicitude é procesada polo método Análise sentimental. Estes trazos xa os xera a aplicación, é dicir. requirían cambios de código.
A partir deste momento, iníciase unha solicitude POST sa-lóxica. O ID de rastrexo debe ser reenviado desde sa-web-app.
...

Nota: No paso 4, a aplicación debería ver as cabeceiras xeradas por Istio e pasalas a solicitudes posteriores, como se mostra na imaxe seguinte:

(A) O envío de cabeceira é responsabilidade de Istio; (B) Os servizos son responsables das cabeceiras

Istio fai o groso do traballo porque xera cabeceiras para as solicitudes entrantes, crea novos intervalos en cada atención secundaria e envíaos. Non obstante, sen traballar con cabeceiras dentro dos servizos, perderase a ruta completa de rastrexo da solicitude.

Débense considerar (reenviados) os seguintes encabezados:

Esta é unha tarefa sinxela, pero para simplificar a súa implementación, xa hai moitas bibliotecas - por exemplo, no servizo sa-web-app, o cliente RestTemplate reenvía estas cabeceiras se simplemente engade as bibliotecas Jaeger e OpenTracing a súas dependencias.

Teña en conta que a aplicación Sentiment Analysis demostra implementacións en Flask, Spring e ASP.NET Core.

Agora que está claro o que estamos a sacar da caixa (ou case fóra da caixa), vexamos o enrutamento fino, a xestión do tráfico de rede, a seguridade e moito máis.

Nota. transl.: lea sobre isto na seguinte parte de materiais sobre Istio de Rinor Maloku, cuxas traducións seguirán no noso blog nun futuro próximo. Actualización (14 de marzo): A segunda parte xa publicados.

PS do tradutor

Lea tamén no noso blog:

"Volver aos microservizos con Istio": parte 2 (enrutamento, control de tráfico), parte 3 (autenticación e autorización);
«Conduit: malla de servizo lixeira para Kubernetes»;
«Que é unha malla de servizos e por que a necesito [para unha aplicación na nube con microservizos]?»;
«Guía ilustrada de redes en Kubernetes. Partes 1 e 2»;
«Como acabou este contedor de sidecar aquí [en Kubernetes]?».

Fonte: www.habr.com

Volve aos microservizos con Istio. Parte 1