Comenzamos una serie de publicaciones en la que demostraremos algunas de las muchas capacidades de la malla de servicios Istio Service Mesh en combinación con Red Hat OpenShift y Kubernetes.
Parte uno, la de hoy:
- Explicaremos el concepto de contenedores sidecar en Kubernetes y formularemos el tema central de esta serie de publicaciones: «no necesita cambiar nada en su código».
- Presentamos la característica fundamental de Istio: las reglas de enrutamiento. Todas las demás capacidades de Istio se basan en estas reglas, ya que permiten dirigir el tráfico hacia los microservicios utilizando archivos YAML externos al código de los servicios. También abordamos el despliegue Canary Deployment. Bonus de Año Nuevo: 10 sesiones interactivas sobre Istio.
Parte dos, que saldrá pronto, le contará:
- Cómo Istio implementa la Eyección de Pool en combinación con el Circuit Breaker y demostrará cómo Istio permite eliminar de la estrategia de balanceo un pod que no está funcionando o que funciona mal.
- Además, abordaremos el tema del Circuit Breaker del primer post en relación a cómo aquí se puede utilizar Istio. Mostraremos cómo, sin ningún cambio en el código de los servicios, dirigir el tráfico y manejar errores de red utilizando archivos de configuración YAML y comandos de terminal.
Parte tres:
- Narración sobre el trazado y monitoreo que ya están integrados o se pueden añadir fácilmente a Istio. Mostraremos cómo utilizar herramientas como Prometheus, Jaeger y Grafana en combinación con la escalabilidad de OpenShift para gestionar sin esfuerzo la arquitectura de microservicios.
- Pasamos del monitoreo y manejo de errores a introducirlos deliberadamente en el sistema. En otras palabras, aprendemos a realizar fault injection sin modificar el código fuente, lo cual es muy importante desde el punto de vista de las pruebas, ya que si modificamos el código para esto, existe el riesgo de introducir errores adicionales.
Finalmente, en el post final sobre Istio Service Mesh:
- Pasaremos al Lado Oscuro. Más precisamente, aprenderemos a utilizar el esquema Dark Launch, cuando el código se implementa y prueba directamente en datos de producción, pero no afecta el funcionamiento del sistema. Aquí es muy útil la habilidad de Istio para dividir el tráfico. La capacidad de realizar pruebas en datos de producción en vivo, sin afectar el funcionamiento del sistema en producción, es la forma más convincente de verificación.
- Basándonos en el Dark Launch, mostraremos cómo utilizar el modelo de Canary Deployment para reducir riesgos y simplificar la implementación de nuevo código. El Canary Deployment no es en sí mismo una novedad, pero Istio permite implementar este esquema simplemente utilizando archivos YAML sencillos.
- En conclusión, mostraremos cómo, a través de Istio Egress, dar acceso a servicios a aquellos que se encuentran fuera de sus clústeres, para aprovechar las capacidades de Istio al trabajar con Internet.
Así que, ¡empecemos…!
La herramienta de monitoreo y gestión de Istio: todo lo necesario para coordinar microservicios en una malla de servicios. .
¿Qué es la malla de servicios Istio?
La malla de servicios ofrece a un grupo de servicios funciones como monitoreo de tráfico, control de accesos, descubrimiento, seguridad, tolerancia a fallos y otras características útiles. Istio permite lograr todo esto sin necesidad de realizar cambios en el código de los propios servicios. ¿Cuál es el secreto de la magia? Istio adosa a cada servicio su propio proxy en forma de contenedor sidecar, después de lo cual todo el tráfico hacia este servicio pasa por el proxy, que, basándose en las políticas establecidas, decide cómo, cuándo y si este tráfico debe llegar al servicio. Istio también permite implementar técnicas avanzadas de DevOps, como canary deployments, circuit breakers, fault injection y muchas más.
Cómo funciona Istio con contenedores y Kubernetes.
La malla de servicios Istio es una implementación sidecar de todo lo necesario para crear y gestionar microservicios: monitoreo, trazado, circuit breakers, enrutamiento, balanceo de carga, fault injection, reintentos, timeouts, mirroring, control de acceso, limitación de velocidad y mucho más. Y aunque hoy en día hay muchas bibliotecas para implementar estas funciones directamente en el código, con Istio puedes obtener lo mismo sin modificar tu código.
Según el modelo sidecar, Istio se ejecuta en un contenedor de Linux, que se encuentra en el mismo -pod que el servicio controlado e inyecta (inject) y extrae (extract) funcionalidad e información de acuerdo con la configuración establecida. Hay que destacar que esta es tu propia configuración, y vive fuera de tu código. Por lo tanto, el código se vuelve mucho más simple y corto.
Lo que es aún más importante, la parte operativa de los microservicios no está relacionada con el código mismo, lo que significa que su manejo puede ser tranquilamente delegado a especialistas de TI. De hecho, ¿por qué debería el desarrollador ser responsable de los circuit breakers y la inyección de fallos? Respondedor – sí, pero ¿gestionarlos y crearlos? Si se elimina todo esto del código, los programadores podrán concentrarse completamente en la funcionalidad aplicada. Además, el código será más corto y sencillo.
Malla de servicios
Istio, que implementa funciones de gestión de microservicios fuera de su código, es el concepto de malla de servicios Service Mesh. En otras palabras, es un grupo coordinado de uno o más binarios que forman una red de funciones de red.
Cómo Istio trabaja con microservicios
Así es como funcionan los contenedores sidecar junto con y desde una perspectiva general: inicias una instancia de Minishift, creas un proyecto para Istio (llamémoslo «istio-system»), instalas y pones en marcha todos los componentes relacionados con Istio. Luego, a medida que creas proyectos y pods, agregas información de configuración a tus deployments, y tus pods comienzan a usar Istio. Simplificando, el diagrama se ve así:
Ahora puedes modificar la configuración de Istio para, por ejemplo, organizar la inyección de fallos, soporte u otras capacidades de Istio, y todo esto sin tocar el código de las aplicaciones mismas. Supongamos que deseas redirigir todo el tráfico web de los usuarios de tu mayor cliente (Foo Corporation) a una nueva versión del sitio web. Para ello, basta con crear una regla de enrutamiento de Istio que busque @foocorporation.com en el identificador de usuario y realice la redirección correspondiente. Para todos los demás usuarios, nada cambiará. Y tú, mientras tanto, podrás probar con tranquilidad la nueva versión del sitio web. Y ten en cuenta que no es necesario involucrar a los desarrolladores para esto.
¿Y tendrás que pagar mucho por eso?
En absoluto. Istio funciona bastante rápido, está escrito en y crea una sobrecarga muy pequeña. Además, la posible pérdida en el rendimiento en línea se compensa con el aumento de la productividad de los desarrolladores. Al menos, en teoría: no olvides que el tiempo de los desarrolladores es costoso. En cuanto a los costos de software, Istio es una herramienta de código abierto, por lo que se puede obtener y utilizar gratuitamente.
Apréndelo tú mismo
El equipo de Red Hat Developer Experience ha desarrollado un curso práctico profundo sobre Istio (en inglés). Funciona en Linux, MacOS y Windows, y el código está disponible en versiones de Java y Node.js.
10 lecciones interactivas sobre Istio
Bloque 1 – Para principiantes
Introducción a Istio
30 minutos
Conocemos el Service Mesh, aprendemos a instalar Istio en un clúster de Kubernetes OpenShift.
Despliegue de microservicios en Istio
30 minutos
Utilizamos Istio para desplegar tres microservicios con Spring Boot y Vert.x.
Bloque 2 – Nivel intermedio
Monitoreo y trazabilidad en Istio
60 minutos
Estudiamos las herramientas de monitoreo integradas de Istio, métricas configurables y OpenTracing a través de Prometheus y Grafana.
Enrutamiento simple en Istio
60 minutos
Aprendemos a gestionar el enrutamiento en Istio con reglas simples.
Reglas avanzadas de enrutamiento
60 minutos
Conocemos el enrutamiento inteligente en Istio, la gestión de acceso, la equilibración de carga y la limitación de velocidad.
Bloque 3 – Usuario avanzado
Inyección de fallos en Istio
60 minutos
Estudiamos escenarios de manejo de fallos en aplicaciones distribuidas, creando errores HTTP y latencias de red, y aprendemos a aplicar ingeniería del caos para restaurar el entorno.
Circuit Breaker en Istio
30 minutos
Instalamos Siege para pruebas de estrés en sitios web y aprendemos a asegurar la resiliencia del backend mediante reintentos, el circuito de interrupción y la expulsión de grupos.
Egress y Istio
10 minutos
Usamos rutas Egress para crear reglas de interacción entre servicios internos y APIs y servicios externos.
Istio y Kiali
15 minutos
Aprendemos a usar Kiali para obtener una visión general de la malla de servicios y estudiar los flujos de solicitudes y datos.
Mutual TLS en Istio
15 minutos
Creamos Istio Gateway y VirtualService, luego estudiamos en profundidad mutual TLS (mTLS) y sus configuraciones.
Bloque 3.1 – Profundización: Istio Service Mesh para microservicios
De qué trata el libro:
- Qué es una malla de servicios (service mesh).
- El sistema Istio y su papel en la arquitectura de microservicios.
- Uso de Istio para resolver las siguientes tareas:
- Resiliencia;
- Enrutamiento;
- Pruebas de caos;
- Seguridad;
- Recolección de telemetría mediante trazado, métricas y Grafana.
Serie de artículos sobre redes de servicios e Istio
Inténtalo tú mismo
Esta serie de publicaciones no tiene como objetivo proporcionar una profunda inmersión en el mundo de Istio. Simplemente queremos familiarizarlo con el concepto mismo y, tal vez, inspirarlo a probar Istio por sí mismo. Esto se puede hacer completamente gratis, y Red Hat proporciona todas las herramientas necesarias para comenzar a dominar OpenShift, Kubernetes, contenedores Linux e Istio, a saber: , y otros recursos en nuestro . ¡No lo posponga, comience hoy mismo!
Reglas de enrutamiento de Istio: dirigimos las solicitudes de servicio donde se necesita
y se ocupan perfectamente de que las solicitudes a se enruten a los pod correctos. Este es uno de los objetivos de Kubernetes: enrutamiento y balanceo de carga. ¿Y si necesita un enrutamiento más fino y sofisticado? Por ejemplo, para utilizar simultáneamente dos versiones de un microservicio. ¿Cómo ayudarán las reglas de enrutamiento de Istio en esto?
Las reglas de enrutamiento son las reglas que, en esencia, definen la elección de la ruta. A cualquier nivel de complejidad del sistema, el principio general de operación de estas reglas sigue siendo sencillo: las solicitudes se enrutadas en función de parámetros determinados y valores de encabezados HTTP.
Veamos algunos ejemplos:
Kubernetes por defecto: trivial "50 a 50"
En nuestro ejemplo, mostraremos cómo usar simultáneamente en OpenShift dos versiones de un microservicio, llamémoslas v1 y v2. Cada versión se ejecuta en su propio pod de Kubernetes, y por defecto aquí se aplica un enrutamiento cíclico equilibrado (evenly balanced round robin routing). Cada pod recibe su parte de solicitudes según la cantidad de instancias de su microservicio, en otras palabras, réplicas. Istio permite cambiar este equilibrio manualmente.
Supongamos que hemos desplegado en OpenShift dos versiones de nuestro servicio de recomendaciones, recommendation-v1 y recommendation-v2.
En la figura 1 se puede ver que, cuando cada servicio se presenta en una sola instancia, las solicitudes se alternan uniformemente entre ellas: 1-2-1-2-… Así es como funciona el enrutamiento de Kubernetes por defecto:
Distribución ponderada entre versiones
En la figura 2 se muestra lo que sucederá si aumentamos el número de réplicas del servicio v2 de una a dos (esto se realiza con el comando oc scale —replicas=2 deployment/recommendation-v2). Como podemos ver, las solicitudes entre v1 y v2 ahora se dividen en una relación de "uno a tres": 1-2-2-1-2-2-…:
Ignorar versión con Istio
Istio permite cambiar fácilmente la distribución de las solicitudes de la manera que necesitamos. Por ejemplo, enviar todo el tráfico solo a recommendation-v1 usando el siguiente archivo yaml de Istio:
Aquí hay que prestar atención a lo siguiente: los pods se seleccionan según las etiquetas. En nuestro ejemplo se utiliza la etiqueta v1. El parámetro "weight: 100" significa que el 100% del tráfico se enrutarán a todos los pods del servicio que tengan la etiqueta v1.
Distribución directiva entre versiones (Canary Deployment)
A continuación, utilizando el parámetro weight, se puede dirigir el tráfico a ambos pods, ignorando el número de instancias de microservicios que se ejecutan en cada uno de ellos. Por ejemplo, aquí estamos dirigiendo de forma directiva el 90% del tráfico a v1 y el 10% a v2:
Enrutamiento separado para usuarios móviles
Finalmente, mostraremos cómo dirigir forzosamente el tráfico de los usuarios móviles al servicio v2, mientras que a todos los demás se les envía a v1. Para ello, analizamos el valor del user-agent en el encabezado de la solicitud mediante expresiones regulares:
Ahora es tu turno
El ejemplo con expresiones regulares para el análisis de encabezados debería motivarte a buscar tus propias variantes de aplicación de las reglas de enrutamiento de Istio. Sobre todo porque aquí se abren muchas posibilidades, ya que los valores de los encabezados se pueden formar en el código fuente de las aplicaciones.
Y recuerda, Ops, no Dev
Todo lo que hemos mostrado en los ejemplos anteriores se hace sin el más mínimo cambio en el código fuente, salvo en aquellos casos en los que es necesario formar encabezados de solicitudes especiales. Istio será útil tanto para los desarrolladores, que podrán aplicarlo en la fase de prueba, como para los especialistas en operaciones de sistemas IT, que les ayudará mucho en producción.
Así que repitamos el leitmotiv de esta serie de publicaciones: no necesitas cambiar nada en tu códigoNo es necesario crear nuevas imágenes o lanzar nuevos contenedores. Todo esto se implementa fuera del código.
Activa tu imaginación
Solo imagina las perspectivas que ofrece el análisis de encabezados utilizando expresiones regulares. ¿Quieres redirigir a tu mayor cliente a una versión especial de tu ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Inténtalo tú mismo
Leer sobre Istio, Kubernetes y OpenShift es una cosa, pero ¿por qué no probarlo todo con tus propias manos? El equipo ha preparado una guía detallada (en inglés) que te ayudará a dominar estas tecnologías lo más rápido posible. La guía también es 100% de código abierto, por lo que está disponible públicamente. El archivo funciona en macOS, Linux y Windows, y el código fuente está disponible en versiones de Java y node.js (próximamente habrá versiones en otros lenguajes). Solo tienes que abrir el repositorio de git correspondiente en tu navegador. .
En la próxima publicación: resolvemos problemas con estilo
Hoy has visto de lo que son capaces las reglas de enrutamiento de Istio. Ahora imagina todo lo mismo, pero aplicándolo al manejo de errores. De esto hablaremos en la próxima publicación.
Fuente: habr.com
