Istio: pilotaje y observabilidad con Kiali.

Istio se conoce como malla de servicios o service mesh para hacer las comunicaciones seguras, rápidas y confiables en nuevas arquitecturas de microservicios. Si es tu primera toma de contacto con Istio, te recomiendo que antes le eches un vistazo a anteriores entradas del blog, donde podrás introducirte en su arquitectura e instalación y sus principales funcionalidades.

En este post queremos resaltar la ayuda que Istio puede ofrecer a la hora de elegir si se debe establecer como productiva una nueva versión de un microservicio en nuestra plataforma, gracias al desarrollo del pilotaje entre versiones de nuestros servicios y su monitorización.

Explicaremos dos tipos de pilotaje que podemos desarrollar con Istio, así como una introducción de las capacidades de Kiali, la dashboard en la que Istio se apoya para la observabilidad y trazabilidad de un entorno de microservicios pilotados con esta herramienta.

Pilotaje con Istio

Entendemos como pilotaje de versiones de microservicios a ese conjunto de pruebas que se realizan a una nueva versión, previamente a que sea establecida como productiva.

Istio dispone de reglas de enrutamiento que le permiten controlar el tráfico y llamadas API entre servicios. Con ello, Istio es capaz de realizar un control de enrutamiento y de balanceo de la carga de tráfico entre versiones de microservicios, mediante varios tipos de pilotaje.

El modelo de gestión de tráfico de Istio se basa en un envoy proxy. Todo el tráfico que los servicios de su malla envían y reciben se transmite a través de este envoy, lo que facilita manejar el tráfico alrededor de su malla sin realizar ningún cambio en sus servicios.

A continuación, se presentan dos posibles conceptos de pilotaje con Istio.

Pilotaje basado en porcentajes de tráfico con Istio

El concepto detrás de la implementación canary se asocia al pilotaje por balanceo de tráfico entre versiones.

En el escenario de pilotaje que vamos a representar disponemos de una versión puesta en producción y de una nueva versión candidata a ser la versión definitiva o productiva.

Este tipo de pilotaje consiste en realizar gradualmente incrementos y decrementos en la misma proporción de carga entre ambas versiones, llegando a acotar todo el tráfico por la nueva versión, para que de esta manera pueda darse como válida y realizar su puesta como versión productiva, lo que se conoce como realizar un rolling update.

Si algo sale mal en el proceso, se aborta el pilotaje y se redirecciona el 100% del tráfico hacia la versión productiva.

Será más fácil de comprender este proceso si observamos el flujo de fases para el pilotaje que mostramos a continuación.

Partimos de una primera fase en el que solo tenemos desplegada una versión de nuestro microservicio, la versión productiva.

En una segunda fase, se despliega la nueva versión, hacia la que queremos pilotar tráfico para que pueda ser validada como versión productiva.

Comenzamos aplicando una pequeña carga de tráfico para esta nueva versión. Continuamos aplicando la misma proporción de tráfico en ambas versiones y, gradualmente, incrementaremos la carga por la nueva versión hasta redirigir todo el tráfico por esta, y con ello validar la capacidad de esta versión.

Si todo ha sido correcto se realiza el rolling update de versión, y la nueva versión se consolida como la versión productiva.

Pilotaje basado en peticiones de usuario con Istio

El Virtual Service (VS) es el componente de Istio que permite configurar cómo se enrutan las solicitudes a un servicio dentro de la mesh. Cuando queremos desplegar un pilotaje tipo canary es configurado con los pesos de carga de tráfico para enrutar el tráfico por las versiones correspondientes.

En este ejemplo el virtual service enruta las solicitudes a la versión v2 de un servicio dependiendo de si la solicitud proviene de un usuario en particular.

El nombre de host puede ser una dirección IP, un nombre DNS o, según la plataforma, un nombre de servicio de Kubernetes por el que se resuelve.

La sección http contiene las reglas de enrutamiento, que describen las condiciones de coincidencia y las acciones para enrutar el tráfico enviado a los destinos especificados en el campo host.

En este caso la primera regla de enrutamiento del ejemplo tiene una condición o match. Las solicitudes del usuario “user1” serán enrutadas a la nueva versión (v2) al recibir el valor exacto del usuario.

Configurando enrutamientos como el anterior, se puede definir un modelo de fases que podrá variar en función de las pruebas o validaciones que se quieran probar en la nueva versión, teniendo como objetivo dar su aprobación como versión productiva.

Kiali

Para la gestión y gobernanza de mallas de servicios basadas en Istio, podemos disfrutar de la dashboard de Kiali.

Kiali tiene las capacidades de observar y monitorizar la trazabilidad de los servicios incorporados en la mesh, así como los elementos y configuraciones que componen Istio.

Kiali es una consola de administración para Istio y se instalan por separado. Kiali requiere de obtener los datos y las configuraciones de Istio, que se exponen a través de Prometheus y la API del clúster.

Prometheus es una dependencia de Istio, que almacena los datos de métricas cuando la telemetría está habilitada. Kiali usa los datos almacenados en Prometheus para descubrir la topología de malla, mostrar métricas, calcular su rendimiento, mostrar posibles errores, etc.

Kiali utiliza la API de la plataforma de aplicaciones de contenedores (API del clúster) para obtener y resolver las configuraciones de la malla de servicios.

OKD y Kubernetes suelen ser las plataformas de aplicaciones de contenedores en las que trabaja Kiali. La API del clúster le sirve a Kiali para recuperar, por ejemplo, definiciones de namespaces, servicios, implementaciones, pods y otras entidades. También se consulta la API del clúster para recuperar configuraciones de Istio como virtual services, destination rules, route rules o gateways.

Como otros servicios opcionales podemos nombrar Jaeger para trazabilidad y Grafana para coleccionar métricas.

En el siguiente diagrama se resaltan los principales enfoques de operabilidad de la herramienta Kiali.

Configuración

Kiali proporciona vistas de listas filtradas de todas sus definiciones de redes de servicios. En su panel lateral podemos encontrar los apartados de gráfico, aplicaciones, servicios, workloads y configuración de Istio.

En el apartado de aplicaciones podemos desplegar según los namespaces, los servicios desplegados en la plataforma.

Kiali es más que observabilidad, también proporciona ayuda a la hora de configurar, actualizar y validar tu red de servicios con Istio.

En la vista de configuración de Istio proporciona un filtrado y navegación para los objetos de configuración de Istio, como virtual services, destination rules, gateway o filtros.

Proporciona edición de configuración en línea y una potente validación semántica para los recursos de Istio.

Validaciones

Kiali realiza un conjunto de validaciones en los objetos de Istio que hemos nombrado anteriormente. Las validaciones de Kiali son más potentes que las que básicamente ofrece Istio. Kiali es capaz de realizar validaciones semánticas para garantizar que las definiciones tengan sentido entre los objetos configurados, mientras que Istio proporciona verificaciones estáticas para definiciones bien formadas. Incluso realiza verificaciones entre namespaces, basadas en el estado de tiempo de ejecución de su malla de servicios.

Wizards

Kiali proporciona wizards, asistentes para crear, modificar y borrar recursos en la malla de servicios. Los asistentes se inician desde el desplegable de Actions, ubicado en cada apartado de Kiali en la interfaz de usuario. Los asistentes pueden crear y actualizar la configuración de Istio para el enrutamiento de sus componentes.

Estas acciones de creación están disponibles en la página de configuración deñ sitio:

Topología

En el apartado Graph se ofrece una potente visualización de su tráfico de malla. Kiali combina el tráfico de solicitudes en tiempo real con su información de configuración de Istio para presentar una visión inmediata del comportamiento de la malla de servicios, lo que le permite identificar problemas rápidamente.

Existen varios tipos de gráficos que permiten visualizar el tráfico según diferentes topologías: de servicio de alto nivel, de carga de trabajo de bajo nivel o de nivel de aplicación.

El gráfico dispone de una gran variedad de configuración, puede mostrar animación y porcentajes de la distribución del tráfico, diferentes visualizaciones de los nodos y sus conjuntos...

De este modo se puede configurar el gráfico para que muestre los namespaces y los datos de la manera que mejor se adapte a sus necesidades.

Métricas y trazabilidad

La dashboard de métricas permite visualizar información de la entrada y de la salida del tráfico de un servicio determinado. Se pueden obtener métricas con respecto al request volume, request duration, request throughput, request size, response throughput, y response size.

Si nos situamos en Traces dentro del apartado Workloads, Kiali nos ofrece una visión gráfica de los tiempos de cada request, permitiendo identificar latencias y baja performance. Además de ello, Kiali añade un mapa de calor para ayudar al usuario a identificar las trazas o tramos problemáticos.

Salud

Kiali permite visualizar la salud de la service mesh, así como la disponibilidad de un servicio y sus comunicaciones. La información de health se puede obtener consultando el health graph, o en la pantalla de detalles de un determinado servicio.

El estado de los nodos se actualiza automáticamente según las preferencias del usuario. El gráfico también se puede pausar para examinar un estado en particular o reproducirlo para volver a examinar un período de tiempo en particular.

El panel lateral resume la selección de gráfico actual, o el gráfico en su conjunto. Al seleccionar el nodo o algún otro elemento de interés, el panel lateral proporciona:

• Gráficos y trazas que muestran el porcentaje de tráfico y los tiempos de respuesta.
• Detalles de salud y rendimiento.
• Enlaces a páginas completamente detalladas.
• Desglose del código de respuesta y del host.

Conclusión

Istio es un gran aliado ante la incertidumbre que provoca la puesta en producción de una nueva versión de un microservicio. Gracias a los procesos de pilotaje que pueden ser desarrollados a partir de Istio, podemos acotar esta problemática y elaborar un conjunto de evidencias que nos haga estimar si la nueva versión es válida como versión productiva.

Hemos mostrado el pilotaje basado en la configuración de porcentajes de tráfico entre versiones y el pilotaje a través de peticiones basadas en usuarios al servicio pilotado. Ambos tipos de pilotaje en Istio son configurables en el virtual service de tu malla de servicios y garantizan un entorno de pruebas adecuado para tomar la decisión de definir la versión productiva de un microservicio.

Para todas estas pruebas, Istio nos ofrece su soporte en la herramienta de Kiali, una dashboard en la que podemos configurar los elementos de Istio, así como observar y monitorizar los servicios desplegados en su service mesh. Con Kiali completamos un abanico de herramientas que dota a nuestro pilotaje de servicios de una mayor precisión en cuanto a su trazabilidad o detección de errores dentro de nuestra malla de servicios.

En este post hemos querido reflejar la mayor parte de capacidades que Kiali contiene, apoyándonos con las ilustraciones de su documentación oficial, donde se encuentran todos los detalles necesarios para incorporar esta herramienta a vuestra plataforma junto a Istio, así como a otros servicios adicionales que hemos citado anteriormente, como Prometheus, Jaeger o Grafana.

Fuentes

• Documentación Istio.
• Documentación Kiali.
• Documentación Prometheus.
• Documentación Jaeger.
• Documentación Grafana.