🥇Regreso a los microservicios junto con Istio. Parte 1

Nota de traducción.: Los service mesh se han convertido en una solución relevante en la infraestructura moderna para aplicaciones basadas en una arquitectura de microservicios. Aunque Istio puede ser conocido por muchos ingenieros DevOps, es un producto relativamente nuevo que, siendo complejo en términos de las capacidades que ofrece, puede requerir un tiempo considerable para familiarizarse. Rinor Maloku, ingeniero alemán responsable de la computación en la nube para grandes clientes en la empresa de telecomunicaciones Orange Networks, ha escrito un interesante ciclo de materiales que permiten sumergirse de manera rápida y profunda en Istio. Comienza su relato explicando lo que Istio puede hacer y cómo se puede echar un vistazo rápido por uno mismo.

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

Gestión del tráfico: tiempos de espera, reintentos, equilibración de carga;
Seguridad: autenticación y autorización del usuario final;
Observabilidad: trazado, monitoreo, registro.

Todos ellos pueden ser resueltos a nivel de aplicación, sin embargo, después de eso, sus servicios dejarán de ser 'micro'. Todos los esfuerzos adicionales para resolver estos problemas representan un gasto innecesario de recursos de la empresa que podrían ser utilizados directamente para crear valor comercial. Consideremos el siguiente ejemplo:

Gerente de proyecto: ¿Cuánto tiempo tomará añadir la funcionalidad de retroalimentación?
Desarrollador: Dos sprints.
GP: ¿Qué?.. ¡Es solo un CRUD!
D: Hacer un CRUD es la parte fácil del trabajo, pero también necesitamos autenticar y autorizar a los usuarios y servicios. Dado que la red es poco fiable, será necesario implementar reintentos, así como patrón de circuit breaker en los clientes. Además, para asegurarnos de que todo el sistema no se caiga, necesitaremos tiempos de espera y bulkheads (más sobre ambos patrones mencionados se discutirá más adelante en el artículo - nota del traductor), y para detectar problemas, necesitaremos monitoreo, trazado, […]
GP: Oh, entonces simplemente añadamos esta función al servicio de Producto.

Creo que la idea está clara: el volumen de pasos y esfuerzos requeridos para agregar un servicio es enorme. En este artículo, veremos cómo Istio elimina todas las complejidades mencionadas anteriormente (que no son objetivo de la lógica empresarial) de los servicios.

Nota: El artículo asume que tienes conocimientos prácticos sobre Kubernetes. De lo contrario, te recomiendo leer mi introducción a Kubernetes y solo después continuar leyendo este material.

La idea de Istio

En un mundo sin Istio, un servicio realiza solicitudes directas a otro, y en caso de fallo, el servicio debe manejarlo por sí mismo: reintentar, prever un tiempo de espera, abrir un circuito de protección, etc.

Tráfico de red en Kubernetes

Istio ofrece una solución especializada, completamente separada de los servicios y que funciona interviniendo en la interacción de red. Así, realiza:

Tolerancia a fallos: basándose en el código de estado en la respuesta, comprende si hubo un fallo en la solicitud y la reintenta.
Implementaciones canarias: redirige solo un porcentaje fijo de las solicitudes a la nueva versión del servicio.
Monitoreo y métricas: ¿cuánto tardó el servicio en responder?
Trazabilidad y observabilidad: añade encabezados especiales a cada solicitud y realiza su trazado en el clúster.
Seguridad: extrae el token JWT, autentica y autoriza a los usuarios.

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

Arquitectura de Istio

Istio intercepta todo el tráfico de red y aplica un conjunto de reglas, insertando en cada pod un proxy inteligente en forma de contenedor sidecar. Los proxies, que activan todas las funcionalidades, forman Data Plane, y pueden configurarse dinámicamente mediante Control Plane.

Data Plane

Los proxies insertados en los pods permiten a Istio cumplir fácilmente con los requisitos que necesitamos. Por ejemplo, verifiquemos las funciones de reintento y el circuito de protección.

Cómo se implementan los reintentos y el circuito de protección en Envoy

Resumiendo:

Envoy (se habla del proxy que está en el contenedor sidecar, que se distribuye también como un producto independiente — nota del traductor) envía la solicitud al primer ejemplo del servicio B y se produce un fallo.
Envoy Sidecar intenta nuevamente (retry). (1)
La solicitud con fallo se devuelve al proxy que la invocó.
Así es como se abre el Circuit Breaker y se llama al siguiente servicio para las solicitudes posteriores. (2)

Esto significa que no tendrás que utilizar otra biblioteca de Retry, ni hacer tu propia implementación de Circuit Breaking y Service Discovery en el lenguaje de programación X, Y o Z. Todo esto y mucho más está disponible de forma nativa en Istio y no requiere ningún cambio en el código.

¡Genial! Ahora podrías querer embarcarte en una aventura con Istio, pero aún tienes algunas dudas y preguntas abiertas. Si se trata de una solución universal para todo, surgen sospechas legítimas: ¿acaso estas soluciones realmente no resultan adecuadas para ningún caso?

Y finalmente puedes preguntar: "¿Es configurable?"

Ahora estás listo para navegar — y conozcamos el Control Plane.

Control Plane

Se compone de tres componentes: Pilot, Mixer y Citadel, que en conjunto configuran los Envoy para enrutamiento de tráfico, aplican políticas y recopilan datos de telemetría. Esto se representa esquemáticamente como:

Interacción del Control Plane con el Data Plane

Los Envoy (es decir, el data plane) son configurados mediante Kubernetes CRD (Definiciones de Recursos Personalizados), definidas por Istio y especialmente diseñadas para este propósito. Para ti, esto significa que se presentan como un recurso más en Kubernetes con una sintaxis familiar. Una vez creado, este recurso será recogido por el control plane y aplicado a los Envoy.

La relación de los servicios con Istio

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

Honestamente, los servicios son tan conscientes de la presencia de Istio como los peces lo son del agua, cuando se preguntan: "¿Qué es el agua realmente?".

Ilustración Victoria Dimitrakopoulos: — ¿Cómo te parece el agua? — ¿Qué es el agua en realidad?

Así, puedes tomar un clúster en funcionamiento y tras desplegar los componentes de Istio, los servicios en él continuarán funcionando, y después de eliminar esos componentes, todo volverá a estar bien. Por supuesto, perderás las capacidades que ofrece Istio.

Suficiente teoría — ¡ahora llevemos este conocimiento a la práctica!

Istio en la práctica

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

Después de crear un clúster y configurar el acceso a Kubernetes a través de la herramienta de línea de comandos, puede instalar Istio a través del gestor de paquetes Helm.

Instalación de Helm

Instale el cliente Helm en su computadora, como se explica en documentación oficial. Lo utilizaremos para generar plantillas para la instalación de Istio en la siguiente sección.

Instalación de Istio

Descargue los recursos de Istio desde la última versión (el enlace original del autor para la versión 1.0.5 ha sido actualizado a la actual, es decir, 1.0.6 — nota del traductor.), extraiga el contenido en un directorio que a partir de ahora llamaré [istio-resources].

Para facilitar la identificación de 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 yendo al directorio [istio-resources] y ejecute el siguiente 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 adaptarla a nuestras necesidades, estableciendo los siguientes parámetros:

global.mtls.enabled se establece en false (es decir, la autenticación mTLS está desactivada — nota del traductor.), para simplificar nuestro proceso de introducción;
tracing.enabled activa el rastreo de solicitudes usando Jaeger;
kiali.enabled instala Kiali en el clúster para visualizar servicios y tráfico;
grafana.enabled instala Grafana para visualizar las métricas recopiladas.

Aplicaremos los recursos generados con el comando:

$ kubectl apply -f istio.yaml

La instalación de Istio en el clúster ha finalizado. Espere a que todos los pod en el espacio de nombres istio-system estén en estado En ejecución o Completed, ejecutando el siguiente comando:

$ kubectl get pods -n istio-system

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

Arquitectura de la aplicación Sentiment Analysis

Usaremos el ejemplo de la aplicación de microservicios Sentiment Analysis, utilizada en la ya mencionada artículo introductorio a Kubernetes. Es lo suficientemente compleja como para mostrar las capacidades de Istio en la práctica.

La aplicación consta de cuatro microservicios:

El servicio SA-Frontend, que gestiona el frontend de la aplicación en Reactjs;
El servicio SA-WebApp, que gestiona las solicitudes de Sentiment Analysis;
El servicio SA-Logic, que realiza el análisis de sentimientos;
El servicio SA-Feedback, que recibe retroalimentación de los usuarios sobre la precisión del análisis realizado.

En este esquema, además de los servicios, también vemos el Ingress Controller, que en Kubernetes enruta las solicitudes entrantes a los servicios correspondientes. En Istio se utiliza un concepto similar dentro del Ingress Gateway, del cual se darán más detalles a continuación.

Lanzamiento de la aplicación con proxy de Istio

Para las operaciones adicionales mencionadas en el artículo, clone el repositorio istio-mastery. Contiene la aplicación y los manifiestos para Kubernetes e Istio.

Inserción de sidecars

La inserción se puede realizar automáticamente o manualmente. Para la inserción automática de contenedores sidecar, será necesario establecer una etiqueta en el espacio de nombres istio-injection=enabled, lo que se hace con el siguiente comando:

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

Ahora, cada pod que se despliegue en el espacio de nombres por defecto (default) recibirá su contenedor sidecar. Para asegurarnos de esto, despleguemos una aplicación de prueba, yendo al directorio raíz del repositorio . En esta rama, el código del frontend se ha modificado para redirigir a los usuarios a Auth0 para la autenticación y utilizar el token JWT en las solicitudes a los demás servicios. Esto se implementa de la siguiente manera ( 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

Al desplegar los servicios, verifiquemos que los pods tengan dos contenedores (el propio servicio y su sidecar) al ejecutar el comando kubectl get pods y asegurarnos de que en la columna READY se indique el valor 2/2, que simboliza que ambos contenedores están en ejecución:

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

Proxy Envoy en uno de los pods

Ahora que la aplicación está funcionando, necesitamos permitir que el tráfico entrante llegue a la aplicación.

Ingress Gateway

La mejor práctica para lograr esto (permitir tráfico en el clúster) es a través de Ingress Gateway en Istio, que se encuentra en la "frontera" del clúster y permite habilitar para el tráfico entrante funciones como enrutamiento, balanceo de carga, seguridad y monitoreo.

El componente Ingress Gateway y el servicio que lo expone hacia afuera se instalaron en el clúster durante la instalación de Istio. Para conocer la dirección IP externa del 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

Nos dirigiremos a la aplicación a través de esta IP (me referiré a ella como EXTERNAL-IP), así que para mayor comodidad guardamos 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 intentas acceder a esta IP a través del navegador ahora, obtendrás un error de Servicio No Disponible, porque por defecto Istio bloquea todo el tráfico entrante, hasta que se defina un Gateway.

Recurso Gateway

El Gateway es una CRD (Definición de Recursos Personalizados) en Kubernetes, que se define tras la instalación de Istio en el clúster y activa la posibilidad de especificar puertos, protocolos y Hosts para los cuales queremos permitir el tráfico entrante.

En nuestro caso, queremos permitir tráfico HTTP en el puerto 80 para todos los Hosts. La tarea se realiza con 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 explicaciones, excepto el selector istio: ingressgateway. Con este selector podemos indicar a qué Ingress Gateway aplicar la configuración. En nuestro caso, se trata del 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

Ahora el gateway permite acceso al puerto 80, pero no tiene información sobre dónde enrutar las solicitudes. Para esto necesitaremos Servicios Virtuales.

Recurso VirtualService

VirtualService indica al Ingress Gateway cómo enrutar las solicitudes que se permiten dentro del clúster.

Las solicitudes a nuestra aplicación, que llegan a través del http-gateway, deben ser enviadas a los servicios sa-frontend, sa-web-app y sa-feedback:

Rutas que deben configurarse con VirtualServices

Consideremos las solicitudes que deben ir hacia SA-Frontend:

Coincidencia exacta por ruta / debe enviarse a SA-Frontend para obtener index.html;
Las rutas con prefijo /static/* deben enviarse a SA-Frontend para obtener archivos estáticos utilizados en el frontend, como CSS y JavaScript;
Las rutas que coinciden con la expresión regular '^.*.(ico|png|jpg)$', deben enviarse a SA-Frontend, ya que son imágenes que se muestran en la página.

La implementación se logra con la siguiente 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) Aspectos importantes: Este VirtualService está relacionado con las solicitudes que llegan a través de http-gateway; En destino se determina 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 en SA-WebApp y SA-Feedback, pero se ha acortado aquí en el artículo por concisión. Aplicamos VirtualService mediante la llamada: $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services creado Nota: Cuando aplicamos recursos de Istio, el servidor API de Kubernetes crea 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 de Ingress Gateway se presenta como otro Envoy, configurado en el plano de control. Todo esto se ve en el esquema así: Configuración de Istio-IngressGateway para el enrutamiento de solicitudes La aplicación Análisis de Sentimientos se ha hecho accesible en http://{EXTERNAL-IP}/. No te preocupes si recibes un estado de No encontrado: a veces se necesita un poco más de tiempo para que la configuración entre en vigor y se actualicen las cachés de Envoy.. Antes de continuar, trabaja un poco con la aplicación para generar tráfico (su presencia es necesaria para la claridad en las siguientes acciones — nota del traductor). Kiali: visibilidad Para acceder a la interfaz administrativa de Kiali, ejecuta el siguiente comando: $ kubectl port-forward $(kubectl get pod -n istio-system -l app=kiali -o jsonpath='{.items[0].metadata.name}') -n istio-system 20001 … y abre http://localhost:20001/, iniciando sesión como admin/admin. Aquí encontrarás muchas funcionalidades útiles, por ejemplo, para comprobar la configuración de los componentes de Istio, visualizar servicios con la información recopilada al interceptar solicitudes de red, obtener respuestas a preguntas como "¿Quién se comunica con quién?", "¿Qué versión del servicio está fallando?" etc. En general, explora las capacidades de Kiali antes de avanzar hacia la visualización de métricas con Grafana. Grafana: visualización de métricas Las métricas recopiladas en Istio se envían a Prometheus y se visualizan con Grafana. Para acceder a la interfaz administrativa de Grafana, ejecuta el siguiente comando, luego abre 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 Haciendo clic en el menú Inicio en la esquina superior izquierda y seleccionando Dashboard del Servicio Istio en la esquina superior izquierda, comienza con el servicio sa-web-app, para ver las métricas recopiladas: Aquí nos espera una representación vacía y completamente aburrida: el manual nunca aprobaría algo así. Creemos una pequeña carga con el siguiente comando: $ while true; do curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" -d '{"sentence": "Me encanta yogobella"}'; sleep .8; done Ahora tenemos gráficos mucho más atractivos y, además, excelentes herramientas de Prometheus para el monitoreo y Grafana para la visualización de métricas, que nos permitirán conocer el rendimiento, el estado de salud, las mejoras y la degradación en el funcionamiento de los servicios a lo largo del tiempo. Finalmente, echemos un vistazo al trazado de las solicitudes en los servicios. Jaeger: trazado Necesitamos el trazado porque cuántos más servicios tengamos, más difícil será encontrar la causa de un fallo. Veamos un caso sencillo de la imagen a continuación: Ejemplo típico de una solicitud fallida al azar La solicitud llega, falla — ¿cuál es la razón? ¿El primer servicio? ¿O el segundo? Excepciones hay en ambos — echemos un vistazo a los registros de cada uno. ¿Con qué frecuencia te has encontrado haciendo esto? Nuestro trabajo se asemeja más al de detectives de software que al de desarrolladores... Este es un problema común en microservicios y se resuelve con sistemas de trazado distribuidos, donde los servicios se envían entre sí un encabezado único, que luego se redirige al sistema de trazado, donde se empareja con los datos de la solicitud. Aquí hay una ilustración: Se utiliza TraceId para identificar la solicitud En Istio, se utiliza Jaeger Tracer, que implementa un marco independiente del proveedor OpenTracing API. Puedes acceder a la interfaz de usuario de Jaeger con el siguiente comando: $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686 Ahora dirígete a http://localhost:16686/ y selecciona el servicio sa-web-app. Si el servicio no aparece en el menú desplegable, genera actividad en la página y actualiza la interfaz. Luego, haz clic en el botón Find Traces, que mostrará los trazos más recientes; selecciona cualquiera — aparecerá información detallada sobre todos los trazos: Este trazo muestra: La solicitud llega a istio-ingressgateway (esta es la primera interacción con uno de los servicios, y se genera un Trace ID para la solicitud), después de lo cual el gateway redirige la solicitud al servicio sa-web-app. En el servicio sa-web-app la solicitud es capturada por el sidecar de Envoy, se crea un "hijo" en el span (por eso lo vemos en los trazos) y se redirige al contenedor sa-web-app. (Span — unidad lógica de trabajo en Jaeger, que tiene un nombre, hora de inicio de la operación y su duración. Los spans pueden estar anidados y ordenados. Un gráfico acíclico dirigido de spans forma un trace. — nota del traductor) Aquí la solicitud se procesa mediante el método sentimentAnalysis. Estos traces ya han sido generados por la aplicación, es decir, se requirieron cambios en el código. A partir de este momento se inicia una solicitud POST a sa-logic. El ID de trace debe ser pasado de sa-web-app. … Nota: En el paso 4, la aplicación debe ver los encabezados generados por Istio y pasarlos en solicitudes posteriores, como se muestra en la imagen a continuación: (A) Istio es responsable de pasar los encabezados; (B) Los encabezados son asumidos por los servicios Istio realiza el trabajo principal, ya que genera encabezados para las solicitudes entrantes, crea nuevos spans en cada sidecar y los pasa. Sin embargo, sin trabajar con los encabezados dentro de los servicios, el camino completo de trazabilidad de la solicitud se perderá. Es necesario tener en cuenta (pasar) los siguientes encabezados: x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context No es una tarea complicada, sin embargo, para facilitar su implementación ya existe una multitud de bibliotecas — por ejemplo, en el servicio sa-web-app, el cliente RestTemplate pasa estos encabezados si simplemente se añaden 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 ha quedado claro lo que obtenemos de serie (o casi «de serie»), consideremos cuestiones sobre enrutamiento ajustado, gestión de tráfico, seguridad, etc.! Nota de traducción.: sobre esto se leerá en la siguiente parte del material de Istio de Rinor Maloku, cuyas traducciones seguirán en nuestro blog en breve. ACTUALIZAR (14 de marzo): La segunda parte ya ha sido publicado. P.D. del traductor También puedes leer en nuestro blog: «Regreso a los microservicios junto con Istio»: parte 2 (ruteo, gestión del tráfico), parte 3 (autenticación y autorización); «Conduit — una malla de servicios liviana para Kubernetes»; «¿Qué es una malla de servicios y por qué la necesito [para una aplicación en la nube con microservicios]?»; «Guía ilustrada sobre la estructura de la red en Kubernetes. Partes 1 y 2»; «¿Cómo llegó este contenedor sidecar aquí [en Kubernetes]?». Fuente: habr.com route: - destination: host: sa-frontend # 2 port: number: 80
Puntos importantes:

Este VirtualService está relacionado con las solicitudes que llegan a través de http-gateway;
En destino se determina 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 en SA-WebApp y SA-Feedback, pero se ha abreviado aquí en el artículo por brevedad.

Aplicamos VirtualService llamando a:

Nota: Cuando aplicamos los recursos de Istio, el servidor API de Kubernetes genera 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. El controlador de Ingress Gateway se presenta como 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

La aplicación Análisis de Sentimientos se ha hecho accesible en http://{EXTERNAL-IP}/. No te preocupes si recibes un estado de No encontrado: a veces se necesita un poco más de tiempo para que la configuración entre en vigor y se actualicen las cachés de Envoy..

Antes de continuar, trabaja un poco con la aplicación para generar tráfico (su presencia es necesaria para la claridad en las siguientes acciones — nota del traductor).

Kiali: visibilidad

Para acceder a la interfaz administrativa de Kiali, ejecuta el siguiente comando:

… y abre http://localhost:20001/, iniciando sesión como admin/admin. Aquí encontrarás muchas funcionalidades útiles, por ejemplo, para comprobar la configuración de los componentes de Istio, visualizar servicios con la información recopilada al interceptar solicitudes de red, obtener respuestas a preguntas como "¿Quién se comunica con quién?", "¿Qué versión del servicio está fallando?" etc. En general, explora las capacidades de Kiali antes de avanzar hacia la visualización de métricas con Grafana.

Grafana: visualización de métricas

Las métricas recopiladas en Istio se envían a Prometheus y se visualizan con Grafana. Para acceder a la interfaz administrativa de Grafana, ejecuta el siguiente comando, luego abre http://localhost:3000/:

Haciendo clic en el menú Inicio en la esquina superior izquierda y seleccionando Dashboard del Servicio Istio en la esquina superior izquierda, comienza con el servicio sa-web-app, para ver las métricas recopiladas:

Aquí nos espera una representación vacía y completamente aburrida: el manual nunca aprobaría algo así. Creemos una pequeña carga con el siguiente comando:

Ahora tenemos gráficos mucho más atractivos y, además, excelentes herramientas de Prometheus para el monitoreo y Grafana para la visualización de métricas, que nos permitirán conocer el rendimiento, el estado de salud, las mejoras y la degradación en el funcionamiento de los servicios a lo largo del tiempo.

Finalmente, echemos un vistazo al trazado de las solicitudes en los servicios.

Jaeger: trazado

Necesitamos el trazado porque cuántos más servicios tengamos, más difícil será encontrar la causa de un fallo. Veamos un caso sencillo de la imagen a continuación:

Ejemplo típico de una solicitud fallida al azar

La solicitud llega, falla — ¿cuál es la razón? ¿El primer servicio? ¿O el segundo? Excepciones hay en ambos — echemos un vistazo a los registros de cada uno. ¿Con qué frecuencia te has encontrado haciendo esto? Nuestro trabajo se asemeja más al de detectives de software que al de desarrolladores...

Este es un problema común en microservicios y se resuelve con sistemas de trazado distribuidos, donde los servicios se envían entre sí un encabezado único, que luego se redirige al sistema de trazado, donde se empareja con los datos de la solicitud. Aquí hay una ilustración:

Se utiliza TraceId para identificar la solicitud

En Istio, se utiliza Jaeger Tracer, que implementa un marco independiente del proveedor OpenTracing API. Puedes acceder a la interfaz de usuario de Jaeger con el siguiente comando:

Ahora dirígete a http://localhost:16686/ y selecciona el servicio sa-web-app. Si el servicio no aparece en el menú desplegable, genera actividad en la página y actualiza la interfaz. Luego, haz clic en el botón Find Traces, que mostrará los trazos más recientes; selecciona cualquiera — aparecerá información detallada sobre todos los trazos:

Este trazo muestra:

La solicitud llega a istio-ingressgateway (esta es la primera interacción con uno de los servicios, y se genera un Trace ID para la solicitud), después de lo cual el gateway redirige la solicitud al servicio sa-web-app.
En el servicio sa-web-app la solicitud es capturada por el sidecar de Envoy, se crea un «hijo» en el span (por eso lo vemos en los rastreos) y se redirige al contenedor sa-web-app. (Span — unidad lógica de trabajo en Jaeger, que tiene un nombre, un tiempo de inicio de operación y su duración. Los spans pueden estar anidados y ordenados. Un grafo acíclico dirigido de spans forma un trace. — nota del traductor)
Aquí la solicitud se procesa mediante el método sentimentAnalysis. Estos traces ya han sido generados por la aplicación, es decir, se requirieron cambios en el código.
A partir de este momento se inicia una solicitud POST a sa-logic. El ID de trace debe ser pasado de sa-web-app.
…

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

(A) Istio es responsable de pasar los encabezados; (B) Los encabezados son asumidos por los servicios

Istio realiza la mayor parte del trabajo, ya que genera encabezados para las solicitudes entrantes, crea nuevos spans en cada sidecar y los transmite. Sin embargo, sin trabajar con los encabezados dentro de los servicios, se perderá el camino completo del rastreo de la solicitud.

Es necesario tener en cuenta (pasar) los siguientes encabezados:

No es una tarea complicada, sin embargo, para facilitar su implementación ya existe una multitud de bibliotecas — por ejemplo, en el servicio sa-web-app, el cliente RestTemplate pasa estos encabezados si simplemente se añaden 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 ha quedado claro lo que obtenemos de serie (o casi «de serie»), consideremos cuestiones sobre enrutamiento ajustado, gestión de tráfico, seguridad, etc.!

Nota de traducción.: sobre esto se leerá en la siguiente parte del material de Istio de Rinor Maloku, cuyas traducciones seguirán en nuestro blog en breve. ACTUALIZAR (14 de marzo): La segunda parte ya ha sido publicado.