"Peligro es mi segundo nombre", dijo Austin Powers, un hombre misterioso a escala internacional. Pero lo que los superagentes y los servicios especiales tienen en alta estima no es adecuado para los servicios informáticos, donde las cosas aburridas son mucho mejores que los peligros.
E Istio, junto con OpenShift y Kubernetes, hacen que las implementaciones de microservicios sean realmente aburridas y predecibles, 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 ocurre solo en la fase final, cuando solo queda sentarse y observar el proceso. Pero para esto necesitas preconfigurar todo, y aquí encontrarás muchas cosas interesantes.Al implementar una nueva versión de su software, debe considerar todas las opciones para minimizar los riesgos. Trabajar en modo paralelo es un método de prueba muy potente y comprobado, e Istio le permite utilizar el "servicio secreto" (una versión de su microservicio oculto para miradas curiosas) sin interferir con el sistema de producción. Incluso hay un término especial para esto: "Lanzamiento secreto" (Dark Launch), que a su vez se activa mediante una función con el nombre no menos espía de "duplicación del tráfico".Tenga en cuenta que la primera oración del párrafo anterior utiliza el término "desplegar" en lugar de "liberar". Realmente debería poder implementar, y, por supuesto, usar, su microservicio tantas veces como lo desee. Este servicio debería poder recibir y procesar el tráfico, producir resultados, así como escribir en registros y monitorear. Pero al mismo tiempo, este servicio en sí no tiene que lanzarse a producción. La implementación y el lanzamiento del software no siempre son lo mismo. Puede realizar la implementación cuando lo desee, pero solo cuando esté completamente listo.Organizar el aburrimiento es interesante
Eche un vistazo a la siguiente regla de enrutamiento de Istio, que enruta todas las solicitudes HTTP al microservicio de recomendación v1 (todos los ejemplos se toman del repositorio de GitHub Tutorial de Istio ), mientras los refleja al microservicio de recomendación v2:Presta atención a la etiqueta mirror:en la parte inferior de la pantalla: es la que establece el reflejo del tráfico. Sí, eso es muy simple!El resultado de esta regla será que su sistema de producción (v1) continuará procesando las solicitudes entrantes, pero las solicitudes mismas se reflejarán de forma asincrónica en la v2, es decir, sus duplicados completos irán allí. Por lo tanto, puede probar el trabajo de v2 en condiciones reales, en datos y tráfico reales, sin interferir con el trabajo del sistema de producción. ¿Esto hace que la organización de prueba sea aburrida? Sí, por supuesto. Pero esto se está haciendo de manera interesante.Añadir drama
Tenga en cuenta que en el código v2, es necesario prever situaciones en las que las solicitudes entrantes pueden provocar cambios en los datos. Las consultas en sí mismas se reflejan de manera fácil y transparente, pero la elección del método de procesamiento en la prueba es suya, y esto ya es un poco emocionante.Repite el punto importante
Se puede realizar un lanzamiento secreto con duplicación de tráfico (Dark Launch / Request Mirroring) sin afectar el código.Comida para el pensamiento
Pero, ¿qué pasa si el lugar para reflejar las solicitudes es enviar algunas de ellas no a la v1, sino a la v2? Por ejemplo, el uno por ciento de todas las solicitudes o solo solicitudes de un grupo de usuarios específico. Y luego, ya mirando cómo funciona v2, transfiere gradualmente todas las solicitudes a la nueva versión. O viceversa, devuelva todo a v1 si algo sale mal con v2. Parece llamarse Despliegue Canario ("despliegue canario" - el término se remonta a la minería , y si fuera de origen ruso, probablemente contendría una referencia a los gatos ), y ahora lo examinaremos con más detalle.Despliegue de Canarias en Istio: simplificando la puesta en marcha
Precaución y poco a poco
La esencia del modelo de implementación de Canary Deployment es extremadamente simple: cuando inicia una nueva versión de su software (en nuestro caso, 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 comience a desecharse o, si esto no sucede, eventualmente transfiera a todos los usuarios. Con la introducción cuidadosa y gradual de una nueva versión en funcionamiento y el cambio de 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 consultas. Y sí, todo esto se puede hacer sin tocar su código fuente.Filtra el navegador
Uno de los criterios de enrutamiento más simples es la redirección basada en el navegador. Suponga que desea que v2 solo envíe solicitudes desde los navegadores Safari. Aquí se explica cómo hacerlo:Aplicamos esta regla de enrutamiento y luego con el comando curlsimularemos solicitudes reales al microservicio en un bucle. Como puede ver en la captura de pantalla, todos van a v1:¿Y dónde está el tráfico en v2? Como en nuestro ejemplo todas las solicitudes provienen solo de nuestra propia línea de comando, simplemente no existe. Pero preste atención a las líneas de fondo en la captura de pantalla anterior: esta es una reacción al hecho de que ejecutamos la solicitud desde el navegador Safari, que a su vez emitió esto:Poder ilimitado
Ya escribimos que las expresiones regulares proporcionan capacidades muy potentes para enrutar consultas. Eche un vistazo al siguiente ejemplo (creemos que usted mismo comprenderá lo que hace):Ahora probablemente ya sepa de qué son capaces las expresiones regulares.Actúa de manera inteligente
El enrutamiento inteligente, en particular el procesamiento de encabezados de paquetes utilizando expresiones regulares, le permite dirigir el tráfico de la manera que desee. Y esto simplifica enormemente la puesta en servicio del nuevo código: es simple, no requiere cambiar el código en sí mismo y, si es necesario, todo puede devolverse rápidamente tal como estaba.¿Interesado en?
¿Estás ansioso por experimentar con Istio, Kubernetes y OpenShift en tu computadora? El equipo de desarrolladores de Red Hat ha preparado un excelente tutorial sobre este tema y ha compartido todos los archivos relacionados. Así que adelante, y no te niegues nada. Istio Egress: sal por la tienda de regalos
Usar Istio con Red Hat OpenShift y Kubernetes puede simplificar enormemente su vida con microservicios. La cuadrícula de la utilidad Istio está oculta dentro de los pods de Kubernetes y su código se ejecuta (principalmente) de forma aislada. Rendimiento, facilidad de cambio, rastreo y más: todo esto es fácil de usar con precisión mediante el uso de contenedores sidecar. Pero, ¿qué sucede si su microservicio necesita comunicarse con otros servicios que se encuentran 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 están incluidos en su sistema de pod Kubernetes. Si no realiza una configuración adicional, en el entorno Istio Egress, el tráfico se enruta solo dentro del grupo de pods y entre dichos grupos en función de las tablas IP internas. Y este tipo de cachorros funciona muy bien hasta que necesite acceso a servicios desde el exterior.Egress le permite omitir las tablas IP antes mencionadas, ya sea en base a las reglas de Egress o para un rango de direcciones IP.Supongamos que tenemos un programa Java que ejecuta una solicitud GET a httpbin.org/headers.(httpbin.org es solo un recurso conveniente para probar las solicitudes de servicio salientes).Si escribe en el símbolo del sistemacurl http://httpbin.org/headersveremos lo siguiente:O puede abrir la misma dirección en un navegador:Como puede ver, el servicio ubicado allí simplemente devuelve los encabezados que se le pasan.Sustitución de importaciones en la frente
Ahora, tomemos el código Java de este servicio externo a nuestro sistema y ejecútelo en casa, donde, recuerde, Istio se encuentra. (Puede hacerlo usted mismo consultando nuestro tutorial de Istio ). Después de construir la imagen correspondiente y ejecutarla en la plataforma OpenShift, llamaremos a este servicio con un comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, después de lo cual veremos en la pantalla esto:Vaya, ¿qué pasó? Aún así, simplemente funcionó. ¿Qué significa no encontrado? Lo acabamos de hacer por él curl.Extienda las tablas IP a todo Internet
Culpa (o agradece) a Istio por esto. Después de todo, Istio son solo contenedores de sidecar que son responsables de la detección y el enrutamiento (bueno, para muchas otras cosas de las que hablamos anteriormente). Por esta razón, las tablas IP solo saben lo que hay dentro de su sistema de clúster. Y httpbin.org se encuentra afuera y, por lo tanto, no está disponible. Y aquí Istio Egress viene al rescate, sin el más mínimo cambio en su código fuente.La siguiente regla de Egress hace que Istio busque (si es necesario, luego en toda Internet) el servicio deseado, en este caso, httpbin.org. Como puede ver en este archivo (egress_httpbin.yml), la funcionalidad aquí es bastante simple:Solo 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, ejecute el comando curl nuevamente y vea 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 guiarlos 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, puede acceder de manera segura a servicios externos a su entorno. Y sí, repetimos una vez más que todo esto se puede hacer sin tocar su código.Esta fue la última publicación de la serie Istio. Quédate con nosotros, ¡hay muchas cosas interesantes por delante!