Tip Service Mesh Kong

Kuma

Introducción a Service Mesh

Durante los últimos años el uso de la arquitectura de microservicios no ha hecho más que crecer y convertirse en el estándar cuando se trata de nuevos desarrollos.

A grandes rasgos esta arquitectura consiste en separar toda la funcionalidad de nuestras aplicaciones en distintos componentes independientes, los servicios. Cada uno de estos servicios puede estar desarrollado utilizando tecnologías diferentes y la comunicación con otros servicios se realiza de forma síncrona o asíncrona (mediante http, grpc, colas de mensajería, service bus, etc.)

Conforme la cantidad de servicios que tenemos que gestionar crece y la comunicación entre servicios se vuelve más y más compleja, el esfuerzo requerido para gestionar correctamente todos estos elementos de forma tradicional aumenta exponencialmente.

Partiendo de esta necesidad ha surgido un nuevo componente encargado explícitamente de gestionar la comunicación entre los servicios, los service mesh. Estos proporcionan una forma consistente de conectar, securizar y monitorizar dichos servicios.

Generalmente cuando hablamos de service mesh muchas veces están enfocados a servicios que están desplegados sobre Kubernetes, pero cabe recordar que también se puede aplicar fuera de este entorno.

En la estructura típica del service mesh, cada uno de nuestros servicios está acompañado de un sidecar. Un pequeño servicio encargado de gestionar las comunicaciones. A todo este conjunto es a lo que generalmente se le conoce como data plane. Por otro lado, todos los componentes encargados de gestionar las políticas de comunicación entre servicios y gestionar el registro de los servicios entre otras funcionalidades se le conoce como control plane.

Introducción Kuma

Kuma es una de las últimas tecnologías en incorporarse a la lista de tecnologías enfocadas a dar soporte al service mesh y aún se encuentra en una fase relativamente temprana de su desarrollo. Actualmente ha sido donado a la CNCF (Cloud Native Computing Foundation).

Kuma ha sido desarrollado por Kong (La empresa que está detrás de Kong API Manager) teniendo como referencia los siguientes principios:

Ser universal
Ser simple
Ser escalable
Estar basada en Envoy (proxy cloud-native)

Funcionalidades Kuma

Entre las funcionalidades que principalmente destacan de Kuma sobre otros productos similares podemos destacar las siguientes.

Funciona sobre Kubernetes, VMs y bare metal

Uno de los puntos fuertes de Kuma es su versatilidad a la hora de dar soporte en diferentes entornos. Muchos service mesh se han centrado únicamente en entornos de contenedores (Kubernetes, Mesos). Kuma en cambio nació con la filosofía de ser una herramienta enfocada a ayudar en la transición hacia los contenedores. Por ello permite definir topologías híbridas. Estas pueden estar compuestas por elementos externos, como puede ser servicios funcionando en VMs o incluso sobre servidores sin ninguna virtualización.

Soporta multizona

Podemos tener distintos clusters gestionados por Kuma al mismo tiempo. Esto es realmente útil cuando tenemos aplicaciones que por ejemplo por la naturaleza de sus datos solo deben de conectarse a otros servicios dentro de su zona pero queremos gestionar toda la infraestructura de forma unificada. Permite definir múltiples topologías dentro del mismo cluster. Esto nos permite tener múltiples service mesh en el mismo sitio pero totalmente aislados de los otros en cuanto a la gestión de la propia red. Es un concepto novedoso que nos permite agrupar mejor los componentes de nuestra infraestructura.

Dashboard

El dashboard nos permite visualizar mediante una interfaz de usuario todos los componentes que están siendo gestionados por Kuma. Esto resulta realmente útil cuando queremos revisar la configuración de todo nuestro.

Monitorización

Kuma permite instalar su configuración por defecto para la monitorización de nuestro servicios. Esta consiste en el uso de Prometheus para el almacenado de datos y Grafana para su visualización. Por defecto Grafana viene con tres vistas configuradas:

Kuma Mesh: Vista resumida de los datos del service-mesh.
Kuma Dataplane: Visualización detallada de las métricas de un data-plane.
Kuma Service to Service: Métricas de conexión y tráfico entre servicios.

Tracing

Kuma soporta tracing L7 (capa de aplicación). Actualmente soporta Zipkin y Jaeger sin tener que realizar ninguna configuración especial.

Este tipo de herramientas son muy útiles para detectar cuellos de botella en nuestra topología de microservicios.

A continuación podemos ver la visualización de una llamada teniendo el tracing activado con Jaeger:

Arquitectura

Los dos componentes principales de Kuma son:

kuma-cp: Es el control plane. Puede escalar horizontalmente, es el encargado de realizar la orquestación.

kuma-dp: Es el data plane. Son el sidecar que se despliega con cada servicio y es el encargado de realizar la comunicación con otros servicios.

Cuando tenemos Kuma en modo Multi-Zona los componentes principales cambian un poco.

Por un lado ya no vamos a tener un kuma-cp sino múltiples. Por un lado tendremos un kuma-cp remoto por zona. Este será el encargado del DNS para resolver direcciones de servicios cuando se establece alguna comunicación s2s. Por otro lado el kuma-cp global es el encargado de gestionar las políticas y de transferirlas a los remotos cuando estos se conecten para actualizarse. Finalmente tenemos un nuevo componente, el kuma-dp ingress. Este es el encargado de gestionar el tráfico entre zonas.

La principal ventaja de un control plane centralizado es que podemos tener muchas redes aisladas siendo controladas por un único elemento. Esto nos permite reducir significativamente los costes operacionales. A continuación podemos ver una tabla resumen comparando este enfoque con los recursos utilizados por Istio.

Conclusiones

Aunque Kuma sea una solución nueva en el mundo de service mesh y aún no esté madura del todo parece tener un gran potencial. Con una configuración relativamente fácil podemos tener un service mesh multi-cluster, multi-cloud, híbrido (Kybernetes, VMs) y multi-mesh.

Por otro lado en cuanto a otras funcionalidades secundarias, como por ejemplo la visualización del tráfico de las distintas topologías, aún están lejos respecto a otros competidores (Istio) aunque tienen un Roadmap bastante interesante que vale la pena ir siguiendo para estar al día de las nuevas funcionalidades.

En resumen, es más simple y fácil de usar que otros, no ofrece tantas funcionalidades pero su enfoque “multi” de forma nativa hace que tenga un gran potencial.