Istio Deep Dive

En el desarrollo de este artículo demostraremos algunas de las ventajas que obtenemos al manejar una arquitectura de microservicios con Istio.

Ahora si, partimos.

Arquitectura de la App Music

Para la demostración usaremos una aplicación basada en microservicios y Angular:

Esta arquitectura muestra un aplicativo front desarrollado en Angular para listar track’s, crear track, mostrar métricas y administración de usuarios. Dichos track’s en la primera versión se almacenan en una base de datos MongoDB, y en la versión 3 del back recuperará los track’s desde Spotify, consumiendo su API.

El código fuente se encuentra publicado en GitLab de forma pública:

https://gitlab.com/deep-dive-on-istio

Requisitos:

• Tener un cluster K8s configurado y las herramientas que se mencionan en la presentación.
• Tener conocimientos avanzados, sobre el trabajo con cluster kubernetes y arquitecturas de microservicios.

Para instalar Istio es recomendable seguir los pasos del sitio oficial: https://istio.io/docs/setup/kubernetes/install/kubernetes/

Instalar Istio usando kubectl apply:

$ curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.2.2 sh -
$ cd ./istio-1.2.2
$ export PATH=$PWD/bin:$PATH
$ for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -f $i; done

Después debemos instalar un profile demo, seleccionaremos el de tipo “permissive mutual TLS mode”:

$ kubectl apply -f install/kubernetes/istio-demo.yaml

Una vez haya terminado de ejecutarse el comando podemos comprobar el estado de los pods desplegados con:

$ watch kubectl get pods --all-namespaces

Hora debemos crear un espacio de nombre para la aplicación y habilitar la auto inyección del envoy:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: music
  labels:
    istio-injection: enabled
EOF

De esta forma cada vez que hagamos un deploy de cualquier app al namespace “music”, Istio le agregará el sidecar por defecto.

Deploy de las Apps

Tener en cuenta que para ejecutar las apps se debe tener configurado la herramienta Skaffold:

1 — Instalar la app que usaremos como back-end llamada “back”:

$ git clone https://gitlab.com/deep-dive-on-istio/back.git
$ cd back/
$ git ckeckout v1.0
$ skaffold run

2 — Instalar la app que usaremos de frond-ent llamada “front”:

$ git clone https://gitlab.com/deep-dive-on-istio/front.git
$ cd front/
$ git ckeckout v1.0
$ skaffold run

3- A continuación desplegaremos el “Gateway” y lo asociaremos a las reglas de entrada en el “Virtual Service”

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: music-gateway
  namespace: music
  labels:
    gateway: music-gateway
    istio: ingressgateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"
    - port:
        number: 80
        name: http2
        protocol: HTTP2
      hosts:
        - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: back-gw-virtualservice
  namespace: music
  labels:
    service: back-gw-virtualservice
spec:
  hosts:
    - "*"
  gateways:
    - music-gateway
  http:
    - match:
        - uri:
            prefix: /back
      route:
        - destination:
            host: back
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: front
EOF

Para ver la IP cluster y la IP publica que proporciona el balanceador de carga , ejecutar:

$ kubectl get svc istio-ingressgateway -n istio-system

Si accedemos desde cualquier al IP que obtuvimos podremos ver la WebApp que publicamos. Pueden acceder con usuario: “admin” y contraseña “admin”.

Ya que tenemos una pequeña aplicación desplegada, compuesta por un front en Angular, un back escrito con SpringBoot y una base de datos con MongoDB, vamos a instalar Kiali para ver como se ve la interacción entre estos componentes de forma mas clara y ver que nos brinda este Service Mesh que hemos implementado. Recordar de generar peticiones para que se muestre mejor en la consola de Kiali.

Para instalar kiali primero debemos desplegar un “secret” con las credenciales de acceso”:

Para generar usuario y contraseña usaremos:

$ KIALI_USERNAME=$(echo -n 'admin' | base64)
$ KIALI_PASSPHRASE=$(echo -n '1f2d1e2e67df' | base64)

Después aplicamos el secreto:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: kiali
  namespace: istio-system
  labels:
    app: kiali
type: Opaque
data:
  username: $KIALI_USERNAME
  passphrase: $KIALI_PASSPHRASE
EOF

Debemos reiniciar el pod que se instaló por defecto al desplegar el perfil por defecto “istio-demo.yaml” para que tome las nuevas credenciales:

$ kubectl get pods -n istio-system
con ese comando veremos el nombre que tiene el pod de kiali y 
luego lo reiniciamos con :
$ kubectl delete pod [nombre-pod] -n istio-system

Para visualizar la consola de kiali en local ejecutamos el comando:

$ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=kiali -o jsonpath='{.items[0].metadata.name}') 20001:20001

este comando hace una re dirección de puerto hacia nuestro localhost por el puerto 20001:

http://localhost:20001/kiali/console/

Navegando por la interfaz de Kiali podemos ver mucha información sobre nuestras aplicaciones, tiempos de respuestas, tipos de errores, configuraciones, etc…

Añadir texto alternativo

Para ver como evoluciona nuestra app y poder ver su comportamiento en kiali, hagamos deploy de otra versión.

#nos posicionamos en nuetras aplicación back 
$ cd back/
$ git ckeckout v2.0
$ skaffold run
# mos movemos a nuestro front y de igual forma hacemos deploy
$ cd front/
$ git ckeckout v2.0
$ skaffold run

Una vez se hayan ejecutado los deploy, podemos entrar a nuestra aplicación Web y navegar en ella para generar peticiones, también podemos crear track’s en el menú entities para generar mas interacción entre los componentes. Luego de esto si vamos a Kiali podemos ver algo así:

Añadir texto alternativo

Si analizamos un poco el código de VirtualService:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: back-virtualservice
  namespace: music
spec:
  hosts:
    - back
  http:
    - route:
        - destination:
            host: back
            subset: 'v1'
          weight: 90
        - destination:
            host: back
            subset: 'v2'
          weight: 10

Podemos ver que estamos haciendo un deployment de tipo Canary, especificando que la v2 solo tendrá el 10 por ciento de las peticiones. Podríamos ir incrementando de a poco el porcentaje según el comportamiento de la aplicación y hasta poder llegar a un 100% de puesta en productivo.

Con kiali podemos ver cuantas respuestas ok hacen las app, cual es el tiempo de latencia entre componentes, en general nos ayuda a comprender un poco mejor nuestro ecosistema y como está interactuando.

Instalamos la app que usaremos como cliente para conectare a Spotify:

$ git clone https://gitlab.com/deep-dive-on-istio/client.git
$ cd client/
$ skaffold run

Siguiendo con la demostración, desplegaremos la versión 3 de nuestra aplicación, para ello ejecutamos:

#nos posicionamos en nuetras aplicación back 
$ cd back/
$ git ckeckout v3.0
$ skaffold run

Debemos generar peticiones desde nuestra interfaz web.

Al ejecutar el deployment de la versión 3 tenemos algo peculiar y es esta característica que nos da Istio llamada “mirror”; con mirror podemos duplicar el trafico que llega al service y mandar una copia completa de ese trafico a la versión 3 de nuestra aplicación y poder probarla con una carga real y si detectamos algún problema, no afectar al usuario, ni al negocio.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: back-virtualservice
  namespace: music
spec:
  hosts:
    - back
  http:
    - route:
        - destination:
            host: back
            subset: v2
          weight: 100
        mirror:
            host: back
            subset: v3

Una vez que la versión 3 este lista para poner productiva cambiamos el VirtualService y ejecutamos:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: back-virtualservice
  namespace: music
spec:
  hosts:
    - back
  http:
    - route:
        - destination:
            host: back
            subset: v2
          weight: 30
        - destination:
            host: back
            subset: v3
          weight: 70
EOF

Seguimos generando peticiones a nuestra web y veremos como viajan en Kiali.

Añadir texto alternativo

Con la demostración espero satisfacer la expectación y poder ejemplificar algunas de las características de Istio que nos ayuda mucho en la administración de arquitecturas de miscroservicios.

Si alguien desea ponerlo en práctica, pueden contar conmigo,

Saludos…