Introducción a Service Mesh
En la entrada de hoy os queremos introducir el concepto de «Service Mesh» -o malla de servicios- en Kubernetes, y comparar varias implementaciones Open Source que se encuentran disponibles.
Según RedHat, un Service Mesh se utiliza para controlar la forma en que las distintas partes de una aplicación comparten datos entre sí. A diferencia de otros sistemas que también permiten administrar esta comunicación, la red de servicios es una capa de infraestructura específica integrada en la aplicación, que es visible y tiene la capacidad de registrar si la interacción entre las distintas partes de una aplicación es buena o mala. De esta manera, facilita la optimización de las comunicaciones y previene el downtime a medida que crece la aplicación.
Un Service Mesh nos puede ayudar a la operación y detección de problemas en entornos productivos en los que tengamos:
- Una arquitectura con múltiples microservicios comunicados entre sí.
- Que se encuentre comunicada con el exterior.
- Que necesitemos una estrategia de versionado de microservicios para publicar nuevas características en modo A/B Testing o friends and family
Para ello, estas mallas nos proporcionan las siguientes habilidades:
- Aseguramiento de la comunicación entre microservicios, con patrones como circuit-breaker, reintentos, gestión de errores, balanceo de carga inteligente y tolerancia a fallos.
- Descubrimiento de servicios dentro de un clúster o incluso fuera de él.
- Enrutamiento entre diferentes versiones o implementaciones de un servicio.
- Observabilidad, recolección de logs y trazas distribuidas, métricas de calidad y monitorización.
- Securización de comunicaciones entre microservicios, haciendo la terminación TLS.
Todas estas funcionalidades son posibles gracias a que «inyecta» un sidecar -en muchos casos Envoy Proxy– que nos permite añadir estas características al software existente de manera prácticamente transparente.
Además de estas características básicas, es importante revisar que el Service Mesh adoptado nos proporcione lo siguiente:
- Multi protocolo: TCP, HTTP 1/2, gRPC, etc.
- Soporte directo de nuestro proveedor Cloud/Kubernetes: lo cual nos permitirá una implantación sencilla.
- Control de tráfico: métricas, división (spliting) y control del tráfico.
- Integración con Grafana/Kibana.
Teniendo esto en mente, existen diferentes opciones Open Source que podemos utilizar. Los principales serían:
¿En qué se diferencian unos de otros? Veámoslo en la siguiente tabla comparativa:
| Linkerd | Istio | Consul Connect | Kuma | Traefik Mesh | |
| Licencia | Apache | Apache | Apache | Apache | Apache |
| Service Proxy | Linkerd Proxy | Envoy | Envoy | Envoy | Traefik |
| Recolección de logs | No | No | No | No | No |
| Prometheus integrado | Si | Si, con una extensión | No | Si | Si |
| Grafana integrado | Si | Si, con una extensión | No | Si | Si |
| Trazas distribuidas | Si, Open Telemetry | Si, Open Telemetry | Datadog, Jaeger, Zipkin | Si, Open Telemetry | Jaeger |
| Balanceo de carga avanzado | Si | Si | Si | Si | Si |
| Patrones de resilencia | Cicuit Breaking Reintentos Inyección de fallos Inyección de demoras | Cicuit Breaking Reintentos Inyección de fallos Inyección de demoras | Cicuit Breaking Reintentos | Cicuit Breaking Reintentos Inyección de fallos Inyección de demoras | Cicuit Breaking Reintentos |
| Terminación TLS | Si | Si | Si, usando el Vault de Hashicorp | Si | Si |
| Protocolos | Http 1/2, tcp, grpc | Http 1/2, tcp, grpc | Http 1/2, tcp, grpc | Http 1/2, tcp, grpc | Http 1/2, tcp, grpc |
Según lo visto, podemos descartar aquellos que no soportan Open Telemetry por ser el estándar de facto, y aquellos que no cubren todos los patrones de resilencia a fecha de hoy. Un punto de valor también es el uso de Envoy como Service Proxy, dado que es la implementación de referencia.
Por lo tanto, nuestra recomendación es el uso de Kuma o Istio, prefiriendo este último por tener integración y soporte en nuestras CaaS de referencia OpenShift y GKE en aquellos productos en entornos productivos.
Esperamos que os haya sido de interés, y si os surge alguna duda, por favor dejadnos un comentario.
Imagen de cabecera de Clint Adair en Unsplash
✍🏻 Author(s)
