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 la primera parte del artículo hablamos sobre la gestión del tráfico y de su monitorización.

Ventajas Istio

 

Clúster con Istio

Kubernetes, por defecto, viene sin algunos controladores. Ingress Controller y NetworkPolicy Controller, son algunos de ellos. Esta es una de las inconvenientes de utilizar Kubernetes en bare metal, que hay que adaptarlo al plano de control en el que corre y, por eso, soluciones como GKE o EKS son tan populares.

En GKE, se puede habilitar/instalar Istio al crear el clúster. Pero GKE ya tiene GCLB, que es el Ingress Controller de Kubernetes de Google y se puede instalar Calico al crear el clúster, como NetworkPolicy Controller, igual que Istio. Veamos cuál es la diferencia entre utilizar estos controladores e Istio.

Ingress Controller

Con GCLB y un objeto del tipo Ingress tenemos un Load Balancer de capa 7 (L7). Podemos redirigir el tráfico hacía un servicio u otro, dependiendo del host y el path de la solicitud. Esto es un mapeo uno-a-uno. Una misma solicitud siempre será redirigida hacia el mismo servicio, que irá a parar al mismo set de pods (backends).

Esta es una forma un poco rígida de gestionar el tráfico. Por ejemplo, para redirigir el 5% del tráfico a una versión “canary” de la aplicación, habría que crear 1 pod “canary” por cada 19 de la aplicación principal, y configurarlos para que sean apuntados por el mismo servicio. Aunque no hagan falta 20 pods para respaldar el tráfico, para conseguir el 95-5 deseado, es la única forma de conseguirlo.

Con Istio, esto es bastante más cómodo. Lo que hace Istio es añadir otro salto entre el servicio y el backend, dando una flexibilidad considerable. Se pueden definir tantos “sub-servicios” como necesarios, en cuyo caso el servicio haría un balanceo de carga homogénea entre los backends de cada “sub-servicio”, y si quisiéramos redirigir un 5% del tráfico a los backends de un “sub-servicio” específico, lo definiríamos explícitamente, al crearlo.

En la imagen de arriba, se puede ver que el Servicio 1 tiene dos versiones. Si no se especifica explícitamente, el tráfico será enviado por igual a las dos versiones. El Servicio 2 enviará un 95% de las solicitudes a la versión 1, y el 5% a la versión 2. Así, con 3 backends, se puede conseguir una versión “canary” sin complicarse.

También se puede configurar este comportamiento con ​headers. Por ejemplo, se puede forzar que las solicitudes desde un iPhone sean redirigidos a una versión de la aplicación, mientras que las solicitudes desde un Android, son respondidos por otra. El concepto de “sub-servicio”, en Istio, es el ​subset de un host,​que se especifica en un VirtualService.

NetworkPolicy Controller

Las ​NetworkPolicies son las reglas internas del clúster con respecto quién puede hablar con quién. El objeto ​NetworkPolicy ​permite agrupar un grupo de pods, por sus ​labels y aplicarles políticas de ​ingress, egress, o ambos. La política se aplica denegando todo tráfico hacia el grupo de pods seleccionado, y se permite el tráfico desde tres fuentes:

  • Pods de un namespace. Cualquierpod que haya sido creado en un namespace​ específico, puede comunicarse con el grupo de pods.
  • Pods con ciertos labels. Cualquier pod, desde cualquier namespace,​ con ciertos labels​, puede comunicarse con el grupo de pods.
  • Tráfico desde un bloque de IPs. Típicamente serían IPs internos, no pertenecientes al clúster. Pueden ser IPs internos al clúster, pero en ese caso sería más conveniente enfocarlo como los dos puntos anteriores.

Hay que decir que las NetworkPolicies​ son objetos bastante robustos y desaprovechados. El único inconveniente es que el controlador es de terceros y hay que buscar e instalar uno.

En Istio, no se configura nada directamente para este propósito, sino que pasa naturalmente al configurar las rutas. Como los proxies Envoy, dentro de la malla, están configurados para aceptar tráfico solo desde fuentes específicas, el resultado es similar, aunque con otro enfoque.

La gestión de logs y la monitorización de Istio, de la forma que lo hace, es algo nuevo, así que no se puede realmente comparar con ninguna otra solución. Quizás con Stackdriver (dentro de GCP), pero son de diferentes envergaduras, así que no haremos esa comparación en este artículo.

 

Conclusión

 

Personalmente encuentramos Istio una herramienta bastante cómoda y potente con que trabajar. Como una navaja suiza. Aunque no tengamos un clúster grande, el hecho de que los objetos estén integrados directamente en Kubernetes, la flexibilidad de enrutar el tráfico, la aplicación de políticas de complimiento, la gesta de logs y la monitorización hacen que Istio definitivamente sea de considerar para añadir a nuestra caja de herramientas.

Suren Danielyan
Training Manager & Cloud Technology Evangelist

Juan Carlos Moreno
CTO & Senior Cloud Engineer

 

¿Quieres saber más sobre Istio?