Soy Òscar Mas y hoy me gustaría enseñaros una de las herramientas más fascinantes de Kubernetes: Istio.
Qué es Istio y qué papel tiene dentro de Kubernetes
El significado de Istio viene de una palabra griega que significa "vela", esta palabra combina muy bien con el resto del ecosistema de Kubernetes.
Istio es una herramienta que comprende muchos ámbitos dentro de la infraestructura de Kubernetes, que mucha gente utiliza (tiene una gran comunidad detrás) y se está convirtiendo en un referente gracias al cambio de paradigma que ha marcado Kubernetes, con la deprecación del Ingress y a favor del Gateway API (no confundir con API Gateway).
Qué funcionalidades ofrece Istio
Hay que tener en cuenta que Istio no solo es un Gateway API, tiene muchas más funcionalidades como podrían ser:
- Service Mesh: esta filosofía tiene muchos conceptos y herramientas, pero vendría a ser una forma de gestionar la comunicación entre nuestros contenedores, esta definición es un buen punto de partida.
- mTLS: es el mecanismo que permite enviar la comunicación entre los diferentes contenedores de manera encriptada y segura.
- Gestión de políticas de capa 7.
- Observabilidad de lo que está sucediendo dentro de nuestro clúster.
- y un montón de cosas más...
A consecuencia de que Istio es un producto tan versátil y con tantas opciones, la complejidad que tiene es bastante alta en comparación con otros competidores. También debe quedar claro que si solo queremos utilizar uno de los servicios como podría ser el Gateway API, realmente es igual que sus competidores. Pero Istio tiene muchas más cosas interesantes.
Las capacidades clave de Istio
Podríamos decir que sus puntos fuertes son:
Service resilience
Es la idea de que los servicios continúan funcionando correctamente, aunque falle alguna cosa.
Observability
Es la monitorización de lo que está pasando dentro de nuestro clúster de Kubernetes. Para poder entender, depurar y solucionar las anomalías o los problemas que nos puedan suceder.
Traffic Control
Es la gestión del tráfico que se hace entre los contenedores de nuestro clúster y todo esto a nivel de capa 7.
Security
Es la protección que se puede gestionar entre los diferentes servicios de manera automática, consistente y basada en la identidad (no en la IP).
Policy enforcement
Es hacer cumplir las normas dictadas en nuestro clúster: seguridad, tráfico, acceso, etc... la idea básicamente es que aunque la aplicación esté mal configurada, la política de seguridad se aplicará pase lo que pase.
Service Mesh vs Ambient Mesh
Mucha gente confunde los conceptos de Service Mesh y Ambient Mesh, vamos a arrojar un poco de luz sobre estas ideas.
El concepto de estas ideas es el mismo, pero la implementación que debemos aplicar para conseguir cada una es muy diferente. El concepto en general es controlar lo que está sucediendo dentro de nuestro clúster de Kubernetes con todas las funcionalidades que se han ido explicando al principio.
Service Mesh
La primera cosa que debemos tener en cuenta es que la palabra Service Mesh es genérica y hay muchos otros productos que se pueden desplegar para conseguir un sistema de Service Mesh, como podría ser: LinkerD, Consul Connect, Cilium Service Mesh y un montón de etcéteras.
Para decirlo de una manera sencilla, la idea del Service Mesh es añadir a todos nuestros servicios un firewall, para gestionar, controlar y visualizar lo que está pasando. Explicándolo de una manera más técnica, lo que se hace es que a cada servicio se le añade un sidecar que tiene un Envoy Proxy.
Este sistema de añadir un Sidecar a nuestros servicios, como es normal, tiene una carga adicional. Aunque el coste por servicio es pequeño, si tenemos muchos servicios o nuestro clúster es muy grande, puede significar una sobrecarga.
Ambient Mesh
En el caso de la palabra Ambient Mesh, no es una palabra genérica, está asociada a Istio y como es normal, tenemos diferentes productos en el mercado como por ejemplo: Cilium Service Mesh, que hace lo mismo.
El punto más importante del Ambient Mesh es que se basa en eBPF, y esto quiere decir que nuestro sistema de CNI que hemos implementado en nuestro clúster debe estar gestionado por eBPF, si no, no funcionará.
La gran ventaja entre el Service Mesh y el Ambient Mesh es que en este caso dejamos totalmente el sistema de sidecars de Envoy que utilizaba el Service Mesh y nos centramos en dos piezas:
ztunnel:
- Gestión de capa 4
- Reemplaza los sidecars y funciona como DaemonSet
- Su funcionalidad es interceptar el tráfico de entrada y salida del nodo de Kubernetes
waypoint:
- Gestión de la capa 7
- Se gestiona por NameSpace
- Su funcionalidad es el routing de tráfico, la observabilidad y policy enforcement
Espero que este artículo os haya ayudado a entender qué es Istio en Kubernetes. Soy consciente de que no he dicho todas las funcionalidades que nos puede dar Istio, pero creo que estas son las más interesantes.
