Istio es el complemento perfecto de Kubernetes. Una solución elegante y completa de “networking”, que además proporciona registro y monitorización en varias plataformas (Prometheus, Grafana, Jaeger, Servicegraph, etc), que viene integrado directamente en su “control plane”.

 

En este informe, más que deconstruir; explicando por separado cada componente del que consiste Istio, veremos qué es Istio y cómo puede simplificar la gestión de un clúster, a medida que éste vaya creciendo. También exploramos los planteamientos que debería cambiar un administrador y la diferencia entre el manejo de datos de un clúster; con y sin Istio.

 

Gestión del Tráfico

 

El problema

Al pasar de una aplicación monolítica a una basada en micro-servicios, no todo son ventajas. Una aplicación monolítica se puede dividir en decenas de micro-servicios. A medida que un clúster va creciendo es inevitable tener varias decenas, e incluso centenares de servicios corriendo; con diferentes versiones, en diferentes entornos, etc. Esto hace que sea muy difícil de visualizar el clúster y haya cada vez más propensión a equivocarse.

¿Qué es Istio y cómo simplifica el tráfico?

Istio es una red (o malla) de servicio que proporciona gestión de tráfico, aplicación de políticas de complimiento y recolección de métricas. Una malla de servicios (“Service mesh”) es una capa de infraestructura dedicada para gestionar la comunicación de servicio a servicio.

En Istio, esto se consigue configurando proxies basados en “Envoy”, que es añadido a los pods como container “sidecar”, e impone el flujo natural del tráfico al backend apropiado, mientras inhabilita a otros servicios que se comuniquen con este. Además, los servicios no se comunican directamente, sino que lo hacen a través de sus contenedores sidecar (“Envoy”). El responsable de este proceso es el “Pilot”.

Puede que algunos se hayan dado cuenta que con este comportamiento, Istio satisface algunos requerimientos que se conseguiría con NetworkPolicies.

En la imagen de arriba se puede ver que los servicios A y B solo se comunican directamente con sus contenedores sidecar Envoy asociados. Así que si el servicio A quisiera enviar un paquete al servicio B, se lo pasaría a su contenedor Envoy, que se lo enviaría al contenedor Envoy del servicio B, que a su vez se lo pasaría al servicio B.

Si el servicio B tuviera varias réplicas, Pilot se encargaría de la distribución de la carga de forma homogénea, así es como se podría configurar para que un porcentaje de solicitudes fuera a un servicio B’, o que las solicitudes con ciertos headers vayan a un servicio B’.

Pilot advance config

 

La recolecta y visualización de las métricas es un añadido que se agradece. La verdad es que es una práctica bastante astuta por parte del equipo Istio. Una vez se tiene el paquete a enrutar, no cuesta nada multiplexarlo a otro bloque y sacar el máximo jugo al tráfico. El bloque que se encarga de esta tarea es el Mixer.

Mixer aplica políticas de complimiento a lo largo de la malla (comprueba si el servicio A está configurado para hablar con el servicio B) y recoge métricas de los containers sidecar Envoy y otros servicios (figura abajo). Además proporciona varias funcionalidades adicionales en Istio. Debido a su modelo plugin de propósito general, es posible ampliar los backends infra-estructurales con los que puede interactuar Mixer de forma relativamente fácil. Implica programar un adaptador.

Istio viene con varios ​adaptadores (que son como drivers) de Mixer incorporados; éstos permiten con mínima configuración conseguir un fin en particular, como por ejemplo tener los logs y las métricas en la herramienta de nuestra elección.

Para la monitorización en Prometheus, pasariamos las métricas al adaptador de Prometheus y el Mixer se encargaría del resto.

figura – Mixer specific

 

Lo bueno de Istio es que está implementado como una extensión de Kubernetes, lo que hace que los objetos estén integrados dentro del api-server. Esto hace que el Admin tenga que aprenderse algunos objetos nuevos de Kubernetes y su propósito, en vez de desplegar una aplicación desacoplada y configurarla.

Esto es una ventaja que proporciona Kubernetes, no Istio directamente.

Los objetos nuevos a destacar para la gestión del tráfico son Gateway, VirtualSevice y DestinationRule. Estos objetos, combinados, y el control de plano de Istio, permiten reemplazar al ingress controller por defecto o integrar uno, en caso de no tenerlo. En GKE, esto implicaría en un control más granular y flexible del tráfico y menor coste. A continuación vamos a ver estos objetos y su propósito.

  • Gateway: El objeto Gateway describe cómo debe entrar el tráfico al clúster. En este objeto típicamente se definiría el puerto, el protocolo, el host, información sobre el certificado y la llave TLS, etc. Una solicitud tendría que satisfacer los requisitos exigidos para entrar al clúster.
  • VirtualService: Un VirtualService va enlazado a un Gateway. En este objeto se definen reglas de enrutamiento; éstas se aplican a todas las solicitudes que hayan superado los requisitos del Gateway, al cual va enlazado. Una configuración típica sería distribuir el tráfico entre varios backend, según el path.
  • DestinationRule: El DestinationRule define reglas, que se aplican a una solicitud que ya ha sido enrutado hacia un servicio en particular. Puede darse el caso que tengamos varias versiones de una misma aplicación, de este modo, e podría definir un subconjunto de la aplicación y dependiendo de algunos parámetros, enviar el tráfico a una versión u otra. Estas comprobaciones se harían en el VirtualService.

Este es un enfoque ligeramente diferente al utilizar un objeto del tipo Ingress, que enrutaría el paquete a un servicio, que acabaría en un pod. Aunque Istio sea capaz de gestionar un objeto Ingress, puede que no sea muy buena idea, por la flexibilidad de la alternativa descrita arriba. Dicho de otra forma, Istio gestiona los paquetes que entran en el cluster de forma propia, ésta resulta ser más apropiada que utilizar el convencional objeto Ingress.

Istio, con estos objetos, consigue un comportamiento similar al que se conseguiría con NetworkPolicies,aunque no de la misma forma.

En Istio, la comunicación no autorizada se bloquea tanto para Ingress, como para Egress. Para el Egress, se puede destacar un objeto: ServiceEntry.

  • ServiceEntry: El objeto ServiceEntry permite añadir servicios externos al clúster, al mesh. Es decir, si quisieramos acceder a “google.com”, por ejemplo, desde un pod de dentro del mesh, no podríamos a menos que añadiésemos un ServiceEntry permitiendo el acceso a “google.com”.

Monitorización

 

Para la gestión de logs y monitorización, los objetos son varios y se agrupan en tres tipos; ​instances, handlers y rules​. A continuación, vamos a ver qué son. Recordemos, de Mixer, que Istio tiene varios adaptadores, de herramientas muy popularesintegradas por defecto.

  • Instances: Un instance define los atributos que se deben pasar a un adaptador. Típicamente podría ser una métrica.
  • Handler: Un handler se encarga de entregar el atributo de forma correcta al adaptador. Si decimos que Istio tiene varios adaptadores integrados por defecto, estamos diciendo que tiene varios tipos de handlers pre-definidos.
  • Rule:​ Un rule enlaza un Instance a un handler.

Por ejemplo, si quisiéramos monitorizar una aplicación en Prometheus, crearíamos un objeto tipo metric que sería el ​instance​, en el cual definiríamos las métricas que queremos monitorizar. También crearíamos un objeto tipo prometheus​​, que sería el handler​​, donde definiríamos cómo queremos procesar y formatear las métricas. Por último, un objeto tipo ​rule enlazaría al ​instance con el handler​, para que Mixer sepa cómo actuar.

Istio, recoge por defecto las métricas del plano de control. Lo que hace que sea más fácil identificar ciertos problemas. Uno tendría que configurar solo las métricas de su aplicación. Debajo, un ejemplo de Grafana con con el ​dashboard​ de la malla de servicios.

Ejemplo dashboard Grafana

 

 

Próximamente publicaremos la segunda parte de este artículo, estad atentos.

 

 

 

¿Quieres saber más sobre Istio?