¡Hola, Habr! Les presento la traducción del artículo «Plano de datos del service mesh vs plano de control» autor Matt Klein.

Esta vez se ha ‘deseado y traducido’ la descripción de ambos componentes del service mesh, el plano de datos y el plano de control. Esta descripción me pareció la más clara e interesante, y lo más importante, nos lleva a comprender ‘¿realmente es necesario?’.

Dado que la idea de ‘Service Mesh’ se ha vuelto cada vez más popular en los últimos dos años (artículo original del 10 de octubre de 2017), y el número de participantes en el espacio ha crecido, he visto un crecimiento proporcional de la confusión dentro de toda la comunidad técnica con respecto a cómo comparar y contrastar diferentes soluciones.

La situación se describe mejor con las siguientes series de tuits que escribí en julio:

Confusión con el service mesh nº 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. Ninguno de ellos es igual a Istio. Istio es algo completamente diferente. 1 /

Los primeros son simplemente planos de datos. Por sí mismos no hacen nada. Deben configurarse para algo más. 2 /

Istio es un ejemplo de un plano de control que conecta las piezas juntas. Es una capa diferente. /fin

En los tuits anteriores se mencionan varios proyectos diferentes (Linkerd, NGINX, HAProxy, Envoy e Istio), pero, más importante aún, se introducen conceptos generales como plano de datos, service mesh y plano de control. En esta publicación, daré un paso atrás y explicaré lo que quiero decir con ‘plano de datos’ y ‘plano de control’ a un nivel muy alto, y luego discutiré cómo se relacionan estos términos con los proyectos mencionados en los tuits.

¿Qué es realmente un service mesh?

Figura 1: Resumen del service mesh

Figura 1 ilustra la concepción de un service mesh a un nivel muy básico. Hay cuatro clústeres de servicio (A-D). Cada instancia del servicio está conectada a un proxy local. Todo el tráfico de red (HTTP, REST, gRPC, Redis, etc.) de cada instancia de aplicación se envía a través del proxy local a los clústeres de servicio externos correspondientes. Así, la instancia de la aplicación no conoce toda la red y solo sabe de su proxy local. De hecho, la red del sistema distribuido se ha abstraído del servicio.

Plano de datos

En un service mesh, el proxy ubicado localmente para la aplicación realiza las siguientes tareas:

• Descubrimiento de servicios. ¿Qué servicios / aplicaciones están disponibles para su aplicación?
• Verificación de salud. ¿Son las instancias de servicio devueltas por el descubrimiento de servicios operativas y están listas para aceptar tráfico de red? Esto puede incluir tanto verificaciones activas (por ejemplo, una verificación de respuesta) como pasivas (por ejemplo, utilizando 3 errores 5xx consecutivos como indicación de un estado no saludable del servicio).
• Enrutamiento. Al recibir una solicitud REST al " /foo", ¿a qué clúster de servicios debería enviarse la solicitud?
• Balanceo de carga. Después de que se seleccionó un clúster de servicios durante el enrutamiento, ¿a qué instancia de servicio debe enviarse la solicitud? ¿Con qué tiempo de espera? ¿Con qué configuraciones de interrupción de circuitos? Si la solicitud falla, ¿debe repetirse?
• Autenticación y autorización. Para las solicitudes entrantes, ¿puede el servicio llamador ser criptográficamente identificado / autorizado mediante mTLS o algún otro mecanismo? Si es identificado / autorizado, ¿tiene permiso para invocar la operación solicitada (endpoint) en el servicio o debe devolverse una respuesta no autenticada?
• Observabilidad. Para cada solicitud deben generarse métricas detalladas, registros y datos de trazabilidad distribuida, para que los operadores puedan comprender el flujo de tráfico distribuido y los problemas de depuración a medida que surgen.

Por todos los puntos anteriores en la red de servicios, es responsable el plano de datos. En esencia, la proxy local del servicio (sidecar) es el plano de datos. Dicho de otra manera, el plano de datos es responsable de la transmisión condicional, el reenvío y la observación de cada paquete de red que se envía o se recibe del servicio.

El plano de control

La abstracción de red que proporciona un proxy local en el plano de datos es mágica (?). Sin embargo, ¿cómo sabe realmente el servidor proxy la ruta «/foo» hacia el servicio B? ¿Cómo se pueden utilizar los datos de descubrimiento de servicios que se completan con solicitudes del proxy? ¿Cómo se configuran los parámetros de balanceo de carga, tiempo de espera (timeout), ruptura de circuito (circuit breaking), etc.? ¿Cómo se implementa una aplicación utilizando el método azul/verde (blue/green) o el método de transición gradual del tráfico? ¿Quién configura los parámetros de autenticación y autorización del sistema en general?

Todos los puntos anteriores están bajo la administración del plano de control (control plane) de la malla de servicios (service mesh). El plano de control (control plane) toma un conjunto de proxies aisladosservidores sin estado y los convierte en un sistema distribuido.

Creo que la razón por la que muchos tecnólogos encuentran confusos los conceptos separados de plano de datos (data plane) y plano de control (control plane) es que para la mayoría de las personas, el plano de datos es familiar, mientras que el plano de control es ajeno/incomprensible. Durante mucho tiempo hemos trabajado con enrutadores y conmutadores de red físicos. Entendemos que los paquetes/solicitudes deben ir del punto A al punto B, y que podemos utilizar hardware y software para ello. La nueva generación de proxies de software son simplemente versiones modernas de herramientas que hemos estado utilizando por mucho tiempo.

Figura 2: Plano de control humano (Human control plane)

Sin embargo, hemos estado utilizando planos de control (control plane) durante mucho tiempo, aunque la mayoría de los operadores de red pueden no relacionar esta parte del sistema con ningún componente tecnológico. La razón es sencilla:
La mayoría de los planos de control (control plane) utilizados hoy en día son... nosotros.

En en la figura 2 Lo que muestro es lo que llamo "Plano de control humano (Human control plane)". En este tipo de implementación, que todavía se encuentra con mucha frecuencia, un operador humano, probablemente malhumorado, crea configuraciones estáticas — potencialmente con la ayuda de scripts — y las despliega a través de algún proceso especial en todos los servidores proxy. Luego, los proxies comienzan a utilizar esta configuración y comienzan a procesar el plano de datos (data plane) utilizando los ajustes actualizados.

Figura 3: Plano de control de la malla de servicios avanzada (Advanced service mesh control plane)

En en la figura 3 se muestra el "plano de control ampliado (control plane)" de la malla de servicios (service mesh). Se compone de las siguientes partes:

• El humano (The human): Todavía hay un humano (espero que menos enojado) que toma decisiones a un alto nivel respecto a todo el sistema en general.
• Interfaz de usuario del plano de control (Control plane UI): El humano interactúa con algún tipo de interfaz de usuario para gestionar el sistema. Esto puede ser un portal web, una aplicación de línea de comandos (CLI) o alguna otra interfaz. A través de la interfaz de usuario, el operador tiene acceso a ciertos parámetros de configuración global del sistema, como:
  • Gestión de implementación, azul/verde (blue/green) y/o con un gradual traslado de tráfico
  • Opciones de autenticación y autorización
  • Especificaciones de la tabla de rutas, por ejemplo, cuando la aplicación A solicita información sobre “/foo”, qué sucede
  • Configuraciones del equilibrador de carga, como tiempos de espera (timeouts), reintentos (retries), opciones de ruptura de circuito (circuit breaking), etc.
• Programador de cargas de trabajo (Workload scheduler): Los servicios se lanzan en la infraestructura a través de un sistema de programación/orquestación de cierto tipo, como Kubernetes o Nomad. El programador se encarga de cargar el servicio junto con su proxy local.
• Descubrimiento de servicios (Service discovery). Cuando el programador inicia y detiene instancias del servicio, informa sobre el estado de disponibilidad al sistema de descubrimiento de servicios.
• APIs de configuración del proxy local (Sidecar proxy configuration APIs) : Los proxies locales extraen dinámicamente el estado de varios componentes del sistema según el modelo de «consistencia eventual» sin intervención del operador. Todo el sistema, compuesto por todas las instancias de servicios y proxies locales en ejecución, converge eventualmente en un ecosistema único. La API del plano de datos universal en Envoy es un ejemplo de cómo esto funciona en la práctica.

En esencia, el objetivo del plano de control es establecer la política que eventualmente será adoptada por el plano de datos. Los planos de control más avanzados eliminarán más detalles de ciertos sistemas del operador y requerirán menos intervención manual, siempre que funcionen correctamente...

Plano de datos y plano de control. Resumen (Data plane vs. control plane summary)

• Plano de datos de la red de servicios (Service mesh data plane): afecta a cada paquete / solicitud en el sistema. Se encarga de la detección de aplicaciones / servicios, verificación de estado, enrutamiento, distribución de carga, autenticación / autorización y observabilidad.
• Plano de control de la red de servicios (Service mesh control plane): proporciona políticas y configuraciones para todos los planos de datos operativos dentro de la red de servicios. No toca ningún paquete / solicitud en el sistema. El plano de control convierte todos los planos de datos en un sistema distribuido.

Estado actual del proyecto (Current project landscape)

Una vez que hemos abordado la explicación anterior, veamos el estado actual del proyecto de la red de servicios (service mesh).

• Planos de datos (Data planes): Linkerd, NGINX, HAProxy, Envoy, Traefik
• Planos de control (Control planes): Istio, Nelson, SmartStack

En lugar de realizar un análisis profundo de cada una de las soluciones mencionadas, tocaré brevemente algunos puntos que, en mi opinión, generan la mayor parte de confusión en el ecosistema en este momento.

A principios de 2016, Linkerd fue uno de los primeros proxies de la capa de datos (data plane) para redes de servicios (service mesh) y logró un trabajo excepcional para aumentar la conciencia y la atención hacia el modelo de diseño de «red de servicios» (service mesh). Aproximadamente seis meses después, Envoy se unió a Linkerd (aunque había estado trabajando en Lyft desde finales de 2015). Linkerd y Envoy son los dos proyectos que se mencionan más a menudo en las discusiones sobre redes de servicios (service mesh).

Istio fue anunciado en mayo de 2017. Los objetivos del proyecto Istio son muy similares a los de la capa de control (control plane) mostrada en en la figura 3. Envoy para Istio es el proxy «por defecto». Así que, Istio es la capa de control (control plane) y Envoy es la capa de datos (data plane). En poco tiempo, Istio causó mucho revuelo, y otras capas de datos (data plane) comenzaron a integrarse como sustitutos de Envoy (tanto Linkerd como NGINX demostraron integración con Istio). El hecho de que en una capa de control (control plane) se puedan utilizar diferentes capas de datos (data plane) significa que la capa de control (control plane) y la capa de datos (data plane) no tienen que estar necesariamente interconectadas. Una API como la API universal de la capa de datos (data plane) de Envoy puede formar un puente entre las dos partes del sistema.

Nelson y SmartStack ayudan a ilustrar aún más la separación entre la capa de control (control plane) y la capa de datos (data plane). Nelson utiliza Envoy como su proxy y construye una sólida capa de control (control plane) para la red de servicios (service mesh) basada en la pila de HashiCorp, es decir, Nomad, etc. SmartStack se ha convertido en el primer representante de una nueva ola de redes de servicios (service mesh). SmartStack forma una capa de control (control plane) alrededor de HAProxy o NGINX, demostrando la posibilidad de desacoplar la capa de control (control plane) de la red de servicios (service mesh) y la capa de datos (data plane).

La arquitectura de microservicios con malla de servicios (service mesh) está atrayendo cada vez más atención (¡correcto!) y cada vez más proyectos y proveedores comienzan a trabajar en esta dirección. En los próximos años, veremos muchas innovaciones tanto en los planos de datos (data plane) como en los planos de control (control plane), así como la mezcla continua de diferentes componentes. En última instancia, la arquitectura de microservicios deberá volverse más transparente y mágica (?) para el operador.
Espero que cada vez sea menos molesto.

Puntos clave (Key takeaways)

• La malla de servicios (service mesh) se compone de dos partes diferentes: el plano de datos (data plane) y el plano de control (control plane). Ambos componentes son obligatorios, y sin ellos el sistema no funcionará.
• Todos están familiarizados con el plano de control (control plane), y ¡en este momento, el plano de control (control plane) puedes ser tú!
• Todos los planos de datos (data plane) compiten entre sí en funciones, rendimiento, configuración y escalabilidad.
• Todos los planos de control (control plane) compiten entre sí en funciones, configurabilidad, escalabilidad y facilidad de uso.
• Un plano de control (control plane) puede contener las abstracciones y API correctas para que se puedan usar múltiples planos de datos (data plane).

Fuente: habr.com