“Peligro es mi segundo nombre”, solía decir Austin Powers, un hombre misterioso internacional. Pero lo que los superagentes y los servicios de inteligencia tienen en alta estima no es en absoluto adecuado para los servicios informáticos, donde el aburrimiento es mucho mejor que el peligro.
E Istio, junto con OpenShift y Kubernetes, hace que la implementación de microservicios sea realmente aburrida y predecible, y eso es genial. Hablaremos de esto y mucho más en la cuarta y última publicación de la serie Istio.
Cuando el aburrimiento es correcto
En nuestro caso, el aburrimiento sólo llega en la fase final, cuando solo queda sentarse y observar el proceso. Pero para ello primero debes configurar todo, y aquí te esperan muchas cosas interesantes.
Al implementar una nueva versión de su software, vale la pena considerar todas las opciones para minimizar los riesgos. Ejecutar en paralelo es una forma muy poderosa y comprobada de realizar pruebas, e Istio le permite usar un "servicio secreto" (una versión oculta de su microservicio) para hacerlo sin interferir con el sistema de producción. Incluso existe un término especial para esto: "Dark Launch", que a su vez se activa mediante una función con el nombre igualmente espía de "traffic mirroring".
Tenga en cuenta que la primera frase del párrafo anterior utiliza el término "implementar" en lugar de "liberar". Realmente debería poder implementar (y, por supuesto, utilizar) su microservicio con la frecuencia que desee. Este servicio debe poder recibir y procesar tráfico, producir resultados y también escribir en registros y monitorear. Pero al mismo tiempo, no es necesario que este servicio en sí se ponga en producción. Implementar y lanzar software no siempre es lo mismo. Puedes implementarlo cuando quieras, pero liberarlo solo cuando estés listo.
Organizar el aburrimiento es interesante
Eche un vistazo a la siguiente regla de enrutamiento de Istio, que enruta todas las solicitudes HTTP a la recomendación de microservicio v1 (todos los ejemplos tomados de ), y al mismo tiempo los refleja en el microservicio de recomendación v2:
Presta atención a la etiqueta. mirror: en la parte inferior de la pantalla: esto es lo que configura la duplicación del tráfico. ¡Sí, es así de simple!
El resultado de esta regla será que su sistema de producción (v1) continuará procesando las solicitudes entrantes, pero las solicitudes en sí se reflejarán de forma asincrónica en la v2, es decir, sus duplicados completos irán allí. De esta manera, puede probar v2 en condiciones reales (con datos y tráfico reales) sin interferir de ninguna manera con el funcionamiento del sistema de producción. ¿Esto hace que organizar las pruebas sea aburrido? Sí definitivamente. Pero se hace de una manera interesante.
agreguemos dramatismo
Tenga en cuenta que en el código v2 es necesario prever situaciones en las que las solicitudes entrantes puedan provocar cambios en los datos. Las solicitudes en sí se reflejan de forma fácil y transparente, pero la elección del método de procesamiento en la prueba depende de usted, y esto es un poco preocupante.
Repitamos un punto importante.
El inicio secreto con duplicación de tráfico (Dark Launch/Request Mirroring) se puede realizar sin afectar el código de ninguna manera.
Comida para el pensamiento
¿Qué pasa si el lugar donde se reflejan las solicitudes envía algunas de ellas no a la v1, sino a la v2? Por ejemplo, el uno por ciento de todas las solicitudes o solo las solicitudes de un determinado grupo de usuarios. Y luego, ya observando cómo funciona la v2, transfiera gradualmente todas las solicitudes a la nueva versión. O viceversa, devuelva todo a v1 si algo sale mal con v2. Creo que se llama Canary Deployment. , y si fuera de origen ruso, probablemente contendría una referencia a ), y ahora veremos esto con más detalle.
Despliegue de Canary en Istio: simplificando la puesta en marcha
Con cuidado y gradualmente
La esencia del modelo de implementación de Canary Deployment es extremadamente simple: cuando lanza 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, aumentará lentamente este grupo hasta que la nueva versión comience a funcionar o, si no es así, eventualmente migrará a todos los usuarios a él. Al introducir de manera cuidadosa y gradual una nueva versión y cambiar a los usuarios de manera controlada, puede reducir los riesgos y maximizar la retroalimentación.
Por supuesto, Istio simplifica la implementación de Canary al ofrecer varias buenas opciones para el enrutamiento inteligente de solicitudes. Y sí, todo esto se puede hacer sin tocar el código fuente de ninguna manera.
Filtrando el navegador
Uno de los criterios de enrutamiento más simples es el redireccionamiento basado en navegador. Supongamos que desea que solo las solicitudes de los navegadores Safari vayan a la versión 2. Así es como se hace:
Apliquemos esta regla de enrutamiento y luego usemos el comando curl Simularemos solicitudes reales al microservicio en un bucle. Como puedes ver en la captura de pantalla, todos pasan a la v1:
¿Dónde está el tráfico en la v2? Dado que en nuestro ejemplo todas las solicitudes provienen únicamente de nuestra propia línea de comando, simplemente no existe. Pero preste atención a las líneas inferiores de la pantalla de arriba: esta es una reacción al hecho de que ejecutamos una solicitud desde el navegador Safari, lo que a su vez produjo esto:
Poder ilimitado
Ya hemos escrito que las expresiones regulares proporcionan capacidades muy poderosas para enrutar solicitudes. Eche un vistazo al siguiente ejemplo (creemos que comprenderá lo que hace):
Probablemente ya tengas una idea de lo que pueden hacer las expresiones regulares.
Actúa inteligentemente
El enrutamiento inteligente, en particular el procesamiento de encabezados de paquetes mediante expresiones regulares, le permite dirigir el tráfico de la manera que desee. Y esto simplifica enormemente la implementación de un nuevo código: es simple, no requiere cambiar el código en sí y, si es necesario, todo se puede devolver rápidamente como estaba.
Interesado
¿Estás ansioso por experimentar con Istio, Kubernetes y OpenShift en tu computadora? Equipo preparó un excelente sobre este tema y puso a disposición del público todos los archivos adjuntos. Así que adelante y no te niegues nada.
Salida de Istio: salida por la tienda de souvenirs.
Al utilizar Istio junto con Red Hat OpenShift y Kubernetes, puede hacer su vida con los microservicios mucho más fácil. La malla de servicios de Istio está oculta dentro de los pods de Kubernetes y su código se ejecuta (en su mayor parte) de forma aislada. Rendimiento, facilidad de cambio, seguimiento, etc.: todo esto es fácil de usar gracias al uso de contenedores con sidecar. Pero, ¿qué pasa si su microservicio necesita comunicarse con otros servicios ubicados fuera de su sistema OpenShift-Kubernetes?
Aquí es donde Istio Egress viene al rescate. En pocas palabras, simplemente le permite acceder a recursos (léase: "servicios") que no forman parte de su sistema de pods de Kubernetes. Si no realiza una configuración adicional, en el entorno de salida de Istio el tráfico se enruta solo dentro de un clúster de pods y entre dichos clústeres según las tablas de IP internas. Y dicha pupación funciona muy bien siempre que no necesite acceso a servicios externos.
La salida le permite omitir las tablas de IP anteriores, ya sea en función de las reglas de salida o de un rango de direcciones IP.
Digamos que tenemos un programa Java que realiza una solicitud GET a httpbin.org/headers.
(httpbin.org es simplemente un recurso conveniente para probar solicitudes de servicio salientes).
Si ingresa en la línea de comando curl http://httpbin.org/headers, veremos lo siguiente:
O puedes abrir la misma dirección en el navegador:
Como puede ver, el servicio ubicado allí simplemente devuelve los encabezados que se le pasan.
La sustitución de importaciones de frente
Ahora tomemos el código Java de este servicio, externo a nuestro sistema, y ejecútelo por nuestra cuenta, donde, recordemos, está instalado Istio. (Puedes hacerlo tú mismo poniéndote en contacto .) Después de crear la imagen adecuada y ejecutarla en la plataforma OpenShift, llamaremos a este servicio con el comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, tras lo cual veremos esto en pantalla:
Ups, ¿qué pasó? Todo simplemente funcionó. ¿Qué significa No encontrado? Simplemente lo hicimos por él. curl.
Ampliar las tablas de IP a todo Internet
Se debe culpar (o agradecer) a Istio por esto. Después de todo, Istio son solo contenedores secundarios que son responsables de la detección y el enrutamiento (y muchas otras cosas de las que hablamos anteriormente). Por este motivo, las tablas de IP solo saben qué hay dentro de su sistema de clúster. Y httpbin.org está ubicado afuera y por lo tanto es inaccesible. Y aquí es donde Istio Egress viene al rescate, sin el más mínimo cambio en su código fuente.
La siguiente regla de salida obliga a Istio a buscar (si es necesario, en todo Internet) el servicio requerido, en este caso, httpbin.org. Como puede ver en este archivo (egress_httpbin.yml), la funcionalidad aquí es bastante simple:
Sólo queda aplicar esta regla:
istioctl create -f egress_httpbin.yml -n istioegress
Puede ver las reglas de salida con el comando istioctl get egressrules:
Y finalmente, ejecutamos el comando nuevamente. rizo – y vemos que todo funciona:
pensamos abiertamente
Como puede ver, Istio le permite organizar la interacción con el mundo exterior. En otras palabras, aún puede crear servicios OpenShift y administrarlos a través de Kubernetes, manteniendo todo en pods que se escalan hacia arriba y hacia abajo según sea necesario. Y al mismo tiempo, podrá acceder de forma segura a servicios externos a su entorno. Y sí, repetimos una vez más que todo esto se puede hacer sin tocar tu código de ninguna manera.
Esta fue la última publicación de la serie sobre Istio. Estén atentos: ¡hay muchas cosas interesantes por delante!
Fuente: habr.com