Hola, soy Rob Denham, parte del equipo de IBM Cloud, y hoy quiero hablarles sobre por qué podrían querer utilizar un service mesh, cómo funciona Service Mesh y algunos conceptos básicos para comenzar rápidamente.
Índice
¿Por qué utilizar un Service Mesh?
La razón número uno por la que alguien utiliza un service mesh es para asegurar su carga de trabajo. Desean tener Mutual TLS cuando un servicio está interactuando con otro. Además, desean configurar de manera dinámica cómo se conectan los servicios entre sí. Por ejemplo, en este caso tenemos la versión 1 y la versión 2, por lo que podemos direccionar el 90% del tráfico a la versión 1 y el 10% restante a la versión 2 mientras realizamos pruebas y despliegues incrementales. También podemos agregar políticas de reintentos y circuit breaking para fortalecer nuestro sistema. Otra razón es poder observar cómo se está desempeñando nuestra aplicación de extremo a extremo, no solo si un servicio está funcionando o no, sino también identificar los cuellos de botella en el sistema y analizar cómo fluye el tráfico. Por último, deseamos tener control sobre quién tiene acceso a interactuar con qué servicios. En este ejemplo, la interfaz de usuario (UI) tiene permitido interactuar con el catálogo (catalog), mientras que el catálogo tiene permitido interactuar con el inventario (inventory). Sin embargo, la interfaz de usuario no está autorizada a interactuar directamente con el inventario y los contenedores no autorizados no pueden acceder al servicio de inventario. Podemos incluso especificar detalles más específicos, como permitir que la UI realice una solicitud HTTP GET y el catálogo realice una solicitud POST al inventario.
¿Qué es un Service Mesh?
En el pasado, solíamos tener a nuestros desarrolladores programando directamente todas estas características en el código de la aplicación. Esto ralentizaba el ciclo de desarrollo, hacía que los microservicios fueran más grandes y en general, limitaba la flexibilidad. Pero ahora, existe una mejor manera de hacerlo: el service mesh. Mantienes tu aplicación pequeña y enfocada en el negocio, y en su lugar, programas dinámicamente la inteligencia en la red. Y eso es exactamente lo que hace Service Mesh (sto). Cuando tienes instalado Service Mesh, lo primero que hace es inyectar automáticamente proxies junto a cada uno de tus contenedores. Estos proxies son proxies de Envoy y se ejecutan dentro de un contenedor junto a tu aplicación. El proxy interceptará las solicitudes de la interfaz de usuario y aplicará las políticas correspondientes, para luego enrutar el tráfico hacia el proxy del catálogo, que a su vez enviará la solicitud al catálogo. Sto configurará cada uno de estos proxies con la configuración deseada utilizando CRDs (Custom Resource Definitions) de Kubernetes. Para aplicar una configuración de Service Mesh, solo necesitas escribir el YAML correspondiente y aplicarlo en Kubernetes. El componente llamado galleta (galley) recibirá ese YAML, lo validará y lo enviará a Service Mesh Pilot (pilot), quien convertirá esa configuración en configuración de Envoy y la distribuirá a cada uno de los proxies. Si deseas que los proxies apliquen políticas adicionales y roles, existe un componente llamado policy. Además, los proxies informarán constantemente información de telemetría sobre lo que sucede en tu sistema al componente de telemetría de Service Mesh. Por último, está Citadel, que se encarga de proporcionar identidad y certificados fuertes a cada uno de los servicios en tu sistema, permitiendo así la comunicación con Mutual TLS entre los proxies.
Primeros Pasos y Recursos
Para comenzar con sto y configurar Service Mesh, hay tres recursos principales que debes conocer. En primer lugar, está el gatewa que funciona como un balanceador de carga que se encuentra en el borde de tu malla de servicios y acepta conexiones HTTP y TCP entrantes y salientes. Luego, puedes crear un VirtualService que se puede vincular a un gateway y dirigir el tráfico hacia la interfaz de usuario o cualquier otro servicio deseado. Dentro del VirtualService, puedes aplicar reglas como división de tráfico del 90% y 10%. Una vez que el tráfico es dirigido, se pueden aplicar reglas adicionales, como configuraciones TLS o circuit breaking, utilizando DestinationRules.
Resumen del artículo
| Razones para utilizar Service Mesh | Recursos principales de Service Mesh | |
|---|---|---|
| – Seguridad de carga de trabajo mediante Mutual TLS | – Gateway: un balanceador de carga | |
| – Configuración dinámica de conexiones y tráfico | – VirtualService: para dirigir el tráfico | |
| – Observación y análisis de rendimiento de extremo a extremo | – DestinationRule: para aplicar reglas sobre el tráfico | |
| – Control de acceso a los servicios | – | |
Preguntas Frecuentes (FAQs)
1. ¿Qué es Mutual TLS?
Mutual TLS (Transport Layer Security) es un protocolo de seguridad que garantiza la autenticación y el cifrado de comunicaciones entre servicios en una malla de servicios.
2. ¿Cuál es la diferencia entre Gateway y VirtualService en Service Mesh?
El gateway es un balanceador de carga que acepta conexiones entrantes y salientes en la malla de servicios, mientras que el VirtualService se utiliza para dirigir el tráfico a servicios específicos dentro de la malla.
3. ¿Qué es un DestinationRule en Service Mesh?
Un DestinationRule es una regla que se aplica al tráfico dirigido a un servicio específico en la malla. Puede configurar aspectos como la seguridad TLS o políticas de circuit breaking.
Gracias por leer este artículo y espero que te haya resultado útil. Para obtener más información, no dudes en consultar otros artículos relacionados en nuestro blog. ¡Hasta la próxima!
¿Te ha resultado útil??
0 / 0
Hola, somos Mila Jiménez y César Sánchez. Dos apasionados de la ciberseguridad con muchos años de experiencia. Hemos trabajado en muchas empresas del mundo TI y ahora nos apetece compartir nuestro conocimiento con cualquiera que lo necesite.
¡Si te gusta nuestro contenido puedes invitarnos a un café AQUÍ!