¿Qué es Service Mesh?

Introducción a Service Mesh

Service mesh es una infraestructura configurable utilizada para gestionar las comunicaciones entre servicios de sistemas de microservicios. Su objetivo es procesar el tráfico entre microservicios, también conocido como tráfico este-oeste.

En aplicaciones nativas de la nube, una aplicación puede consistir en cientos de servicios. Cada servicio podría tener múltiples instancias, y cada una de esas instancias podría estar cambiando constantemente. En un entorno de ejecución tan complejo, cómo proporcionar a los usuarios un acceso confiable y mantener los servicios funcionando de manera estable se ha convertido en un gran desafío. Así nació una solución llamada service mesh.

Service mesh es como el TCP/IP entre microservicios, que maneja funciones entre servicios como llamadas de red, limitación de tasa, monitoreo, etc. Principalmente aplicamos service mesh en la plataforma Kubernetes. Además, el patrón más clásico se llama sidecar, que abstrae algunas funciones generales en el contenedor sidecar y lo monta junto con el contenedor de servicio en el mismo pod. La siguiente imagen demuestra por qué se llama service mesh.

Sidecar no es el único patrón que aplica service mesh; además de eso, tenemos el patrón DaemonSet y el patrón Ambient mesh:

• La diferencia entre el patrón DaemonSet y el patrón sidecar es que el patrón DaemonSet solo permite que cada nodo en el clúster de Kubernetes ejecute un pod, y este pod funciona como un proxy sidecar. En comparación con el patrón sidecar, el patrón DaemonSet utiliza muchos menos recursos de la máquina, pero tiene desventajas como un aislamiento deficiente, llamadas de recursos difíciles de predecir, etc. Puedes encontrar más diferencias en este artículo: Sidecars y DaemonSets: Batalla de patrones de contenedorización.

• Ambient mesh es un nuevo modo de plano de datos introducido por Istio el 7 de septiembre de 2022. Para resolver el problema de acoplamiento de la infraestructura y despliegue del mesh, Ambient mesh separa el proxy del plano de datos del pod de la aplicación para que pueda desplegarse por separado.

Ambient mesh divide el plano de datos en una capa de superposición segura y una capa de procesamiento L7: La capa de superposición segura maneja funciones como enrutamiento TCP, métricas de monitoreo, registro de acceso, túnel mTLS; además de todas las funciones de la capa de superposición segura, la capa de procesamiento L7 tiene muchas más funciones como control de tráfico sobre enrutamiento HTTP, observabilidad y logra políticas de autorización L7 ricas.

Además, Ambient mesh utiliza un agente compartido llamado ztunnel (túnel de confianza cero), que se ejecuta en cada nodo dentro del clúster de Kubernetes y conecta y autentica de manera segura las cargas de trabajo dentro del mesh. Puedes leer este artículo si deseas conocer detalles sobre el modo Ambient mesh: Introducing Ambient Mesh

¿Por qué necesitamos service mesh?

Antes de que service mesh se popularizara, la gobernanza de servicios de muchas arquitecturas de microservicios se lograba a través de la colaboración del marco de microservicios con la plataforma de control. Sin embargo, este método tiene los siguientes problemas:

1. Acoplamiento estrecho entre el marco y el servicio, por lo que su dificultad y complejidad de mantenimiento general se vuelven muy altas. Además, los desarrolladores necesitan entender bibliotecas públicas, lo que les impide concentrarse en las implementaciones del servicio.
2. Necesita mantener un marco de múltiples lenguajes, lo que aumenta los costos de mantenimiento.
3. El microservicio tiene un alto costo de actualización, y generalmente necesita reiniciar el servicio durante la actualización.
4. Existen marcos con muchas versiones diferentes en línea, lo que obliga a las personas a considerar una compatibilidad compleja.

Para resolver los problemas anteriores, el ex ingeniero de Twitter Willian Morgan, uno de los fundadores de Linkerd, propuso el concepto de "Service Mesh". Service mesh utiliza un patrón sidecar para desacoplar la infraestructura de la lógica del servicio sin afectar la aplicación, lo que logra una actualización y O&M unificada en cuanto al lenguaje.

Service mesh traslada funciones como control de tráfico, observabilidad y comunicaciones seguras a los componentes básicos; por lo tanto, los desarrolladores no necesitan preocuparse por las implementaciones concretas de la capa de comunicación y la gestión del servicio. Los desarrolladores podrían dejar todo el trabajo sucio relacionado con la comunicación a service mesh y concentrarse en el desarrollo del servicio. Basado en estas características, service mesh podría ayudarnos a resolver esos problemas mencionados anteriormente.

¿Cómo funciona service mesh?

Service mesh no agregaría nuevas funciones al entorno de ejecución de la aplicación, por lo que todas las aplicaciones dentro de un marco aún necesitan reglas correspondientes para especificar cómo enviar solicitudes de A a B. La diferencia es que service mesh extraería las comunicaciones entre servicios de la gestión de lógica y luego las abstraería en una capa de infraestructura.

Actualmente, la mayoría de los service meshes utilizan la arquitectura de plano de datos + plano de control, que se muestra a continuación:

El plano de control

El plano de control gestiona y configura el plano de datos y lleva a cabo estrategias mientras se ejecuta el servicio. Todas las instancias dentro del plano de control con un solo service mesh compartirían los mismos recursos de configuración.

El plano de control se enfoca más en la entrega y estrategias como seguridad, observabilidad y control de tráfico. También recopilará y recogerá datos de telemetría del plano de datos para que DevOps pueda utilizarlos.

El plano de datos

El plano de datos generalmente funciona como un proxy y consiste en muchos proxies sidecar. Sidecar se ejecutaría en paralelo con las instancias del servicio y controlaría el tráfico de la aplicación de servicio interceptando el flujo de datos del servicio.

Como mencionamos anteriormente, el service mesh se logra implementando un patrón sidecar en Kubernetes y envolviéndolo como un contenedor. Sidecar sugiere usar un contenedor adicional para expandir y fortalecer el contenedor principal, y este contenedor adicional se llama contenedor sidecar, que se asigna en el mismo pod que el contenedor de servicio. Por otro lado, el service mesh es una red en malla que consiste en esos proxies sidecar.

Aplicaciones de service mesh

En la arquitectura de microservicios, los ingenieros generalmente cifrarían los servicios públicos expuestos o limitarían el acceso para proteger el servicio, pero ignoran la seguridad de la comunicación dentro de los clústeres. Hasta ahora, muchas aplicaciones de microservicios aún carecen de cifrado en la comunicación entre servicios, y el tráfico interno del clúster incluso se transfiere en formato de datos sin procesar. Como resultado, el tráfico interno es muy susceptible a ataques de escucha y MITM (Man-in-the-middle attack).

Para evitar ataques contra el tráfico interno del clúster, utilizamos mTLS para cifrar los datos del tráfico. mTLS podría asegurar la seguridad de la comunicación entre microservicios dentro del service mesh. Utiliza tecnología de cifrado para autenticar cada microservicio y cifrar el tráfico entre servicios mutuamente.

Aunque podríamos definir directamente la estrategia de seguridad de la comunicación dentro del microservicio e implementar autenticación de identidad y cifrado, sigue siendo muy ineficiente implementar la misma función individualmente en cada microservicio. Agregar una nueva función tiene que modificar los códigos del servicio e invadir la lógica del servicio. Además, incluso si pudiéramos implementar la nueva función, las iteraciones posteriores, actualizaciones y pruebas aún requerirían que los desarrolladores pasen más tiempo en mantenimiento. Por lo tanto, los desarrolladores no podrían concentrarse en el desarrollo de la función del servicio.

En cambio, si usamos service mesh, podríamos proporcionar comunicación mTLS sin que el servicio original necesite estar al tanto. Por lo tanto, en el service mesh, trasladamos todas las funciones relacionadas con la comunicación a los proxies sidecar.

Cuando dos microservicios necesitan comunicarse, el proxy sidecar primero establecerá una conexión mTLS, y enviará tráfico cifrado a través de esta conexión mTLS. Sidecar cambiará certificados y se autenticará mutuamente mediante la autoridad de certificación. Antes de conectarse, el sidecar examinará la estrategia de autenticación enviada por el plano de control para determinar si permite que el microservicio se comunique. Si se permite la comunicación, sidecar utilizará la clave de comunicación generada para establecer conexiones seguras y cifrar los datos de comunicación entre microservicios. Durante todo el proceso, las aplicaciones de servicio no se verán afectadas, reduciendo así las molestias de los desarrolladores.

A partir de este escenario, todos pueden entender por qué service mesh podría expandir las funciones actuales sin afectar el servicio actual. Pero, por supuesto, aparte de lograr la función de configuración de seguridad del tráfico interno, que es similar a mTLS, service mesh también podría expandir rápidamente funciones como control de tráfico, observabilidad y protocolo de codec modificando la configuración del plano de control.

Conclusión

Este artículo introduce brevemente los conceptos básicos del service mesh, su principio de funcionamiento y los beneficios que nos brinda. Service mesh revoluciona la arquitectura de microservicios y ayuda a los desarrolladores a deshacerse del complejo entorno de ejecución de microservicios para concentrarse en el desarrollo de la función del servicio.

Aunque service mesh resuelve muchos puntos de dolor en la arquitectura de microservicios, todavía tiene limitaciones. La complejidad del desarrollo de software es eterna, y simplemente se transfiere de una parte a otra. Cuando abstraemos la gestión del servicio en una capa separada, tenemos que enfrentar dificultades adicionales de O&M y aumentos en los enlaces de tráfico. Además, service mesh necesita usarse en un entorno nativo de la nube, lo que establece un listón más alto para la capacidad profesional y la experiencia laboral de ingeniería de DevOps. Es por eso que decimos que la tecnología es solo una herramienta para resolver problemas, pero necesitamos sopesar los beneficios que service mesh trae según su aplicación práctica.

Con el desarrollo explosivo de la nube nativa y la optimización del service mesh, service mesh probablemente reemplazará por completo la arquitectura de microservicios en el futuro y se convertirá en la primera opción de la arquitectura de reconstrucción de microservicios y nube nativa de cada empresa.

Si deseas saber más sobre la gestión de API, contáctanos cuando quieras: https://api7.ai/contact.