El objetivo de este artículo es realizar una introducción a la instalación y uso de unas herramientas de gran utilidad en sistemas de microservicios como son Kiali, Jager y Grafana. Lo vamos a realizar usando la recién liberada versión 1.6 de Istio(Junio 2020). La idea no es entrar en detalle de la instalación y configuración de Istio, solo lo imprescindible para tener un sistema de microservicios y ver como podemos podemos sacarle partido con estas herramientas. Os recomiendo éste artículo previo dedicado a la instalación y configuración de Istio 1.5

Lo primero es ir a github y descargar la última release de la 1.6 en mi caso la 1.6.2. Actualizamos el path con la nueva ruta istio-1.6.2/bin en caso de tener una previa o la añadimos si es la primera vez.

Creamos una instancia nueva de minikube con 8Gb
minikube delete
minikube start --memory 8192

Instalamos el perfil demo de Istio
istioctl install --set profile=demo

Indicamos que deben inyectarse los proxies automáticamente en el namespace default
kubectl label namespace default istio-injection=enabled

Y consultamos los pods del namespace istio-system

Ya tenemos instalado Istio con todos sus pods corriendo y ahora tenemos que desplegar los microservicios, vamos a usar la aplicación de test que viene con Istio Bookinfo(todo un clásico)

En primer lugar desplegamos un yaml (bookinfo.yaml en local) con la configuración de los Deployment(Pods y ReplicaSet) y Service

kubectl apply -f bookinfo.yaml

Y a continuación otro yaml (bookinfo-gateway.yaml en local) con la configuración del ingressgateway de Istio (Gateway y VirtualService).

kubectl apply -f bookinfo-gateway.yaml

De momento no vamos a desplegar ningún DestinationRule pero cuando veamos Kiali si que usaremos varios (incluso desde la misma herramienta de manera gráfica) para poner en práctica la gestión del tráfico (enrutamiento de solicitudes en base a criterios de url,parámetros de cabecera, enrutamiento a diferentes versiones coexistentes de un mismo microservicio con un determinado peso, modificación del peso en caliente,circuit breaker,tolerancia a fallos…)

Pues con los que tenemos hasta ahora,si consultamos los Pods,Services y VirtualServices, obtenemos toda la información de lo que hemos desplegado en el namespace default.

Vamos a centrarnos en un punto importante.Observamos que cada pod contiene 2 contenedores cuando a priori solo debería tener 1, el correspondiente a la imagen del microservicio tal como podemos chequear en cualquiera de los Deployment de bookinfo.yaml.

Pues bien el segundo contenedor es el sidecar-proxy envoy que istio ha inyectado automáticamente en todos los pods y que es la pieza clave para el funcionamiento de Istio.

En cuanto a los servicios son todos del tipo ClusterIP y sin IP externa por lo tanto.Es importante recalcar que los servicios que tengamos definidos como NodePort y con un puerto de acceso externo establecido no van a pasar por el sidecar-proxy sino que accederán directamente al servicio…con todas sus consecuencias, ya que no van a estar en el ámbito de istio.

Ésto no nos conviene en general y la idea es que el acceso sea mediante el ingressgateway de istio.Si observamos los VirtualService vemos precisamente a bookinfo-gateway, que es una instancia de ingressgateway de istio y que va a ser el punto de acceso desde el exterior.

Establezcamos las ips y puertos para habilitar el acceso desde el exterior

export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')

export INGRESS_HOST=$(minikube ip)

Si comprobamos la url del gateway
echo $GATEWAY_URL

Y efectivamente vemos que mediante ella accedemos a la aplicación Bookinfo.

Kiali

A modo introductorio indicar que kiali es una de las herramientas que viene con Istio y que nos permite visualizar la topología de nuestros microservicios(como se conectan, quien dependende de quien) pemitiendo la visualización de los tiempos de respuesta, peticiones por segundo, los porcentajes de tráfico entre diferentes versiones coexistentes. La salud de los microservicios, errores en caso de producirse (códigos http) ,servicios no disponibles y conexiones no operativas.Gestión del tráfico, permtiéndonos configurar VirtualService y DestinationRules de manera gráfica para realizar bastantes cosas.

• Enrutar peticiones entre diferentes versiones, o a partir de su url o de atrubutos de la cabecera de la petición.
• Aplicar el patrón «circuit breaker» para hacer resilente el sistema.
• Inyectar fallos y parar el tráfico en un determinado punto, para testear la resilencia del sistema.
• Establecer timeouts.
• Realizar «canary» ,»shifting»o «shadowing» entre releases o versiones. Para asegurar los cambios en el software.

Se trata de un entorno gráfico con diferentes perspectivas y diferentes niveles de detalle

En éste enlace podeis acceder a un video de la web oficial de kiali que realiza un tour por sus diferentes opciones. 

Pues pongamos en práctica algunos de estos temas.

PENDIENTE DE COMPLETAR

Tiene una integración total con Jaeger (herramienta encargada de la gestión de trazas distribuidas) y con Grafana(herramienta para cuadros de mando)

Jaeger

Grafana