«El peligro es mi segundo nombre», solía decir Austin Powers, un hombre enigmático de alcance internacional. Pero lo que es valorado por superagentes y servicios secretos no es adecuado para los servicios informáticos, donde la monotonía es mucho mejor que los peligros.
Y Istio junto con OpenShift y Kubernetes convierten la implementación de microservicios en una tarea verdaderamente aburrida y predecible, ¡y eso es genial! Hablaremos de esto y mucho más en la cuarta y última publicación de la serie sobre Istio.
Cuando la monotonía es la correcta
En nuestro caso, la monotonía solo aparece en la fase final, cuando solo queda sentarse y observar el proceso. Pero para eso, todo debe estar previamente configurado, y aquí les espera mucho interés.
Al desplegar una nueva versión de su software, debe considerar todas las opciones para minimizar riesgos. Trabajar en paralelo es un método muy poderoso y comprobado para realizar pruebas, y Istio permite utilizar para esto un 'servicio secreto' (una versión de su microservicio oculta de ojos ajenos) sin interferir en la operación del sistema de producción. Para esto hay incluso un término especial: 'Lanzamiento secreto' (Dark Launch), que a su vez se activa con una función con un nombre no menos espía: 'mirroring de tráfico'.
Tenga en cuenta que en la primera oración del párrafo anterior se utiliza el término 'despliegue' (deploy) y no 'lanzamiento' (release). Realmente debe tener la capacidad de desplegar (y, por supuesto, utilizar) su microservicio tan a menudo como desee. Este servicio debe ser capaz de recibir y procesar tráfico, emitir resultados y también escribir en logs y ser monitoreado. Pero esto no significa que dicho servicio deba ser lanzado a producción. Desplegar y lanzar software no siempre es lo mismo. Puede desplegar cuando quiera, pero lanzar solo cuando esté completamente listo.
Organizar la monotonía es interesante
Mire la siguiente regla de enrutamiento de Istio, que dirige todas las solicitudes HTTP al microservicio recommendation v1 (todos los ejemplos se toman de ), al mismo tiempo que las refleja en el microservicio recommendation v2:
Observe la etiqueta mirror: en la parte inferior de la pantalla, es la que establece el mirroring del tráfico. ¡Sí, así de simple!
El resultado de esta regla será que su sistema de producción (v1) seguirá procesando las solicitudes entrantes, pero las solicitudes se duplicarán de manera asíncrona en v2, es decir, se enviarán duplicados completos. De este modo, podrá probar el funcionamiento de v2 en condiciones reales, con datos y tráfico reales, sin interferir en el sistema de producción. ¿Convierte esto la organización de pruebas en una tarea aburrida? Sí, indudablemente. Pero se hace de manera interesante.
Añadamos drama
Tenga en cuenta que en el código de v2 es necesario prever situaciones en las que las solicitudes entrantes pueden provocar cambios en los datos. Las solicitudes se reflejan de manera fácil y transparente, pero la elección del método de procesamiento en la fase de prueba queda en sus manos, y esto es un poco inquietante.
Repitamos un punto importante
Un lanzamiento secreto con espejo de tráfico (Dark Launch/Request Mirroring) se puede ejecutar sin afectar el código.
Comida para el pensamiento
¿Y si en lugar de enviar todas las solicitudes a v1, se enviara una parte de ellas a v2? Por ejemplo, un uno por ciento de todas las solicitudes o solo solicitudes de un grupo específico de usuarios. Y luego, al observar cómo funciona v2, ir trasladando gradualmente todas las solicitudes a la nueva versión. O, por el contrario, volver todo a v1 si algo sale mal con v2. Parece que esto se llama Canary Deployment ("despliegue canario" - un término , y si tuviera un origen ruso, probablemente contendría una referencia a ), y ahora lo examinaremos con más detalle.
Despliegue Canary en Istio: facilitando la incorporación
Con precaución y de manera gradual
La esencia del modelo de despliegue Canary Deployment es extremadamente simple: al lanzar una nueva versión de su software (en nuestro caso, un microservicio), primero le da acceso a un pequeño grupo de usuarios. Si todo va bien, aumenta lentamente este grupo hasta que la nueva versión comienza a fallar, o - si esto no sucede - finalmente traslada a todos los usuarios a ella. Introduciendo de manera controlada y gradual la nueva versión y switchando a los usuarios de forma controlada, se pueden reducir los riesgos y maximizar la retroalimentación.
Por supuesto, Istio simplifica el Canary Deployment, ofreciendo varias buenas opciones para la inteligencia en el enrutamiento de solicitudes. Y sí, todo esto se puede hacer sin tocar tu código fuente.
Filtrando por navegador
Uno de los criterios más simples de enrutamiento es redirigir en función del navegador. Supongamos que deseas que solo las solicitudes del navegador Safari vayan a v2. Así es como se hace:
Aplicaremos esta regla de enrutamiento y luego con el comando curl simularemos en un ciclo solicitudes reales al microservicio. Como se puede ver en la captura de pantalla, todas se dirigen a v1:
¿Y dónde está el tráfico a v2? Dado que en nuestro ejemplo todas las solicitudes provenían de nuestra propia línea de comandos, simplemente no hay tráfico. Pero presta atención a las líneas inferiores en la captura anterior: esta es la reacción a que realizamos una solicitud desde el navegador Safari, que a su vez nos devolvió esto:
Poder ilimitado
Ya hemos mencionado que las expresiones regulares ofrecen capacidades muy poderosas para el enrutamiento de solicitudes. Eche un vistazo al siguiente ejemplo (creemos que entenderás por ti mismo lo que hace):
Ahora, probablemente ya te imaginas de qué son capaces las expresiones regulares.
Actúa inteligentemente
El enrutamiento inteligente, en particular el manejo de los encabezados de paquetes utilizando expresiones regulares, permite controlar el tráfico como desees. Y esto facilita enormemente la implementación de nuevo código: es simple, no requiere modificar el propio código y, si es necesario, todo se puede revertir rápidamente a como estaba.
¿Interesado?
¿Tienes ganas de experimentar con Istio, Kubernetes y OpenShift en tu computadora? El equipo preparó un excelente sobre este tema y puso a disposición todos los archivos relacionados. Así que adelante, no te limites.
Istio Egress: salida a través de la tienda de souvenirs
Al aplicar Istio junto con Red Hat OpenShift y Kubernetes, puedes facilitar mucho la vida con los microservicios. La malla de servicios de Istio está integrada dentro de los pods de Kubernetes, mientras que tu código se ejecuta (principalmente) de manera aislada. Rendimiento, facilidad de modificación, seguimiento, y más: todo esto es fácil de usar gracias a la aplicación de contenedores sidecar. Pero, ¿qué hacer si tu microservicio necesita comunicarse con otros servicios que están fuera de tu sistema OpenShift-Kubernetes?
Aquí es donde Istio Egress entra en juego. En pocas palabras, permite acceder a recursos (léase: «servicios») que no están dentro de sus pods de Kubernetes. Si no se realizan configuraciones adicionales, en el entorno de Istio Egress, el tráfico se enruta solo dentro del clúster de pods y entre tales clústeres según las tablas IP internas. Y esta encapsulación funciona perfectamente hasta que necesita acceder a servicios externos.
Egress permite sortear las tablas IP mencionadas anteriormente, ya sea en función de las reglas de Egress o para un rango de direcciones IP.
Supongamos que tenemos un programa Java que realiza una solicitud GET a httpbin.org/headers.
(httpbin.org es solo un recurso útil para probar solicitudes de servicios salientes.)
Si ingresamos en la línea de comandos curl http://httpbin.org/headers, veremos lo siguiente:
O se puede abrir esta misma dirección en el navegador:
Como podemos ver, el servicio allí simplemente devuelve los encabezados que se le enviaron.
Sustituyéndolo de manera directa
Ahora tomemos el código Java de este servicio externo en relación con nuestro sistema y lo ejecutemos, donde, recordemos, está Istio. (Puede hacerlo usted mismo consultando .) Al crear la imagen correspondiente y ejecutarla en la plataforma OpenShift, llamaremos a este servicio con el comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, después de lo cual veremos lo siguiente en pantalla:
¿Qué ocurrió? Justo estaba funcionando. ¿Qué significa Not Found? Solo configuramos curl.
Ampliamos las tablas IP a toda la internet
Hay que culpar (o agradecer) a Istio por esto. Porque Istio son simplemente contenedores sidecar, que se encargan de la detección y el enrutamiento (así como muchas otras cosas de las que hemos hablado anteriormente). Por esta razón, las tablas IP solo conocen lo que está dentro de su sistema de clústeres. Y httpbin.org está ubicado afuera y, por lo tanto, no está accesible. Aquí es donde Istio Egress entra en acción, sin necesidad de cambiar nada en su código fuente.
La regla de Egress que se muestra a continuación hace que Istio busque (si es necesario, en toda la internet) el servicio requerido, en este caso, httpbin.org. Como se puede ver en este archivo (egress_httpbin.yml), la funcionalidad aquí es bastante sencilla:
Solo queda aplicar esta regla:
istioctl create -f egress_httpbin.yml -n istioegress
Se pueden visualizar las reglas de Egress con el comando istioctl get egressrules:
Y finalmente, ejecutamos el comando de nuevo curl – y vemos que todo funciona:
Pensamos abiertamente
Como pueden ver, Istio permite organizar la interacción también con el mundo exterior. En otras palabras, aún pueden crear servicios de OpenShift y gestionarlos a través de Kubernetes, manteniendo todo en pods que escalan hacia arriba y hacia abajo según la necesidad. Y además, pueden acceder tranquilamente a servicios externos a su entorno. Y sí, reiteramos que todo esto se puede hacer sin modificar su código.
Este fue el último post de la serie sobre Istio. ¡Quédense con nosotros, hay mucho más interesante por venir!
Fuente: habr.com
