Vuelta a los microservicios con Istio. Parte 1

Nota. traducir: Las mallas de servicios definitivamente se han convertido en un tema candente en la infraestructura actual para aplicaciones que siguen la arquitectura de microservicios. Si bien Istio puede estar en el radar de muchos ingenieros de DevOps, es un producto bastante nuevo que, si bien es complejo en cuanto a las características que ofrece, puede llevar mucho tiempo conocerlo. El ingeniero alemán Rinor Maloku, que está a cargo de la computación en la nube para grandes clientes en la empresa de telecomunicaciones Orange Networks, ha escrito una maravillosa serie de materiales que le permiten sumergirse rápida y profundamente en Istio. Comienza su historia con lo que puede hacer Istio y cómo puedes verlo rápidamente con tus propios ojos.

Istio — Proyecto de código abierto, desarrollado en colaboración con equipos de Google, IBM y Lyft. Resuelve las complejidades que surgen en las aplicaciones basadas en microservicios, por ejemplo, como:

• la gestión del tráfico: tiempos de espera, reintentos, equilibrio de carga;
• seguridad: autenticación y autorización del usuario final;
• observabilidad: seguimiento, seguimiento, registro.

Todos ellos pueden resolverse a nivel de aplicación, sin embargo, después de eso, sus servicios ya no serán "micro". Todo el esfuerzo adicional para abordar estos problemas es un desperdicio de recursos de la empresa que podría usarse directamente para generar valor comercial. Considere un ejemplo:

Gerente de proyecto: ¿Cuánto tiempo lleva agregar una función de comentarios?
Desarrollador: dos sprints.

MP: ¿Qué?... ¡Es simplemente CRUD!
R: Hacer CRUD es la parte fácil de la tarea, pero aún necesitamos autenticar y autorizar usuarios y servicios. Dado que la red no es confiable, deberá implementar solicitudes repetidas, así como patrón de disyuntor en clientes. Además, para asegurarse de que todo el sistema no se bloquee, los tiempos de espera y mamparos (Consulte más adelante en el artículo para obtener más detalles sobre ambos patrones mencionados)., y con el fin de detectar problemas, seguimiento, rastreo, […]

MP: Oh, entonces pongamos esta característica en el servicio de Producto.

Creo que la idea es clara: la cantidad de pasos y esfuerzo necesarios para agregar un solo servicio es enorme. En este artículo, veremos cómo Istio elimina toda la complejidad mencionada anteriormente (no dirigida por la lógica comercial) de los servicios.

Nota: El artículo asume que tiene conocimientos prácticos de Kubernetes. De lo contrario, recomiendo leer mi introducción a Kubernetes y solo entonces continuar leyendo este material.

idea de istio

En un mundo sin Istio, un servicio realiza solicitudes directas a otro y, en caso de falla, el servicio debe manejarlo por sí mismo: hacer un nuevo intento, prever un tiempo de espera, abrir un disyuntor, etc.

Tráfico de red en Kubernetes

Istio, por otro lado, ofrece una solución especializada que está completamente separada de los servicios y funciones al interferir con la interacción de la red. Y así implementa:

• Tolerancia a fallos: según el código de estado en la respuesta, comprende si la solicitud falló y la vuelve a enviar.
• Lanzamientos canarios: redirige solo un porcentaje fijo de solicitudes a la nueva versión del servicio.
• Monitoreo y Métricas: ¿cuánto tardó en responder el servicio?
• Rastreo y observabilidad: agrega encabezados especiales a cada solicitud y los rastrea en el clúster.
• seguridad: recupera un token JWT, autentica y autoriza a los usuarios.

Estas son solo algunas de las posibilidades (¡realmente solo algunas!) para intrigarte. ¡Ahora profundicemos en los detalles técnicos!

Arquitectura

Istio intercepta todo el tráfico de la red y le aplica un conjunto de reglas, insertando un proxy inteligente en forma de contenedor sidecar en cada pod. Proxies que activan todas las posibilidades forman un Plano de datos, y se pueden ajustar dinámicamente con Plano de control.

Plano de datos

Los proxies que se insertan en los pods permiten a Istio lograr fácilmente los requisitos que necesitamos. Por ejemplo, vamos a comprobar las funciones de reintentos y disyuntores.

Cómo se implementan los reintentos y la interrupción del circuito en Envoy

Resumiendo:

1. Enviado (estamos hablando de un proxy ubicado en un contenedor sidecar, que se distribuye y como producto separado - aprox. trad.) envía una solicitud a la primera instancia del servicio B y falla.
2. Envoy Sidecar lo está intentando de nuevo (rever). (1)
3. La solicitud fallida se devuelve al proxy que la llamó.
4. Esto abre el disyuntor y llama al siguiente servicio para solicitudes posteriores. (2)

Esto significa que no tiene que usar la siguiente biblioteca de reintentos, no tiene que hacer su propia implementación de interrupción de circuitos y detección de servicios en el lenguaje de programación X, Y o Z. Todo esto y más está disponible de fábrica en Istio y no requiere no cambios de código.

¡Excelente! Ahora puede que quieras ir de viaje con Istio, pero aún quedan algunas dudas, preguntas abiertas. Si esta es una solución universal para todas las ocasiones en la vida, entonces tiene una sospecha legítima: después de todo, todas esas soluciones no son adecuadas para ningún caso.

Y finalmente preguntas: “¿Es personalizable?”

Ahora está listo para un viaje por mar, y familiaricémonos con Control Plane.

Plano de control

Consta de tres componentes: Piloto, Mezclador и Ciudadela, que en conjunto configuran Envoys para enrutar el tráfico, aplicar políticas y recopilar datos de telemetría. Esquemáticamente, todo se ve así:

Interacción del plano de control con el plano de datos

Los enviados (es decir, el plano de datos) están configurados con CRD de Kubernetes (Definiciones de recursos personalizadas) definidas por Istio y diseñadas específicamente para este fin. Lo que esto significa para usted es que son solo otro recurso en Kubernetes con una sintaxis familiar. Una vez creado, este recurso será recogido por el plano de control y aplicado a Envoys.

Relación de servicios con Istio

Hemos descrito la relación de Istio con los servicios, pero no al revés: ¿cómo se relacionan los servicios con Istio?

Para ser honesto, los servicios saben sobre la presencia de Istio tan bien como los peces saben sobre el agua, cuando se preguntan: "¿Qué es el agua de todos modos?".

Ilustración Victoria Dimitrakopoulos: ¿Qué te parece el agua? - ¿Qué es el agua de todos modos?

Por lo tanto, puede tomar un clúster en funcionamiento y, después de implementar los componentes de Istio, los servicios en él seguirán funcionando y, después de eliminar estos componentes, todo volverá a estar bien. Está claro que en este caso perderá las oportunidades que brinda Istio.

¡Basta de teoría, pongamos este conocimiento en práctica!

Istio en la práctica

Istio requiere un clúster de Kubernetes con al menos 4 vCPU y 8 GB de RAM disponibles. Para subir rápidamente el clúster y seguir las instrucciones del artículo, recomiendo usar Google Cloud Platform, que ofrece a los nuevos usuarios gratis $ 300.

Después de crear el clúster y configurar el acceso a Kubernetes a través de la utilidad de la consola, puede instalar Istio a través del administrador de paquetes de Helm.

Instalación del timón

Instale el cliente Helm en su computadora como se describe en documentación oficial. Lo usaremos para generar plantillas para instalar Istio en la siguiente sección.

Instalación

Descargar recursos de Istio desde último lanzamiento (el enlace del autor original a la versión 1.0.5 se ha cambiado al actual, es decir, 1.0.6 - traducción aproximada), extraiga el contenido a un solo directorio, al que me referiré como [istio-resources].

Para identificar fácilmente los recursos de Istio, cree un espacio de nombres en el clúster de K8s. istio-system:

$ kubectl create namespace istio-system

Complete la instalación navegando al directorio [istio-resources] y ejecutando el 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 generará los componentes clave de Istio en un archivo. istio.yaml. Hemos modificado la plantilla estándar para nosotros mismos especificando los siguientes parámetros:

• global.mtls.enabled instalado en false (es decir, la autenticación mTLS está deshabilitada - traducción aproximada)para simplificar nuestro proceso de citas;
• tracing.enabled permite el seguimiento de solicitudes con Jaeger;
• kiali.enabled instala Kiali en un clúster para visualizar servicios y tráfico;
• grafana.enabled instala Grafana para visualizar las métricas recopiladas.

Aplicar los recursos generados con el comando:

$ kubectl apply -f istio.yaml

¡La instalación de Istio en el clúster está completa! Espere hasta que todos los pods en el espacio de nombres istio-system será capaz Running o Completedejecutando el siguiente comando:

$ kubectl get pods -n istio-system

Ahora estamos listos para continuar con la siguiente sección, donde levantaremos y ejecutaremos la aplicación.

Arquitectura de aplicación de análisis de sentimiento

Usemos el ejemplo de la aplicación de microservicio Sentiment Analysis utilizada en el ya mencionado Artículo de introducción a Kubernetes. Es lo suficientemente complejo como para mostrar las posibilidades de Istio en la práctica.

La aplicación consta de cuatro microservicios:

1. Servicio Interfaz SA, que sirve a la aplicación front-end en Reactjs;
2. Servicio Aplicación web SA, que atiende consultas de análisis de sentimiento;
3. Servicio Lógica SAque se realiza a sí mismo análisis de los sentimientos;
4. Servicio Comentarios de SA, que recibe comentarios de los usuarios sobre la precisión del análisis realizado.

En este diagrama, además de los servicios, también vemos el Ingress Controller, que en Kubernetes enruta las solicitudes entrantes a los servicios correspondientes. Istio usa un concepto similar como parte de Ingress Gateway, cuyos detalles se darán a continuación.

Iniciar una aplicación con un proxy de Istio

Para otras operaciones mencionadas en el artículo, clone su repositorio istio-maestría. Contiene la aplicación y los manifiestos de Kubernetes e Istio.

Inserción de sidecares

La inserción se puede hacer automáticamente o a mano. Para insertar automáticamente contenedores sidecar, debe establecer la etiqueta en el espacio de nombres istio-injection=enabled, que se hace con el siguiente comando:

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

Ahora, cada pod que se implementará en el espacio de nombres predeterminado (default) obtendrá su contenedor sidecar. Para verificar esto, implementemos una aplicación de prueba yendo al directorio raíz del repositorio [istio-mastery] y ejecutando el siguiente 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

Una vez implementados los servicios, verifique que los pods tengan dos contenedores (con el propio servicio y su sidecar) ejecutando el comando kubectl get pods y asegurándose de que debajo de la columna READY valor especificado 2/2, que simboliza que ambos contenedores se están ejecutando:

$ 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 se ve así:

Envoy proxy en uno de los pods

Ahora que la aplicación está en funcionamiento, debemos permitir que el tráfico entrante ingrese a la aplicación.

Puerta de enlace de ingreso

La mejor práctica para lograr esto (permitir el tráfico en el clúster) es a través de Puerta de enlace de ingreso en Istio, que se encuentra en el "perímetro" del clúster y le permite habilitar funciones de Istio como el enrutamiento, el equilibrio de carga, la seguridad y la supervisión del tráfico entrante.

El componente Ingress Gateway y el servicio que lo reenvía hacia el exterior se instalaron en el clúster durante la instalación de Istio. Para averiguar la dirección IP externa de un servicio, ejecute:

$ 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 accediendo a la aplicación utilizando esta IP (me referiré a ella como EXTERNAL-IP), por lo que, por conveniencia, escribiremos el valor en una variable:

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

Si intenta acceder a esta IP a través de un navegador ahora, recibirá un error de Servicio no disponible, porque por defecto, Istio bloquea todo el tráfico entrantehasta que se defina Gateway.

Recurso de puerta de enlace

Gateway es un CRD (Definición de recursos personalizada) en Kubernetes, definido después de instalar Istio en un clúster y habilitar la capacidad de especificar puertos, protocolos y hosts para los que queremos permitir el tráfico entrante.

En nuestro caso, queremos permitir el tráfico HTTP en el puerto 80 para todos los hosts. El problema se realiza mediante la siguiente 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 no necesita explicación excepto por el selector istio: ingressgateway. Con este selector podemos especificar a qué Ingress Gateway aplicar la configuración. En nuestro caso, este es el controlador Ingress Gateway, que se instaló por defecto en Istio.

La configuración se aplica llamando al siguiente comando:

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

La puerta de enlace ahora permite el acceso al puerto 80 pero no tiene idea de dónde enrutar las solicitudes. Para esto necesitarás Servicios virtuales.

Recurso de servicio virtual

VirtualService le dice a Ingress Gateway cómo enrutar las solicitudes que están permitidas dentro del clúster.

Las solicitudes a nuestra aplicación que llegan a través de la puerta de enlace http deben enviarse a los servicios sa-frontend, sa-web-app y sa-feedback:

Rutas a configurar con VirtualServices

Considere las solicitudes que deben enviarse a SA-Frontend:

• Coincidencia exacta en el camino / debe enviarse a SA-Frontend para obtener index.html;
• Caminos con un prefijo /static/* debe enviarse a SA-Frontend para obtener archivos estáticos utilizados en la interfaz, como CSS y JavaScript;
• Rutas que coinciden con la expresión regular '^.*.(ico|png|jpg)$', debe enviarse a SA-Frontend, porque Estas son las imágenes que se muestran en la página.

La implementación se logra mediante la siguiente configuración (sa-virtualservice-externo.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

Puntos importantes:

 Este VirtualService se refiere a las solicitudes que llegan puerta de enlace http;
 В destination define el servicio al que se envían las solicitudes.

Nota: La configuración anterior se almacena en un archivo sa-virtualservice-external.yaml, que también contiene configuraciones para el enrutamiento a SA-WebApp y SA-Feedback, pero se ha abreviado aquí en el artículo por motivos de brevedad.
Aplicar VirtualService llamando al:

NotaNota: cuando aplicamos recursos de Istio, el servidor API de Kubernetes activa un evento que recibe el plano de control de Istio y, después de eso, la nueva configuración se aplica a los proxies Envoy de cada pod. Y el controlador Ingress Gateway parece ser otro Envoy configurado en el plano de control. Todo esto se ve así en el diagrama:


Configuración de Istio-IngressGateway para el enrutamiento de solicitudes
El análisis de sentimiento ya está disponible en http://{EXTERNAL-IP}/. No se preocupe si obtiene el estado No encontrado: a veces, la configuración tarda un poco más en surtir efecto y las cachés de Envoy se actualizan..
Antes de continuar, juegue un poco con la aplicación para generar tráfico. (su presencia es necesaria para mayor claridad en acciones posteriores - aprox. trad.).
Kiali: observabilidad
Para acceder a la interfaz de administración de Kiali, ejecute el siguiente comando:

…y abre http://localhost:20001/iniciando sesión como admin/admin. Aquí encontrará muchas funciones útiles, por ejemplo, para verificar la configuración de los componentes de Istio, visualizar servicios a partir de la información recopilada al interceptar solicitudes de red, obtener respuestas a las preguntas "¿Quién está contactando a quién?", "¿Qué versión del servicio está experimentando fallas?" etcétera. En general, explora las posibilidades de Kiali antes de pasar a visualizar métricas con Grafana.

Grafana: visualización de métricas
Las métricas recopiladas en Istio acaban en Prometheus y se visualizan con Grafana. Para acceder a la interfaz de administración de Grafana, ejecute el siguiente comando y luego abra http://localhost:3000/:

Al hacer clic en el menú Inicio arriba a la izquierda y seleccione Panel de servicio de Istio en la esquina superior izquierda, comience con el servicio aplicación-sa-webpara ver las métricas recopiladas:

Aquí estamos esperando una actuación vacía y completamente aburrida; la gerencia nunca aprobará esto. Vamos a crear una pequeña carga con el siguiente comando:

Ahora contamos con gráficos mucho más bonitos, y además de ellos, las maravillosas herramientas Prometheus para el monitoreo y Grafana para la visualización de métricas, que nos permitirán conocer el rendimiento, estado de salud, mejoras/degradación en los servicios a lo largo del tiempo.
Por último, veamos el seguimiento de solicitudes en los servicios.
Jaeger: seguimiento
Necesitaremos rastrear, porque cuantos más servicios tengamos, más difícil será llegar a la causa de la falla. Veamos un caso simple de la siguiente imagen:


Ejemplo típico de una solicitud aleatoria fallida
La solicitud llega, cae - ¿Cuál es la razón? primer servicio? ¿O segundo? Hay excepciones en ambos: veamos los registros de cada uno. ¿Con qué frecuencia te has sorprendido haciendo esto? Nuestro trabajo se parece más a los detectives de software que a los desarrolladores...
Este es un problema generalizado en los microservicios y se resuelve mediante sistemas de seguimiento distribuidos, en los que los servicios pasan un encabezado único entre sí, después de lo cual esta información se redirige al sistema de seguimiento, donde se compara con los datos de la solicitud. Aquí hay una ilustración:


TraceId se utiliza para identificar la solicitud
Istio usa Jaeger Tracer, que implementa un marco de API OpenTracing independiente del proveedor. Puede acceder a la interfaz de usuario de Jaeger con el siguiente comando:

ahora ve a http://localhost:16686/ y seleccione un servicio aplicación-sa-web. Si el servicio no se muestra en el menú desplegable, muestra/genera actividad en la página y actualiza la interfaz. Después de eso, haga clic en el botón Encuentra rastros, que mostrará los rastros más recientes - seleccione cualquiera - aparecerá información detallada sobre todos los rastros:

Este rastro muestra:

 entra el pedido puerta de entrada-istio (esta es la primera interacción con uno de los servicios y se genera un ID de seguimiento para la solicitud), después de lo cual la puerta de enlace envía la solicitud al servicio aplicación-sa-web.
 En el servicio aplicación-sa-web la solicitud es recogida por el sidecar de Envoy, se crea un "hijo" en el lapso (es por eso que lo vemos en las huellas) y se redirige al contenedor aplicación-sa-web. (Lapso - una unidad lógica de trabajo en Jaeger, que tiene un nombre, la hora de inicio de la operación y su duración. Los tramos se pueden anidar y ordenar. Un gráfico acíclico dirigido de tramos forma una traza. - aprox. trad.)
 Aquí la solicitud es procesada por el método análisis de los sentimientos. Estos rastros ya están generados por la aplicación, es decir, requerían cambios de código.
 A partir de este momento se inicia una petición POST en sa-lógica. El ID de seguimiento debe reenviarse desde aplicación-sa-web.
 ...

Nota: En el paso 4, la aplicación debería ver los encabezados generados por Istio y pasarlos a solicitudes posteriores, como se muestra en la imagen a continuación:


(A) El reenvío de encabezados es responsabilidad de Istio; (B) Los servicios son responsables de los encabezados
Istio hace la mayor parte del trabajo porque genera encabezados para las solicitudes entrantes, crea nuevos tramos en cada sidecare y los reenvía. Sin embargo, sin trabajar con encabezados dentro de los servicios, se perderá la ruta de seguimiento de la solicitud completa.
Los siguientes encabezados deben ser considerados (reenviados):

Esta es una tarea simple, pero para simplificar su implementación, ya existe muchas bibliotecas - por ejemplo, en el servicio sa-web-app, el cliente RestTemplate reenvía estos encabezados si simplemente agrega las bibliotecas Jaeger y OpenTracing a sus dependencias.
Tenga en cuenta que la aplicación Sentiment Analysis muestra implementaciones en Flask, Spring y ASP.NET Core.
Ahora que está claro lo que estamos sacando de la caja (o casi de la caja), veamos cómo ajustar el enrutamiento, la administración del tráfico de red, la seguridad y más.
Nota. traducir: lea sobre esto en la siguiente parte de los materiales sobre Istio de Rinor Maloku, cuyas traducciones seguirán en nuestro blog en un futuro próximo. ACTUALIZAR (14 de marzo): Segunda parte ya publicado
PD del traductor
Lea también en nuestro blog:

 "Volver a los microservicios con Istio": parte 2 (enrutamiento, control de tráfico), parte 3 (autenticación y autorización);
 «Conduit: malla de servicio ligera para Kubernetes";
 «¿Qué es una red de servicios y por qué la necesito [para una aplicación en la nube con microservicios]?";
 «Una guía ilustrada para redes en Kubernetes. Partes 1 y 2";
 «¿Cómo terminó este contenedor sidecar aquí [en Kubernetes]?".

Fuente: habr.com