👨🏼‍✈️ 📹 👩🏼‍🤝‍👨🏿 Casos de uso de Service Mesh 🦔 🔓 👠

Aprox. transl. : El autor de este artículo (Luc Perkins) es un defensor de los desarrolladores de CNCF, hogar de proyectos de código abierto como Linkerd, SMI (Service Mesh Interface) y Kuma (por cierto, ¿también te has preguntado por qué Istio no está en esta lista? .). En otro intento de brindar una mejor comprensión de la moda de moda llamada malla de servicios a la comunidad DevOps, cita 16 capacidades características que brindan tales soluciones. La malla de servicios es uno de los temas más candentes en la ingeniería de software

actual(¡y con razón!). Encuentro esta tecnología increíblemente prometedora y sueño con presenciar su adopción generalizada (cuando tiene sentido, por supuesto). Sin embargo, todavía está rodeado por un halo de misterio para la mayoría de la gente. Además, incluso aquellos quelo conoce bien, a menudo es difícil formular sus ventajas y qué es exactamente (incluido su humilde servidor). En este artículo, intentaré remediar la situación enumerando varios escenarios para el uso de "redes de servicio" *.

* Aprox. transl .: aquí y más adelante en el artículo, esta es la traducción ("malla de servicio") que se utilizará para el término todavía nuevo malla de servicios.

Pero primero, quiero hacer algunos comentarios:

, . , service mesh Twitter 2015 ( « ») Linkerd, - .
— . , , .
Al mismo tiempo, no todas las implementaciones de malla de servicios existentes admiten todos estos casos de uso. Por lo tanto, mis expresiones como "service mesh can ..." deberían leerse como "separadas, y posiblemente todas las implementaciones populares de service mesh pueden ...".
El orden de los ejemplos no importa.

Lista corta:

descubrimiento de servicios;
cifrado;
autenticacion y autorizacion;
balanceo de carga;
ruptura de circuito;
autoescalado;
despliegues canarios;
despliegues azul-verde;
chequeo de salud;
desconexión de carga;
espejo de tráfico;
aislamiento;
limitación de velocidad, reintentos y tiempos de espera;
telemetría;
auditoría;
visualización.

1. Descubrimiento de servicios

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

Los servicios deben ser capaces de forma automática "descubrir" entre sí a través nombre apropiado - por ejemplo, service.api.production, pets/stagingo cassandra. Los entornos en la nube son resistentes y un solo nombre puede ocultar varias 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 este servicio sin temor a que terminen en la entrada de su instancia inactiva. En otras palabras, la malla de servicios debe monitorear el estado de todas las instancias de servicio y mantener actualizada la lista de hosts.

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

2. Cifrado

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

Es bueno saber que los atacantes no pueden penetrar su red interna. Los cortafuegos hacen un excelente trabajo en esto. Pero, ¿qué pasa si entra un hacker? ¿Podrá hacer lo que quiera con el tráfico dentro del servicio? Esperemos que no suceda. 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 mallas de servicio modernas logran esto mediante TLS mutuo .(TLS mutuo, mTLS). En algunos casos, mTLS funciona en nubes y cúmulos completos (creo que algún día las comunicaciones interplanetarias se organizarán de manera similar).

Por supuesto, para mTLS, la malla de servicios es opcional . Cada servicio puede hacerse cargo de su propio TLS, pero esto significa que será necesario encontrar una forma de generar certificados, distribuirlos entre los hosts del servicio, incluir código en la aplicación que cargará estos certificados desde archivos. Sí, recuerde también renovar estos certificados a intervalos regulares. Las redes de servicio automatizan mTLS utilizando 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: Determine quién inicia la solicitud y qué se le permite hacer antes de que la solicitud llegue al servicio.

Los servicios a menudo quieren saber quién realiza la solicitud (autenticación) y, utilizando esta información, deciden qué puede hacer el sujeto (autorización). En este caso, el pronombre "quién" puede esconderse:

Otros servicios. Esto se llama "autenticación de pares ". Por ejemplo, un servicio webdesea acceder a un servicio db. Las mallas de servicio suelen resolver estos problemas con mTLS: los certificados en este caso actúan como un identificador necesario.
-. « ». , haxor69 . , , JSON Web Tokens.

. , users, , permissions .. service mesh , .

Una vez que hayamos establecido de quién provino la solicitud, debemos determinar qué puede hacer este sujeto. Algunas mallas de servicio le permiten definir políticas de línea base (quién puede hacer qué) como archivos YAML o en la línea de comandos, mientras que otras ofrecen integración con marcos como Open Policy Agent . El objetivo final es garantizar que sus servicios acepten cualquier solicitud, asumiendo con seguridad que provienen de una fuente confiable y que esta acción está permitida.

4. Equilibrio de carga

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

Un "servicio" dentro de una secta de servicios a menudo consta de muchas instancias idénticas. Por ejemplo, hoy el servicio cacheconsta de 5 ejemplares, y mañana su número puede aumentar a 11. Las solicitudes dirigidas a cachedeben distribuirse de acuerdo con un propósito específico. Por ejemplo, minimice la latencia o maximice la probabilidad de llegar a una instancia en buen estado. El algoritmo round-robin más utilizado (Round-robin), pero hay muchos otros, por ejemplo, el método de solicitudes ponderadas (ponderadas) (puede seleccionar el objetivo preferido), anular (anillo)hash (usando hash consistente para hosts ascendentes) o el método de menor solicitud (se prefiere la instancia con la menor cantidad de solicitudes).

Los balanceadores de carga clásicos tienen otras características, 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 del centro de datos, aprox. Transl.) (Uso típico del servicio malla). 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 administración centralizada, lo que elimina la necesidad de ejecutar y configurar equilibradores de carga independientes en la pila de red.

5. circuito de ruptura

TL; DR: Detenga el tráfico hacia un servicio problemático y controle los daños en el peor de los casos.

Si, por alguna razón, el servicio no puede manejar el tráfico, la malla de servicios brinda varias opciones para resolver este problema (otras se discutirán en las secciones correspondientes). La rotura de circuitos es la forma más severa de desconectar un servicio del tráfico. Sin embargo, no tiene sentido por sí solo: necesita un plan de respaldo. Puede proporcionar contrapresión ( contrapresión ) en los servicios que consultan (¡pero no olvide configurar su malla de servicio para eso!), O, por ejemplo, teñir el estado de la página en rojo y redirigir a los usuarios a otra versión de la página con la "ballena cayendo" («Twitter esta abajo ").

Las redes de servicio hacen más que simplemente determinar cuándo y qué sucederá a continuación. En este caso, "cuándo" puede incluir cualquier combinación de los parámetros especificados: el número total de solicitudes para un período determinado, el número de conexiones paralelas, solicitudes pendientes, reintentos activos, etc.

Probablemente no quiera abusar de la ruptura de circuitos, pero es bueno saber que existe un plan de contingencia para emergencias.

6. Zoom automático

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

Las mallas de servicio no son programadores, por lo que no se escalan por sí mismas. Sin embargo, pueden proporcionar información sobre la base de qué planificadores tomarán decisiones. Dado que las mallas de servicios tienen acceso a todo el tráfico entre servicios, tienen una gran cantidad de información sobre lo que está sucediendo: qué servicios están experimentando problemas, cuáles tienen una carga muy débil (la potencia asignada se desperdicia), etc.

Por ejemplo, Kubernetes escala los servicios en función del uso de la CPU y la memoria de los pods (consulte nuestra charla " Ajuste de escala automático y administración de recursos en Kubernetes " - aprox. Transl.), pero si decide escalar en función de cualquier otra métrica (en nuestro caso, relacionada con el tráfico), necesitará una métrica especial. Un tutorial como este le muestra cómo hacer esto con Envoy , Istio y Prometheus , pero el proceso en sí es bastante complejo. Nos gustaría que la malla de servicios lo simplificara simplemente permitiendo condiciones como "aumentar la cantidad de instancias de servicio authsi la cantidad de solicitudes pendientes excede el umbral por un minuto".

7. Implementaciones canarias

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

Supongamos que está desarrollando un producto SaaS y tiene la intención de lanzar una nueva versión genial. Lo probaste en la puesta en escena y funcionó muy bien. Pero aún así, existen ciertas preocupaciones sobre su comportamiento en condiciones reales. En otras palabras, se requiere probar la nueva versión en tareas reales, sin arriesgar la confianza del usuario. Las implementaciones de Canary 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 por aquellos que utilizan la versión gratuita del producto, o por usuarios que han expresado su deseo de ser conejillos de indias.

Las mallas de servicio hacen esto al permitirle especificar criterios que determinan quién ve qué versión de su aplicación y enrutar el tráfico en consecuencia. Al mismo tiempo, 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 asume lo mismo para sus usuarios. Mientras tanto, puede cambiar el porcentaje de tráfico entre la versión antigua y la nueva, redireccionando un número creciente de usuarios a la nueva, si funciona de forma estable y su "experimental" da el visto bueno.

8. Implementaciones azul-verde

TL; DR: Implemente la nueva característica interesante, pero prepárese para volver a instalarla de inmediato.

El objetivo de las implementaciones azul-verde es implementar el nuevo servicio azul ejecutándolo en paralelo con el antiguo verde. Si todo va bien y el nuevo servicio demuestra ser bueno, entonces el anterior se puede apagar 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 implementaciones canarias en que la nueva función cubre a todos los usuarios a la vez (no solo una parte); el punto aquí es tener un "puerto de repuesto" listo en caso de que algo salga mal.

Las mallas de servicio ofrecen una forma muy conveniente de probar un servicio azul y cambiar instantáneamente a un verde que funciona en caso de un problema. Sin mencionar el hecho de que a lo largo del camino dan mucha información (ver el ítem "Telemetría" a continuación) sobre el trabajo del "azul", lo que ayuda a comprender si está listo para una explotación completa.

Aprox. transl. : Lea más sobre las diferentes estrategias de implementación en Kubernetes (incluidas las mencionadas canary, blue / green y otras) en este artículo .

9. Control de salud

TL; DR: Realice un seguimiento de las instancias de servicio que están activas y reaccione a las que ya no lo están.

Una verificación de estado lo ayuda a decidir si las instancias de servicio están listas para recibir y procesar tráfico. Por ejemplo, en el caso de los servicios HTTP, una verificación de estado puede parecer una solicitud GET a un punto final /health. La respuesta 200 OKsignificará que la instancia está en buen estado, cualquier otra, que no está lista para recibir tráfico. Las mallas de servicio permiten especificar tanto la forma en que se comprobará el estado como la frecuencia con la que se realizará esta comprobación. Esta información se puede utilizar para otros fines, como el equilibrio de carga y la interrupción del circuito.

Por lo tanto, la verificación de estado no es un caso de uso independiente, sino que generalmente se usa para lograr otros objetivos. Además, según los resultados de las verificaciones de estado, es posible que se requieran acciones externas (en relación con otros objetivos de las cuadrículas de servicios): por ejemplo, actualizar la página de estado, crear un problema en GitHub o completar un ticket de JIRA. Y la malla de servicios ofrece un mecanismo útil para automatizar todo esto.

10. Desprendimiento de carga

TL; DR: Redirigir el tráfico en respuesta a picos temporales de uso.

Si un determinado servicio está sobrecargado de tráfico, puede redirigir temporalmente parte de este tráfico a otra ubicación (es decir, "volcarlo", " arrojarlo" allí). Por ejemplo, a un servicio de respaldo o centro de datos, o a un tema permanente de Pulsar . Como resultado, el servicio continuará procesando parte de las solicitudes en lugar de fallar y dejar de procesar todo. Es preferible descargar la carga a interrumpir el circuito, pero aún así no es deseable abusar de él. Ayuda a prevenir fallas en cascada que hacen que los servicios posteriores se bloqueen.

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

TL; DR: envíe una solicitud a varias ubicaciones a la vez.

A veces es necesario enviar una solicitud (o alguna muestra de solicitudes) a varios servicios a la vez. Un ejemplo típico es enviar una parte del tráfico de producción a un servicio de ensayo. El servidor web de producción principal envía una solicitud products.productiony solo al servicio descendente . Y la malla de servicios copia de manera inteligente esta solicitud y la envía a products.staging, de lo que el servidor web ni siquiera es consciente.

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

12. Aislamiento

TL; DR: Divida su malla de servicios en mini redes.

También conocido como segmentación , el aislamiento es el arte de dividir una red de servicios en segmentos lógicamente distintos que no se conocen entre sí. El aislamiento es un poco como crear redes privadas virtuales. La diferencia fundamental es que aún puede aprovechar al máximo la malla de servicios (como el descubrimiento de servicios), pero con mayor seguridad. Por ejemplo, si un atacante logra penetrar un servicio en una de las subredes, no podrá ver qué servicios se están ejecutando en otras subredes ni interceptar su tráfico.

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

13. Límite de velocidad, reintentos y tiempos de espera

TL; DR: Ya no es necesario incluir las tareas urgentes de administrar solicitudes en la base de código.

Todas estas cosas podrían verse como casos de uso separados, pero decidí combinarlos por una cosa en común: se hacen cargo de las tareas de administración del ciclo de vida de las solicitudes que generalmente manejan las bibliotecas de aplicaciones. Si está desarrollando un servidor web Ruby on Rails (no integrado con la malla de servicios) que realiza solicitudes para servicios de backend a través de gRPC, la aplicación tendrá que decidir qué hacer si N solicitudes fallan. También tendrá que averiguar cuánto tráfico podrán manejar estos servicios y codificar estos parámetros utilizando una biblioteca especial. Además, la aplicación tendrá que decidir cuándo darse por vencido y dejar que la solicitud salga mal (por tiempo de espera). Y para cambiar cualquiera de los parámetros anteriores, el servidor web deberá detenerse, reconfigurarse y reiniciarse.

Transferir estas tareas a la red de servicios significa no solo que los desarrolladores de servicios no necesitan pensar en ellas, sino que pueden verse de una manera más global. Si se utiliza una cadena de servicios compleja, digamos A -> B -> C -> D -> E, se debe considerar el ciclo de vida completo de la solicitud. Si la tarea es extender los tiempos de espera en el servicio C, es lógico hacerlo todo de una vez, y no en partes: actualizando el código de servicio y esperando que se acepte la solicitud de extracción y que el sistema de 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 registro. Las redes de servicios ofrecen mecanismos para recopilar y procesar los tres tipos de datos. Aquí es donde las cosas se vuelven un poco confusas ya que hay muchas opciones disponibles. Para recopilar métricas, existen Prometheus y otras herramientas, para recopilar registros puede usar fluentd , Loki , Vector , etc. (por ejemplo, ClickHouse con nuestra casa de registro para K8s - aproximadamente transl.) , Para el rastreo distribuido está Jaegeretc. Cada malla de servicio puede admitir algunas herramientas y no otras. Será curioso ver si el proyecto Open Telemetry puede 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, obtiene un único sistema de recopilación de telemetría a su disposición y la malla de servicios puede procesar toda esta información de diferentes maneras. Por ejemplo:

tail 'registros de un determinado servicio en la CLI;
realizar un seguimiento del volumen de solicitudes desde el panel de control de la malla de servicios;
recopilar rastros distribuidos y redirigirlos 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 malla de servicio. Recopilar información básica y rastrear sobre la marcha algunas de las "métricas de oro", como las tasas de éxito y las latencias, está bien, pero esperemos que no veamos emerger pilas de Frankenstein que intenten reemplazar los sistemas especializados, algunos de los cuales ya han demostrado ser excelentes. y bien estudiado.

15. Auditoría

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

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

Está claro que la auditoría está muy relacionada con la telemetría. La diferencia es que la telemetría generalmente se asocia con cosas como el rendimiento y la corrección técnica, mientras que la auditoría puede estar relacionada con cuestiones legales y de otro tipo que van más allá del área estrictamente técnica (por ejemplo, el cumplimiento de los requisitos del GDPR - Reglamento general de la UE para protección de datos).

16. Visualización

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

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

Trabajar en un entorno orientado a servicios conlleva una carga cognitiva mucho mayor que Su Majestad el Monolito. Por tanto, la presión cognitiva debe reducirse a toda costa. Una interfaz gráfica cursi para una malla de servicios con la capacidad de hacer clic en un botón y obtener el resultado deseado puede ser fundamental para el crecimiento de la popularidad de esta tecnología.

No incluido 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 las razones de mi decisión:

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

Conclusión

¡Eso es todo por ahora! Nuevamente, esta lista es muy provisional y probablemente incompleta. Si cree que me falta algo o que me equivoco, comuníquese conmigo en Twitter ( @lucperkins ). Observe las reglas de la decencia.

PD del traductor

Como base para la ilustración del título del artículo, una imagen del artículo “ ¿Qué es una malla de servicios (y cuándo usar una)? "(Por Gregory MacKinnon). Muestra cómo algunas de las funcionalidades de las aplicaciones (en verde) se han trasladado a la malla de servicios, que proporciona interconexiones entre ellas (en azul).

Lea también en nuestro blog:

Casos de uso de Service Mesh