¡Hola, Habr! Presento a su atención la traducción del artículo. автора Matt Klein.
Esta vez, "quería y traduje" la descripción de ambos componentes de la malla de servicios, el plano de datos y el plano de control. Esta descripción me pareció la más comprensible e interesante y, lo más importante, la que me llevó a comprender la pregunta "¿Es realmente necesario?".
A medida que la idea de una "malla de servicios" 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 aumentado, he visto un aumento proporcional de la confusión entre todo el mundo. comunidad tecnológica sobre cómo comparar y contrastar diferentes soluciones.
La situación se resume mejor en la siguiente serie de tweets que escribí en julio:
Confusión de malla de servicio 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í solos no hacen nada. Deben estar de humor para algo más. 2/
Istio es un ejemplo de un plano de control que une las piezas. Esta es otra capa. /fin
Los tweets anteriores mencionan varios proyectos diferentes (Linkerd, NGINX, HAProxy, Envoy e Istio), pero lo más importante es que presentan los conceptos generales de plano de datos, malla de servicios y plano de control. En esta publicación, daré un paso atrás y hablaré sobre lo que quiero decir con los términos "plano de datos" y "plano de control" en un nivel muy alto, y luego hablaré sobre cómo se aplican los términos a los proyectos mencionados en los tweets.
¿Qué es realmente una malla de servicios?
Figura 1: descripción general de la malla de servicios
Figura 1 ilustra el concepto de una malla de servicios en su nivel más básico. Hay cuatro grupos de servicios (AD). Cada instancia de servicio está asociada con un servidor proxy local. Todo el tráfico de red (HTTP, REST, gRPC, Redis, etc.) de una única instancia de aplicación pasa a través de un proxy local a los clústeres de servicios externos apropiados. De esta manera, la instancia de la aplicación desconoce la red en su conjunto y solo conoce su proxy local. De hecho, la red del sistema distribuido fue eliminada del servicio.
Plano de datos
En una malla de servicios, un servidor proxy ubicado localmente para la aplicación realiza las siguientes tareas:
- Descubrimiento de servicios. ¿Qué servicios/aplicaciones están disponibles para su aplicación?
- control de salud. ¿Las instancias de servicio devueltas por el descubrimiento de servicios están en buen estado y listas para aceptar tráfico de red? Esto puede incluir comprobaciones de estado tanto activas (por ejemplo, respuesta/comprobación de estado) como pasivas (por ejemplo, utilizando 3 errores 5xx consecutivos como indicación de un estado de servicio incorrecto).
- Enrutamiento. Al recibir una solicitud a "/foo" de un servicio REST, ¿a qué grupo de servicios se debe enviar la solicitud?
- Balanceo de carga. Una vez que se ha seleccionado un clúster de servicios durante el enrutamiento, ¿a qué instancia de servicio se debe enviar la solicitud? ¿Con qué tiempo de espera? ¿Con qué ajustes de corte de circuito? Si la solicitud falla, ¿se debe volver a intentar?
- Autenticacion y autorizacion. Para solicitudes entrantes, ¿se puede identificar/autorizar criptográficamente el servicio de llamadas mediante mTLS o algún otro mecanismo? Si se reconoce/autoriza, ¿se le permite llamar a la operación solicitada (punto final) en el servicio o se debe devolver una respuesta no autenticada?
- Observabilidad. Se deben generar estadísticas detalladas, registros/registros y datos de seguimiento distribuido para cada solicitud para que los operadores puedan comprender el flujo de tráfico distribuido y los problemas de depuración a medida que surjan.
El plano de datos es responsable de todos los puntos anteriores de la malla de servicios. De hecho, el proxy local del servicio (sidecar) es el plano de datos. En otras palabras, el plano de datos es responsable de transmitir, reenviar y monitorear condicionalmente cada paquete de red que se envía hacia o desde un 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 proxy acerca de la ruta "/foo" al servicio B? ¿Cómo se pueden utilizar los datos de descubrimiento de servicios que se completan con las solicitudes de proxy? ¿Cómo se configuran los parámetros para equilibrio de carga, tiempo de espera, interrupción de circuito, etc.? ¿Cómo se implementa una aplicación utilizando el método azul/verde o el método de transición de tráfico elegante? ¿Quién configura los ajustes de autenticación y autorización en todo el sistema?
Todos los elementos anteriores están bajo el control del plano de control de la malla de servicio. El plano de control toma un conjunto de servidores proxy sin estado aislados 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 y plano de control es porque para la mayoría de las personas el plano de datos es familiar mientras que el plano de control es extraño o incomprendido. Llevamos mucho tiempo trabajando con enrutadores y conmutadores de redes físicas. Entendemos que los paquetes/solicitudes deben ir del punto A al punto B y que podemos usar hardware y software para hacerlo. La nueva generación de proxies de software son simplemente versiones sofisticadas de las herramientas que hemos estado usando durante mucho tiempo.
Figura 2: Plano de control humano
Sin embargo, llevamos mucho tiempo utilizando planos de control, aunque es posible que la mayoría de operadores de red no asocien esta parte del sistema con ningún componente tecnológico. La razón es sencilla:
La mayoría de los aviones de control que se utilizan hoy en día son... nosotros.
En figura 2 Muestra lo que yo llamo el “plano de control humano”. En este tipo de implementación, que sigue siendo muy común, un operador humano probablemente de mal humor crea configuraciones estáticas (potencialmente mediante scripts) y las implementa mediante algún proceso especial en todos los servidores proxy. Luego, los servidores proxy comienzan a usar esta configuración y comienzan a procesar el plano de datos usando la configuración actualizada.
Figura 3: Plano de control de malla de servicio avanzado
En figura 3 muestra el plano de control "extendido" de la malla de servicio. Consta de las siguientes partes:
- El humano: Todavía hay una persona (ojalá menos enojada) que toma decisiones de alto nivel con respecto a todo el sistema en su conjunto.
- Interfaz de usuario del plano de control: Una persona interactúa con algún tipo de interfaz de usuario para controlar el sistema. Podría ser un portal web, una aplicación de línea de comandos (CLI) o alguna otra interfaz. Usando la interfaz de usuario, el operador tiene acceso a parámetros de configuración global del sistema tales como:
- Control de despliegue, transición de tráfico azul/verde y/o gradual
- Opciones de autenticación y autorización
- Especificaciones de la tabla de enrutamiento, por ejemplo, cuando la aplicación A solicita información sobre "/foo", qué sucede
- Configuraciones del balanceador de carga, como tiempos de espera, reintentos, configuraciones de interrupción de circuitos, etc.
- Programador de carga de trabajo: Los servicios se ejecutan en la infraestructura a través de algún tipo de sistema de programación/orquestación, como Kubernetes o Nomad. El planificador es responsable de cargar el servicio junto con su proxy local.
- Descubrimiento de servicios. Cuando el programador inicia y detiene instancias de servicio, informa el estado de salud al sistema de descubrimiento de servicios.
- API de configuración de proxy sidecar : Los proxies locales extraen dinámicamente el estado de varios componentes del sistema utilizando un modelo eventualmente consistente sin intervención del operador. Todo el sistema, que consta de todas las instancias de servicio actualmente en ejecución y servidores proxy locales, finalmente converge en un ecosistema. La API del plano de datos universal de Envoy es un ejemplo de cómo funciona esto en la práctica.
Esencialmente, el propósito del plano de control es establecer la política que finalmente será aceptada por el plano de datos. Los aviones de control más avanzados eliminarán más piezas de algunos sistemas del operador y requerirán menos operación manual, ¡siempre que funcionen correctamente!...
Plano de datos y plano de control. Resumen del plano de datos frente al plano de control
- Plano de datos de malla de servicio: Afecta a todos los paquetes/solicitudes del sistema. Responsable del descubrimiento de aplicaciones/servicios, verificación de estado, enrutamiento, equilibrio de carga, autenticación/autorización y observabilidad.
- Plano de control de malla de servicio: proporciona política y configuración para todos los planos de datos en ejecución dentro de la red de servicio. No toca ningún paquete/solicitud en el sistema. El plano de control convierte todos los planos de datos en un sistema distribuido.
Panorama actual del proyecto
Habiendo entendido la explicación anterior, veamos el estado actual del proyecto de malla de servicios.
- Planos de datos: Linkerd, NGINX, HAProxy, Envoy, Traefik
- Aviones de control: Istio, Nelson, SmartStack
En lugar de entrar en un análisis en profundidad de cada una de las soluciones anteriores, abordaré brevemente algunos de los puntos que creo que están causando gran parte de la confusión en el ecosistema en este momento.
Linkerd fue uno de los primeros servidores proxy del plano de datos para la malla de servicios a principios de 2016 y ha hecho un trabajo fantástico al generar conciencia y atención sobre el modelo de diseño de la malla de servicios. Aproximadamente 6 meses después de eso, Envoy se unió a Linkerd (aunque había estado en Lyft desde finales de 2015). Linkerd y Envoy son los dos proyectos que se mencionan con más frecuencia cuando se habla de mallas de servicios.
Istio se anunció en mayo de 2017. Los objetivos del proyecto Istio son muy similares al plano de control extendido que se muestra en figura 3. Envoy for Istio es el proxy predeterminado. Por tanto, Istio es el plano de control y Envoy es el plano de datos. En poco tiempo, Istio generó mucho entusiasmo y otros planos de datos comenzaron a integrarse como reemplazo de Envoy (tanto Linkerd como NGINX demostraron integración con Istio). El hecho de que se puedan utilizar diferentes planos de datos dentro del mismo plano de control significa que el plano de control y el plano de datos no están necesariamente estrechamente acoplados. Una API como la API genérica del plano de datos de Envoy puede formar un puente entre dos partes del sistema.
Nelson y SmartStack ayudan a ilustrar mejor la separación del plano de control y el plano de datos. Nelson utiliza Envoy como proxy y construye un plano de control confiable para la malla de servicios basado en la pila de HashiCorp, es decir. Nómada, etcétera. SmartStack fue quizás el primero de una nueva ola de mallas de servicios. SmartStack construye un plano de control alrededor de HAProxy o NGINX, lo que demuestra la capacidad de desacoplar el plano de control de la malla de servicios del plano de datos.
La arquitectura de microservicios con una malla de servicios está ganando cada vez más atención (¡con razón!), y cada vez más proyectos y proveedores están empezando a trabajar en esta dirección. En los próximos años veremos mucha innovación tanto en el plano de datos como en el plano de control, así como una mayor combinación de diferentes componentes. En última instancia, la arquitectura de microservicios debería volverse más transparente y mágica (?) para el operador.
Ojalá cada vez esté menos irritado.
Conclusiones clave
- Una malla de servicio consta de dos partes diferentes: el plano de datos y el plano de control. Se requieren ambos componentes y sin ellos el sistema no funcionará.
- Todo el mundo está familiarizado con el plano de control y, en este punto, ¡el plano de control podrías ser tú!
- Todos los planos de datos compiten entre sí en características, rendimiento, configurabilidad y extensibilidad.
- Todos los planos de control compiten entre sí en características, configurabilidad, extensibilidad y facilidad de uso.
- Un plano de control puede contener las abstracciones y API adecuadas para que se puedan utilizar varios planos de datos.
Fuente: habr.com