Casos de uso de malla de servicios

Nota. traducir: El autor de este artículo (Luc Perkins) es un defensor de los desarrolladores en la organización CNCF, que alberga proyectos de código abierto como Linkerd, SMI (Service Mesh Interface) y Kuma (por cierto, ¿te has preguntado también por qué Istio es ¿No estás en esta lista? .). Una vez más, tratando de brindarle a la comunidad DevOps una mejor comprensión de la moda popular llamada "malla de servicios", enumera 16 capacidades características que brindan este tipo de soluciones.

Hoy malla de servicio ― uno de los temas más candentes en el campo de la ingeniería de software (¡y con razón!). Creo que esta tecnología es increíblemente prometedora y me gustaría que se adoptara ampliamente (cuando tenga sentido, por supuesto). Sin embargo, para la mayoría de la gente todavía está rodeada de un aura de misterio. Al mismo tiempo, incluso aquellos que bien conocido con él, a menudo es difícil articular sus ventajas y qué es exactamente (incluido un servidor). En este artículo intentaré corregir la situación enumerando varios casos de uso "mallas de servicio"*.

* Nota transl.: aquí y más adelante en el artículo exactamente esta traducción (“service mesh”) se utilizará para el término aún nuevo service mesh.

Pero primero quiero hacer algunos comentarios:

Nunca he trabajado con mallas de servicios ni las he usado fuera de proyectos iniciados para mi propia educación. Por otro lado, fui yo quien escribió un montón de documentación para la malla de servicios interna de Twitter en 2015 (en aquel entonces ni siquiera se llamaba "malla de servicios") y participé en el desarrollo del sitio web y la documentación para Linkerd, entonces eso significa algo.
Mi lista es aproximada e incompleta. Es posible que existan casos de uso que desconozco, y es probable que surjan nuevas opciones con el tiempo a medida que la tecnología se desarrolle y su popularidad crezca.
Al mismo tiempo, no todas las implementaciones de malla de servicios existentes admiten todos los casos de uso enumerados. Por lo tanto, mis declaraciones como "la malla de servicios puede..." deben leerse como "individuales, y quizás todas las implementaciones populares de malla de servicios pueden...".
El orden de los ejemplos no hace ninguna diferencia.

Lista corta:

descubrimiento de servicios;
cifrado;
autenticacion y autorizacion;
balanceo de carga;
interrupción de circuitos;
escalado automático;
despliegues canarios;
despliegues azul-verde;
chequeo de salud;
desconexión de carga;
duplicación de tráfico;
aislamiento;
solicitar limitación de velocidad, reintentos y tiempos de espera;
telemetría;
auditoria
visualización.

1. Descubrimiento de servicios

TL;DR: Conéctese a otros servicios en la red usando nombres simples.

Los servicios deberían poder "encontrarse" automáticamente entre sí utilizando nombres adecuados; por ejemplo, service.api.production, pets/staging o cassandra. Los entornos de nube son elásticos y un solo nombre puede ocultar muchas instancias de un servicio. Está claro que en tal situación es físicamente imposible codificar todas las direcciones IP.

Además, cuando un servicio encuentra otro, debería poder enviar solicitudes a ese servicio sin temor a que terminen en la entrada de su instancia rota. En otras palabras, la malla de servicios debe monitorear el estado de todas las instancias de servicios y mantener la lista de hosts lo más actualizada posible.

Cada malla de servicios implementa el mecanismo de descubrimiento de servicios de manera diferente. Por el momento, la forma más común es delegar en procesos externos como Kubernetes DNS. En el pasado en Twitter usábamos un sistema de nombres para este propósito. Fingle. Además, la tecnología de malla de servicios hace posible que surjan mecanismos de nombres personalizados (aunque todavía no he visto ninguna implementación de SM con dicha funcionalidad).

2. Cifrado

TL;DR: elimine el tráfico no cifrado entre servicios y haga que este proceso sea automatizado y escalable.

Es bueno saber que los atacantes no pueden penetrar su red interna. Los cortafuegos hacen un gran trabajo al respecto. ¿Pero qué pasa si un hacker entra? ¿Podrá hacer lo que quiera con el tráfico dentro del servicio? Esperemos que esto no suceda después de todo. Para evitar este escenario, debe implementar una red de confianza cero en la que todo el tráfico entre servicios esté cifrado. La mayoría de las redes de servicios modernas logran esto a través de TLS (TLS mutuo, mTLS). En algunos casos, mTLS funciona en nubes y cúmulos enteros (creo que algún día las comunicaciones interplanetarias se organizarán de manera similar).

Por supuesto, para la malla de servicios mTLS opcional. Cada servicio puede encargarse de su propio TLS, pero esto significa que necesitará encontrar una manera de generar certificados, distribuirlos entre los hosts del servicio e incluir código en la aplicación que cargará estos certificados desde archivos. Sí, no olvide renovar estos certificados periódicamente. Las mallas de servicios automatizan mTLS con sistemas como SPIFFE, que, a su vez, automatizan el proceso de emisión y rotación de certificados.

3. Autenticación y autorización

TL;DR: Establezca quién es el solicitante y defina qué puede hacer antes de que la solicitud llegue al servicio.

Los servicios a menudo quieren saber que realiza la solicitud (autenticación) y, utilizando esta información, decide que una determinada entidad puede hacer (autorización). En este caso, el pronombre “quién” puede ocultar:

Otros servicios. Esto se llama "autenticación" par" Por ejemplo, servicio web quiere acceder al servicio db. Las mallas de servicios suelen resolver estos problemas utilizando mTLS: en este caso, los certificados actúan como el identificador necesario.
Algunos usuarios humanos. Esto se llama "autenticación" solicitud" Por ejemplo, usuario haxor69 quiere comprar una lámpara nueva. Las mallas de servicio proporcionan varios mecanismos, p. Tokens web JSON.
Muchos de nosotros hemos hecho esto en el código de la aplicación. Llega una solicitud, miramos la tabla. users, busque el usuario y compare la contraseña, luego verifique la columna permissions etc. En el caso de una malla de servicio, esto sucede incluso antes de que la solicitud llegue al servicio.

Una vez que hayamos establecido de quién proviene la solicitud, debemos determinar qué puede hacer esta entidad. Algunas mallas de servicios le permiten establecer políticas básicas (sobre quién puede hacer qué) como archivos YAML o en la línea de comandos, mientras que otras ofrecen integración con marcos como Agente de políticas abierto. El objetivo final es que sus servicios acepten cualquier solicitud, asumiendo de forma segura que proviene de una fuente confiable. и esta acción está permitida.

4. Equilibrio de carga

TL;DR: Distribuya la carga entre instancias de servicio de acuerdo con un patrón específico.

Un "Servicio" dentro de una sección de servicios a menudo consta de muchas instancias idénticas. Por ejemplo, hoy el servicio cache consta de 5 ejemplares, y mañana su número puede aumentar a 11. Solicitudes enviadas a cache, debe distribuirse de acuerdo con un propósito específico. Por ejemplo, minimice la latencia o maximice la probabilidad de llegar a una instancia que funcione. El algoritmo más utilizado es el round-robin, pero hay muchos otros, por ejemplo, el método ponderado. (ponderado) consultas (puede seleccionar objetivos preferidos), timbre (anillo) hash (utilizando hash consistente entre hosts ascendentes) o método de menor solicitud (se da preferencia a la instancia con la menor cantidad de solicitudes).

Los balanceadores clásicos tienen otras funciones, como el almacenamiento en caché HTTP y la protección DDoS, pero no son muy relevantes para el tráfico de este a oeste (es decir, para el tráfico que fluye dentro de un centro de datos - aprox. traducción) (alcance típico de la malla de servicios). Por supuesto, no es necesario utilizar una malla de servicios para el equilibrio de carga, pero le permite establecer y controlar políticas de equilibrio para cada servicio desde una capa de control centralizada, eliminando así la necesidad de ejecutar y configurar equilibradores de carga separados en la pila de red. .

5. Rotura de circuito

TL;DR: Detenga el tráfico hacia el servicio problemático y controle el daño en los peores escenarios.

Si por alguna razón el servicio no puede hacer frente al tráfico, la red de servicios ofrece varias opciones para resolver este problema (otras se analizarán en las secciones correspondientes). La interrupción del circuito es la opción más grave para desconectar un servicio del tráfico. Sin embargo, por sí solo no tiene sentido: se necesita un plan de respaldo. Se puede proporcionar contrapresión (contrapresión) a servicios que realizan solicitudes (¡simplemente no olvide configurar su malla de servicios para esto!) o, por ejemplo, colorear la página de estado de rojo y redirigir a los usuarios a otra versión de la página con una "ballena que cae" ("Twitter es abajo").

Las mallas de servicio no sólo le permiten definir cuándo el cierre seguirá y que esto seguirá. En este caso, "cuándo" puede incluir cualquier combinación de parámetros especificados: el número total de solicitudes durante un período determinado, el número de conexiones paralelas, solicitudes pendientes, reintentos activos, etc.

Probablemente no quieras abusar de los interruptores de circuito, pero es bueno saber que tienes un plan de respaldo en caso de emergencia.

6. Escalado automático

TL;DR: aumentar o disminuir el número de instancias de servicio según los criterios especificados.

Las mallas de servicios no son programadores, por lo que no llevar a cabo escalarte a ti mismo. Sin embargo, pueden proporcionar información en qué planificadores basarán sus decisiones. Dado que las mallas de servicios tienen acceso a todo el tráfico entre servicios, tienen amplia información sobre lo que está sucediendo: qué servicios están experimentando problemas, qué servicios están muy ligeramente cargados (la capacidad que se les asigna se desperdicia), etc.

Por ejemplo, Kubernetes escala los servicios según el uso de CPU y memoria de los pods. (ver nuestro informe "Autoescalado y gestión de recursos en Kubernetes" - aprox. trad.), pero si decides escalar en función de cualquier otra métrica (en nuestro caso, relacionada con el tráfico), necesitarás una métrica especial. Gestión como esto muestra cómo hacer esto con Enviado, Istio и Prometheus, pero el proceso en sí es bastante complicado. Nos gustaría que la malla de servicios simplifique esto permitiéndonos simplemente establecer condiciones como "aumentar el número de instancias de servicio". auth, si el número de solicitudes pendientes supera el umbral en un minuto".

7. Implementaciones en Canarias

TL;DR: Pruebe nuevas funciones o versiones de servicios en un subconjunto de usuarios.

Supongamos que está desarrollando un producto SaaS y tiene la intención de lanzar una nueva versión interesante del mismo. Lo probaste en la puesta en escena y funcionó muy bien. Pero todavía existen ciertas preocupaciones sobre su comportamiento en condiciones reales. En otras palabras, es necesario probar la nueva versión en problemas reales sin poner en riesgo la confianza del usuario. Las implementaciones de Canarias son excelentes para esto. Le permiten demostrar una nueva característica a un subconjunto de usuarios. Este subconjunto puede estar formado por los usuarios más leales o aquellos que trabajan con la versión gratuita del producto, o usuarios que han expresado su deseo de ser "conejillos de indias".

Las mallas de servicio implementan esto al permitirle especificar criterios que determinan quién verá qué versión de la aplicación y enrutar el tráfico en consecuencia. Sin embargo, nada cambia para los servicios en sí. La versión 1.0 del servicio cree que todas las solicitudes provienen de usuarios que deberían verlo, y la versión 1.1 cree lo mismo para sus usuarios. Mientras tanto, puedes cambiar el porcentaje de tráfico entre la versión antigua y la nueva, redirigiendo un número creciente de usuarios a la nueva si funciona de manera estable y tus “conejillos de indias” dan el visto bueno.

8. Implementaciones azul-verde

TL;DR: Implemente una característica nueva e interesante, pero prepárese para retirar todo de inmediato.

Significado implementaciones azul-verde es implementar un nuevo servicio “azul”, lanzándolo en paralelo con el antiguo servicio “verde”. Si todo va bien y el nuevo servicio funciona bien, entonces el antiguo se puede desactivar gradualmente. (Por desgracia, algún día este nuevo servicio “azul” repetirá el destino del “verde” y desaparecerá...) Las implementaciones azul-verde se diferencian de las canarias en que la nueva función cubre todo a la vez usuarios (no parte); La cuestión aquí es tener preparado un “puerto seguro” en caso de que algo salga mal.

Las mallas de servicios ofrecen una manera muy conveniente de probar un servicio "azul" y cambiar instantáneamente a uno "verde" que funcione en caso de problemas. Sin mencionar el hecho de que en el camino brindan mucha información (ver "Telemetría" a continuación) sobre el trabajo del "azul", lo que ayuda a comprender si está listo para funcionar completamente.

Nota. traducir: Puede leer más sobre las diferentes estrategias de implementación en Kubernetes (incluido el canario, azul/verde y otros mencionados) en este artículo.

9. Control de salud

TL;DR: realice un seguimiento de qué instancias de servicio son funcionales y responda a aquellas que ya no lo son.

Chequeo de salud (chequeo de salud) ayuda a decidir si las instancias de servicio están listas para aceptar y procesar el tráfico. Por ejemplo, en el caso de los servicios HTTP, una verificación de estado podría parecerse a una solicitud GET al punto final. /health... Respuesta 200 OK significará que la instancia está en buen estado, cualquier otro, que no está lista para recibir tráfico. Las mallas de servicios permiten especificar tanto la forma en que se comprobará la funcionalidad como la frecuencia con la que se realizará esta comprobación. Esta información se puede utilizar para otros fines, por ejemplo, para equilibrar la carga y desconectar circuitos.

Por lo tanto, la verificación del estado no es un caso de uso independiente, sino que generalmente se utiliza para lograr otros objetivos. Además, dependiendo de los resultados de las comprobaciones de estado, es posible que se requieran acciones externas a otros objetivos de la malla de servicios: por ejemplo, actualizar la página de estado, crear un problema en GitHub o completar un ticket JIRA. Y la malla de servicios ofrece un mecanismo conveniente para automatizar todo esto.

10. Deslastre de carga

TL;DR: Redirigir el tráfico en respuesta a un aumento temporal en el uso.

Si un determinado servicio está sobrecargado de tráfico, puede redirigir temporalmente parte de este tráfico a otra ubicación (es decir, "volcar", "transferir" (cobertizo) él allí). Por ejemplo, a un servicio de respaldo o centro de datos, o a un permanente Pulsar tema. Como resultado, el servicio continuará procesando algunas solicitudes en lugar de fallar y dejar de procesar todo por completo. Es preferible deslastrar la carga a romper el circuito, pero aun así no es aconsejable abusar de él. Ayuda a prevenir fallos en cascada que provocan la caída de los servicios posteriores.

11. Paralelización/duplicación del tráfico

TL;DR: envíe una solicitud a varios lugares a la vez.

A veces es necesario enviar una solicitud (o una determinada selección de solicitudes) a varios servicios a la vez. Un ejemplo típico es enviar parte del tráfico de producción a un servicio de ensayo. El servidor web de producción principal envía una solicitud al servicio descendente. products.production y sólo a él. Y la malla de servicio copia inteligentemente esta solicitud y la envía a products.staging, del cual el servidor web ni siquiera es consciente.

Otro caso de uso de malla de servicios relacionado que se puede implementar además de la paralelización del tráfico es pruebas de regresión. Implica enviar las mismas solicitudes a diferentes versiones del servicio y comprobar si todas las versiones se comportan igual. Todavía no me he encontrado con una implementación de malla de servicios con un sistema de prueba de regresión integrado como Difícil, pero la idea en sí parece prometedora.

12. Aislamiento

TL;DR: divida su red de servicios en miniredes.

También conocido como segmentaciónEl aislamiento es el arte de dividir una red de servicios en segmentos lógicamente distintos que no saben nada unos de otros. El aislamiento es un poco como crear redes privadas virtuales. La diferencia fundamental es que aún puede disfrutar de todos los beneficios de una malla de servicios (como el descubrimiento de servicios), pero con mayor seguridad. Por ejemplo, si un atacante puede penetrar un servicio en una subred, no podrá ver qué servicios se están ejecutando en otras subredes ni interceptar su tráfico.

Además, los beneficios también pueden ser organizativos. Es posible que desee dividir sus servicios en subredes según la estructura de su empresa y aliviar a los desarrolladores de la carga cognitiva de tener que tener en cuenta toda la red de servicios.

13. Solicitar limitación de velocidad, reintentos y tiempos de espera

TL;DR: Ya no necesita incluir las tareas esenciales de administración de solicitudes en su código base.

Todas estas cosas podrían considerarse casos de uso separados, pero decidí combinarlas debido a una característica común: se hacen cargo de las tareas de administración del ciclo de vida de las solicitudes que normalmente manejan las bibliotecas de aplicaciones. Si está desarrollando un servidor web en Ruby on Rails (no integrado con una malla de servicios) que realiza solicitudes a servicios backend a través de gRPC, la aplicación tendrá que decidir qué hacer si fallan N solicitudes. También deberá averiguar cuánto tráfico podrán procesar estos servicios y codificar estos parámetros utilizando una biblioteca especial. Además, la aplicación tendrá que decidir cuándo es el momento de darse por vencido y dejar que la solicitud se esfume (según el tiempo de espera). Y para cambiar cualquiera de los parámetros anteriores, será necesario detener, reconfigurar y reiniciar el servidor web.

Descargar estas tareas a una malla de servicios no sólo significa que los desarrolladores de servicios no tendrán que pensar en ellas, sino que también podrán verse de una manera más global. Si se utiliza una cadena compleja de servicios, digamos A -> B -> C -> D -> E, se debe tener en cuenta todo el ciclo de vida de la solicitud. Si la tarea es extender los tiempos de espera en el servicio C, es lógico hacerlo todo a la vez, y no en partes: actualizando el código del servicio y esperando hasta que se acepte la solicitud de extracción y el sistema CI implemente el servicio actualizado.

14. Telemetría

TL;DR: Recopile toda la información necesaria (y no del todo) de los servicios.

La telemetría es un término general que incluye métricas, seguimiento distribuido y registros. Las mallas de servicios ofrecen mecanismos para recopilar y procesar los tres tipos de datos. Aquí es donde las cosas se vuelven un poco borrosas porque la cantidad de opciones posibles es demasiado grande. Para recopilar métricas hay Prometheus y otras herramientas que se pueden utilizar para recopilar registros fluido, Loki, Vector et al. (por ejemplo ClickHouse con nuestro Casa de registro para K8 - aprox. trad.), para el rastreo distribuido hay Jaeger etcétera. Cada malla de servicios puede admitir algunas herramientas y no otras. Será interesante ver si el proyecto puede Telemetría abierta proporcionar cierta convergencia.

En este caso, la ventaja de la tecnología de malla de servicios es que los contenedores sidecar pueden, en principio, recopilar todos los datos anteriores de sus servicios. En otras palabras, tienes a tu disposición un único sistema de recogida de telemetría y la red de servicios puede procesar toda esta información de varias formas. Por ejemplo:

registros finales de un determinado servicio en la CLI;
monitorear el volumen de solicitudes desde el panel de la malla de servicios;
recopilar rastros distribuidos y reenviarlos a un sistema como Jaeger.

Atención, juicio subjetivo: En términos generales, la telemetría es un área en la que no es deseable una fuerte interferencia de la red de servicios. Recopilar información básica y rastrear sobre la marcha algunas métricas de oro como la tasa de éxito de las solicitudes y la latencia está bien, pero esperemos que no veamos surgir pilas de Frankenstein que intenten reemplazar los sistemas especializados, algunos de los cuales ya han demostrado su eficacia y están bien estudiados. .

15. Auditoría

TL;DR: Aquellos que olvidan las lecciones de la historia están condenados a repetirlas.

La auditoría es el arte de observar eventos importantes en un sistema. En el caso de una malla de servicios, esto podría significar rastrear quién realizó solicitudes a puntos finales específicos para servicios específicos, o cuántas veces ocurrió algún evento relacionado con la seguridad en el último mes.

Está claro que la auditoría está muy relacionada con la telemetría. La diferencia es que la telemetría suele estar asociada con aspectos como la productividad y la integridad técnica, mientras que la auditoría puede estar relacionada con cuestiones legales y de otro tipo que van más allá del ámbito estrictamente técnico (por ejemplo, el cumplimiento del RGPD, el Reglamento general de la UE sobre protección de datos).

16. Visualización

TL;DR: Larga vida a React.js: una fuente inagotable de interfaces sofisticadas.

Puede que haya un término mejor, pero no lo sé. Simplemente me refiero a una representación gráfica de una malla de servicios o algunos de sus componentes. Estas visualizaciones pueden incluir indicadores como latencias promedio, información de configuración del sidecar, resultados de verificación de estado y alertas.

Trabajar en un entorno orientado a servicios implica una carga cognitiva mucho mayor en comparación con Su Majestad el Monolito. Por tanto, la presión cognitiva debe reducirse a toda costa. Una interfaz gráfica sencilla para una red de servicios con la posibilidad de hacer clic en un botón y obtener el resultado deseado podría ser decisiva para el crecimiento de la popularidad de esta tecnología.

No fueron incluidos en la lista.

Originalmente tenía la intención de incluir algunos casos de uso más en la lista, pero luego decidí no hacerlo. Aquí están, junto con los motivos de mi decisión:

Centro de datos múltiples. En mi opinión, esto no es tanto un caso de uso como un área estrecha y específica de aplicación de mallas de servicios o algún conjunto de funciones como el descubrimiento de servicios.
Ingreso y egreso. Esta es un área relacionada, pero me he limitado (quizás artificialmente) al caso de uso de "tráfico este-oeste". La entrada y la salida merecen un artículo aparte.

Conclusión

¡Eso es todo por ahora! Una vez más, esta lista es muy arbitraria y probablemente incompleta. Si cree que me perdí algo o me equivoqué en algo, comuníquese conmigo en Twitter (@luckerkins). Por favor respete las reglas de la decencia.

PD del traductor

La ilustración del título del artículo se basa en una imagen del artículo "¿Qué es una Service Mesh (y cuándo usarla)?"(por Gregory MacKinnon). Muestra cómo algunas funciones de las aplicaciones (en verde) se han trasladado a una malla de servicios que proporciona interconexiones entre ellas (en azul).

Lea también en nuestro blog:

Fuente: habr.com