¡Hola de nuevo!.. Con el inicio del curso a la vista hemos preparado otra traducción útil.
Service Mesh es una capa de infraestructura configurable con baja latencia, necesaria para manejar un alto volumen de comunicaciones inter-procesos de red entre las interfaces de programación de aplicaciones (API). Service Mesh asegura una comunicación rápida, confiable y segura entre servicios en contenedores que suelen ser efímeros en la infraestructura de aplicaciones. Service Mesh ofrece capacidades como descubrimiento de servicios, balanceo de carga, cifrado, transparencia, trazabilidad, autenticación y autorización, así como soporte para el patrón de interrupción automática (circuit breaker).
Service Mesh generalmente se implementa proporcionando a cada instancia de servicio una instancia de proxy llamada Sidecar. Sidecar manejan las comunicaciones entre servicios, realizan monitoreo y resuelven problemas de seguridad, es decir, todo lo que puede ser abstraído de servicios individuales. De este modo, los desarrolladores pueden escribir, mantener y operar el código de la aplicación en los servicios, mientras que los administradores del sistema pueden trabajar con el Service Mesh y ejecutar la aplicación.
Istio de Google, IBM y Lyft, es actualmente la arquitectura de Service Mesh más conocida. Kubernetes, que fue desarrollado inicialmente en Google, es ahora el único marco de orquestación de contenedores compatible con Istio. Los proveedores están tratando de crear versiones comerciales soportadas de Istio. Es interesante ver qué novedades podrán aportar al proyecto de código abierto.
Sin embargo, Istio no es la única opción, ya que se están desarrollando otras implementaciones de Service Mesh. El patrón sidecar proxy es la implementación más popular, como se puede observar en los proyectos de Buoyant, HashiCorp, Solo.io y otros. También existen arquitecturas alternativas: el conjunto de herramientas de Netflix es un enfoque donde las funcionalidades de Service Mesh se implementan mediante las bibliotecas Ribbon, Hysterix, Eureka, Archaius, así como plataformas como Azure Service Fabric.
Service Mesh también tiene su propia terminología para componentes de servicios y funciones:
- Marco de orquestación de contenedores. A medida que se añaden más y más contenedores a la infraestructura de la aplicación, surge la necesidad de una herramienta separada para supervisar y gestionar contenedores: el marco de orquestación de contenedores. Kubernetes ha ocupado este nicho de tal manera que incluso sus principales competidores, Docker Swarm y Mesosphere DC/OS, ofrecen como alternativa la integración con Kubernetes.
- Servicios y pods (podes de Kubernetes). Un pod es una única copia en ejecución de un microservicio. A veces, un pod es un solo contenedor. En Kubernetes, un pod consiste en un pequeño grupo de contenedores independientes, conocido como pod. Los clientes rara vez acceden directamente a un pod; más bien, suelen acceder a un servicio, que representa un conjunto de copias escalables e independientes de un pod (réplicas).
- Proxy Sidecar. El Proxy Sidecar trabaja con un solo pod. El objetivo del Proxy Sidecar es enrutar o hacer proxy del tráfico que proviene del contenedor con el que trabaja, así como del tráfico de retorno. El Sidecar interactúa con otros Proxies Sidecar y es gestionado por el marco de orquestación. Muchas implementaciones de Service Mesh utilizan el Proxy Sidecar para interceptar y gestionar todo el tráfico entrante y saliente del pod.
- Descubrimiento de servicios. Cuando un pod necesita interactuar con otro servicio, debe encontrar (descubrir) una copia activa y disponible de otro servicio. Generalmente, el pod realiza la búsqueda a través de DNS. El marco de orquestación de contenedores mantiene una lista de pods que están listos para recibir solicitudes y proporciona una interfaz para las consultas DNS.
- Balanceo de carga. La mayoría de los marcos de orquestación de contenedores proporcionan balanceo de carga a nivel 4 (transporte). Service Mesh implementa balanceo de carga más sofisticado a nivel 7 (aplicación), rico en algoritmos y más eficiente en la gestión del tráfico. Los parámetros de balanceo de carga pueden modificarse a través de API, lo que permite orquestar despliegues azul-verde o canarios.
- Cifrado. Service Mesh puede cifrar y descifrar solicitudes y respuestas, eliminando esta carga de los servicios. Service Mesh también puede mejorar el rendimiento al priorizar o reutilizar conexiones persistentes existentes, lo que reduce la necesidad de costosas computaciones para crear nuevas conexiones. La implementación más común de cifrado de tráfico es mutual TLS (mTLS), donde la infraestructura de claves públicas (PKI) genera y distribuye certificados y claves para su uso en el Sidecar Proxy.
- Autenticación y autorización. Service Mesh puede autorizar y autenticar solicitudes realizadas desde fuera o desde dentro de la aplicación, enviando instancias solo solicitudes validadas.
- Soporte del patrón de desconexión automática. Service Mesh soporta , que aísla instancias no saludables y luego las devuelve gradualmente al grupo de instancias saludables según sea necesario.
La parte de la aplicación Service Mesh que gestiona el tráfico de red entre instancias se llama Data Plane. La creación y despliegue de la configuración que controla el comportamiento Data Plane, se realiza mediante un Control Plane. Control Plane que generalmente incluye o está diseñado para conectarse a API, CLI o GUI para gestionar la aplicación.
El Control Plane en Service Mesh distribuye la configuración entre Sidecar Proxy y Data Plane.
A menudo, la arquitectura Service Mesh se aplica para abordar complejos desafíos operativos utilizando contenedores y microservicios. Los pioneros en el campo de son empresas como Lyft, Netflix y Twitter, que proporcionan servicios que funcionan de manera estable a millones de usuarios en todo el mundo. (). Para tareas de aplicación menos exigentes, probablemente será suficiente con arquitecturas más simples.
La arquitectura Service Mesh difícilmente será alguna vez la solución a todas las preguntas relacionadas con el funcionamiento de las aplicaciones y su entrega. Los arquitectos y desarrolladores cuentan con un enorme arsenal de herramientas, y solo una de ellas es un martillo, que entre muchas tareas solo debe resolver una: clavar clavos. , por ejemplo, incluye varios modelos diferentes que ofrecen un espectro continuo de enfoques para resolver problemas mediante microservicios.
Los elementos que se integran en la arquitectura Service Mesh, como NGINX, contenedores, Kubernetes y microservicios como enfoque arquitectónico, pueden ser igualmente utilizados de manera productiva en implementaciones sin Service Mesh. Por ejemplo, Istio fue diseñado como una arquitectura Service Mesh completa, pero su modularidad indica que los desarrolladores pueden elegir y aplicar solo los componentes tecnológicos que necesiten. Teniendo esto en cuenta, es importante formar una comprensión clara del concepto de Service Mesh, incluso si no estás seguro de poder implementarlo completamente en tu aplicación.
Fuente: habr.com
