Una breve historia sobre las ventajas y desventajas de los microservicios, el concepto de Service Mesh y las herramientas de Google que le permiten ejecutar aplicaciones de microservicios sin obstruir su cabeza con configuraciones interminables de políticas, accesos y certificados y encontrar rápidamente errores ocultos no en el código, sino en la lógica del microservicio.
El artículo se basa en el
informe de Craig Box en nuestra conferencia DevOops 2017 del año pasado. El video y la traducción del informe están recortados.
Craig Box (Craig Box,
Twitter ): DevRel de Google a cargo de microservicios y herramientas Kubernetes e Istio. Su historia actual trata sobre la gestión de microservicios en estas plataformas.
Comencemos con un concepto relativamente nuevo llamado Service Mesh. Este término se utiliza para describir la red de microservicios interactivos que componen la aplicación.
En un nivel alto, vemos la red como una tubería que simplemente mueve bits. No queremos preocuparnos por ellos o, por ejemplo, por las direcciones MAC en las aplicaciones, pero nos esforzamos por pensar en los servicios y conexiones que necesitan. Si observa desde el punto de vista de
OSI , entonces tenemos una red de tercer nivel (con funciones para determinar la ruta y el direccionamiento lógico), pero queremos pensar en términos de la séptima (con la función de acceso a servicios de red).
¿Cómo debería ser una red real de séptimo nivel? Tal vez queremos ver algo así como un rastro de tráfico en torno a servicios problemáticos. Para que pueda conectarse al servicio, y al mismo tiempo, el nivel del modelo se elevó desde el tercer nivel. Queremos tener una idea de lo que está sucediendo en el clúster, encontrar dependencias no deseadas, descubrir las causas raíz de las fallas. También debemos evitar sobrecargas innecesarias, por ejemplo, conectarse con una latencia alta o conectarse a servidores con una memoria caché fría o no totalmente calentada.
Debemos asegurarnos de que el tráfico entre servicios esté protegido contra ataques triviales. Se requiere autenticación mutua de TLS, pero sin incorporar los módulos apropiados en cada aplicación que escribimos. Es importante poder controlar lo que rodea nuestras aplicaciones no solo a nivel de conexión, sino también a un nivel superior.
Service Mesh es una capa que nos permite resolver los problemas anteriores en un entorno de microservicio.
Monolito y microservicios: pros y contras
Pero primero nos preguntamos, ¿por qué deberíamos resolver estos problemas? ¿Cómo hicimos el desarrollo de software antes? Teníamos una aplicación que se parecía a esto, como un monolito.
Es genial: todo el código está a la vista. ¿Por qué no seguir usando este enfoque?
Sí, porque el monolito tiene sus propios problemas. La principal dificultad es que si queremos reconstruir esta aplicación, debemos volver a implementar cada módulo, incluso si nada ha cambiado. Nos vemos obligados a crear una aplicación en el mismo idioma o en idiomas compatibles, incluso si diferentes equipos trabajan en ello. De hecho, las partes individuales no se pueden probar independientemente una de la otra. Es hora de cambiarlo, es hora de microservicios.
Entonces, dividimos el monolito en partes. Puede notar que en este ejemplo eliminamos algunas de las dependencias innecesarias y dejamos de usar los métodos internos llamados desde otros módulos. Creamos servicios a partir de los modelos que se usaron anteriormente, creando abstracciones en los casos en que necesitamos mantener el estado. Por ejemplo, cada servicio debe tener un estado independiente para que cuando acceda a él, no tenga que preocuparse por lo que sucede en el resto de nuestro entorno.
Cual es el resultado?
Dejamos el mundo de las aplicaciones gigantes para obtener lo que realmente se ve genial. Aceleramos el desarrollo, dejamos de usar métodos internos, creamos servicios y ahora podemos escalarlos de forma independiente, hacer que el servicio sea más grande sin tener que consolidar todo lo demás. Pero, ¿cuál es el precio del cambio que hemos perdido?
Tuvimos llamadas confiables dentro de las aplicaciones porque simplemente llamaste a una función o módulo. Reemplazamos la llamada de confianza dentro del módulo con una llamada de procedimiento remoto poco confiable. Pero el servicio del otro lado no siempre está disponible.
Estábamos a salvo, usando el mismo proceso dentro de la misma máquina. Ahora nos estamos conectando a servicios que pueden estar en diferentes máquinas y en una red no confiable.
En el nuevo enfoque en la red, es posible la presencia de otros usuarios que intentan conectarse a los servicios. Los retrasos aumentaron y, al mismo tiempo, disminuyeron sus capacidades de medición. Ahora tenemos conexiones paso a paso en todos los servicios que crean una llamada de módulo, y ya no podemos simplemente mirar la aplicación en el depurador y descubrir exactamente qué causó la falla. Y este problema necesita ser resuelto de alguna manera. Obviamente, necesitamos un nuevo conjunto de herramientas.
Que se puede hacer
Hay varias opciones Podemos tomar nuestra aplicación y decir que si
RPC no funciona la primera vez, debe intentarlo nuevamente, y luego una y otra vez. Espere un poco e intente nuevamente o agregue Jitter. También podemos agregar rastreos de entrada - salida para decir que la llamada comenzó y terminó, lo que para mí es equivalente a la depuración. Puede agregar infraestructura para proporcionar autenticación de conexiones y enseñar a todas nuestras aplicaciones cómo trabajar con el cifrado TLS. Tendremos que asumir la carga del contenido de los equipos individuales y tener en cuenta constantemente los diversos problemas que pueden surgir en las bibliotecas SSL.
Mantener la coherencia en múltiples plataformas es una tarea desagradecida. Me gustaría que el espacio entre las aplicaciones sea razonable, para que exista la posibilidad de realizar un seguimiento. También necesitamos la capacidad de cambiar configuraciones en tiempo de ejecución para no recompilar o reiniciar aplicaciones para la migración. Esta lista de deseos e implementa Service Mesh.
Isstio
Habla sobre
Istio .
Istio es un marco completo para conectar, administrar y monitorear la arquitectura de microservicios. Istio está diseñado para funcionar sobre Kubernetes. Él mismo no implementa el software y no le importa que esté disponible en las máquinas que utilizamos para este propósito con contenedores en Kubernetes.
En la figura, vemos tres secciones diferentes de las máquinas y bloques que conforman nuestros microservicios. Tenemos una forma de agruparlos usando los mecanismos proporcionados por Kubernetes. Podemos apuntar y decir que un grupo específico que puede tener una escala automática adjunta a un servicio web o puede tener otros métodos de implementación contendrá nuestro servicio web. En este caso, no necesitamos pensar en máquinas, operamos en términos del nivel de acceso a los servicios de red.
Esta situación se puede representar en forma de diagrama. Considere un ejemplo cuando tenemos un mecanismo que procesa algunas imágenes. El usuario de la izquierda es el tráfico que nos llega en el microservicio.
Para aceptar el pago del usuario, tenemos un microservicio de pago separado que llama a una API externa que se encuentra fuera del clúster.
Para procesar el inicio de sesión del usuario, proporcionamos un microservicio de autenticación y tiene estados almacenados nuevamente fuera de nuestro clúster en la
base de datos de Cloud SQL .
¿Qué hace Istio? Istio mejora Kubernetes. Lo instala utilizando una función alfa en Kubernetes llamada Initializer. Cuando implemente el software, kubernetes lo notará y preguntará si queremos cambiar y agregará otro contenedor dentro de cada kubernetes. Este contenedor manejará rutas y enrutamiento, tenga en cuenta todos los cambios de la aplicación.
Así se ve el circuito con Istio.
Tenemos máquinas externas que proporcionan proxies entrantes y salientes para el tráfico en un servicio en particular. Podemos descargar las funciones de las que ya hemos hablado. No necesitamos enseñarle a la aplicación cómo realizar telemetría o rastreo usando TLS. Pero podemos agregar otras cosas adentro: interrupción automática, límite de velocidad,
liberación de canario .
Todo el tráfico pasará ahora a través de servidores proxy en máquinas externas, y no directamente a los servicios. Kubernetes hace todo en la misma dirección IP. Podremos interceptar el tráfico que iría a los servicios frontales o finales.
El proxy externo que usa Istio se llama
Envoy .
Envoy es en realidad más viejo que Istio, fue desarrollado en Lyft. Lleva más de un año trabajando en producción, lanzando toda la infraestructura de microservicios. Elegimos Envoy para el proyecto Istio en colaboración con la comunidad. Por lo tanto, Google, IBM y LYFT son las tres compañías que aún están trabajando en ello.
Envoy está escrito en C ++ 11. Ha estado en producción durante más de 18 meses antes de convertirse en un proyecto de código abierto. No tomará muchos recursos cuando lo conecte a sus servicios.
Aquí hay algunas cosas que Envoy puede hacer. Esta es la creación de un servidor proxy para HTTP, que incluye HTTP / 2 y protocolos basados en él, como gRPC. También puede reenviar a otros protocolos a nivel binario. Envoy controla su zona de infraestructura para que pueda hacer que su parte sea autónoma. Puede manejar una gran cantidad de conexiones de red con reintentos y espera. Puede establecer un cierto número de intentos para conectarse al servidor antes de detener la llamada y transmitir información a sus servidores que el servicio no responde.
No debe preocuparse por volver a cargar la aplicación para agregarle configuración. Simplemente conéctese a él utilizando una API muy similar a kubernetes y cambie la configuración en tiempo de ejecución.
El equipo de Istio ha hecho una gran contribución a la plataforma UpStream Envoy. Por ejemplo, una alerta de error de inyección. Hicimos posible ver cómo se comporta la aplicación en caso de exceder el número de solicitudes para el objeto que falló. Y también implementó las funciones de visualización gráfica y separación de tráfico para manejar casos cuando se utiliza la implementación canaria.
La figura muestra cómo se ve la arquitectura del sistema Istio. Tomaremos solo dos microservicios que se mencionaron anteriormente. Finalmente, en el diagrama, todo es muy similar a una red definida por software. Desde el servidor proxy Envoy, que implementamos con las aplicaciones, el tráfico se transfiere mediante tablas IP en el espacio de nombres. El panel de control es responsable de administrar la consola, pero no procesa el tráfico en sí.
Tenemos tres componentes. Pilot, que crea la configuración, observa las reglas que se pueden cambiar usando la API para el panel de control de Istio y luego actualiza Envoy para que se comporte como un servicio de descubrimiento de clúster. Istio-Auth sirve como autoridad de certificación y transmite certificados TLS a los servidores proxy. La aplicación no requiere SSL, se pueden conectar a través de HTTP y los servidores proxy se encargarán de todo esto por usted.
Mixer procesa solicitudes para garantizar que cumpla con la política de seguridad y luego transmite información de telemetría. Sin realizar ningún cambio en la aplicación, podemos ver todo lo que sucede dentro de nuestro clúster.
Beneficios de Istio
Entonces, hablemos con más detalle sobre las cinco cosas que obtendremos de Istio. En primer lugar, considere
la gestión del tráfico . Podemos separar el control del tráfico de la escala de la infraestructura, por lo que antes podríamos hacer algo así como 20 instancias de la aplicación y 19 de ellas estarán en la versión anterior, y una en la nueva, es decir, el 5% del tráfico estará en la nueva versión. Con Istio, podemos implementar cualquier cantidad de instancias que necesitemos, y al mismo tiempo indicar qué porcentaje de tráfico debe enviarse a las nuevas versiones. Una simple regla de separación.
Todo se puede programar sobre la marcha utilizando reglas. Envoy se actualizará periódicamente a medida que cambie la configuración, y esto no dará lugar a interrupciones del servicio. Dado que trabajamos en el nivel de acceso a los servicios de red, podemos ver los paquetes y, en este caso, existe la oportunidad de ingresar al agente de usuario, que se encuentra en el tercer nivel de la red.
Por ejemplo, podemos decir que cualquier tráfico del iPhone sigue una regla diferente, y vamos a dirigir una cierta fracción del tráfico a la nueva versión, que queremos probar para un dispositivo específico. El microservicio de llamadas internas puede determinar a qué versión específica necesita conectarse y puede transferirlo a otra versión, por ejemplo, 2.0.
La segunda ventaja es la
transparencia . Cuando tiene una vista dentro del clúster, puede comprender cómo está hecho. No necesitamos crear herramientas para métricas en el proceso de desarrollo. Las métricas ya están en cada componente.
Algunos creen que es suficiente mantener un registro de registro para el monitoreo. Pero, de hecho, todo lo que necesitamos es tener un conjunto de indicadores tan universal que se pueda alimentar a cualquier servicio de monitoreo.
Así es como se ve la barra de herramientas Istio creada usando el servicio Prometheus. Recuerde implementarlo dentro del clúster.
En el ejemplo, la captura de pantalla muestra una serie de parámetros supervisados específicos para todo el clúster. Se pueden deducir cosas más interesantes, por ejemplo, qué porcentaje de aplicaciones da más de 500 errores, lo que implica una falla. El tiempo de respuesta se agrega en todas las instancias de servicio de llamada y respuesta dentro del clúster; esta funcionalidad no requiere configuración. Istio sabe qué admite Prometheus y sabe qué servicios están disponibles en su clúster, por lo que Istio-Mixer puede enviar métricas a Prometheus sin ninguna configuración adicional.
Veamos como funciona. Si llama a un servicio específico, el servicio proxy envía información sobre esta llamada a Mixer, que captura parámetros tales como el tiempo de espera para la respuesta, el estado del código y la IP. Los normaliza y los envía a cualquier servidor que haya configurado. Especialmente para mostrar los indicadores principales, existe el servicio Prometheus y los adaptadores FLUX DB, pero también puede escribir su propio adaptador y mostrar datos en cualquier formato para cualquier otra aplicación. Y no tiene que cambiar nada en la infraestructura si desea agregar una nueva métrica.
Si desea realizar una investigación más profunda, use el
sistema de rastreo distribuido
Zipkin . La información sobre todas las llamadas enrutadas a través del Istio-Mixer se puede enviar a Zipkin. Allí verá toda la cadena de llamadas de microservicio al responder al usuario y encontrará fácilmente un servicio que está retrasando el tiempo de procesamiento.
A nivel de aplicación, hay poca necesidad de preocuparse por crear una traza. Envoy pasa toda la información necesaria al Mezclador, que lo envía a la traza, por ejemplo, a Zipkin, la
traza de stackdriver de Google o cualquier otra aplicación de usuario.
Hablemos de
tolerancia a fallos y eficiencia .
Los tiempos de espera entre llamadas de servicio son necesarios para probar el estado de, en primer lugar, los equilibradores de carga. Introducimos errores en esta conexión y vemos qué sucede. Considera un ejemplo. Supongamos que hay una conexión entre el servicio A y el servicio B. Esperamos una respuesta del servicio de video durante 100 milisegundos y damos solo 3 intentos si no se recibe el resultado. En esencia, lo vamos a tomar por 300 milisegundos antes de que informe un intento de conexión fallido.
Además, por ejemplo, nuestro servicio de películas debería analizar la calificación de la película a través de otro microservicio. La calificación tiene un tiempo de espera de 200 milisegundos y se dan dos intentos de llamada. Llamar a un servicio de video puede hacer que espere 400 milisegundos si la calificación de estrellas está fuera de su alcance. Pero, recordamos, después de 300 ms, el servicio de películas informará que está inactivo, y nunca sabremos la verdadera causa de la falla. Usar tiempos de espera y probar lo que sucede en estos casos es una excelente manera de encontrar todo tipo de errores inteligentes en su arquitectura de microservicios.
Veamos ahora qué hay con eficiencia. El equilibrador de kubernetes actúa solo al nivel de la cuarta capa. Inventamos un constructor de entrada para el equilibrio de carga desde la segunda capa hasta la séptima. Istio se implementa como un equilibrador para la capa de red con acceso a los servicios de red.
Realizamos la descarga de TLS, por lo que utilizamos SSL moderno y bien dopado en Envoy, para que no tenga que preocuparse por las vulnerabilidades.
Otra ventaja de Istio es la
seguridad .
¿Cuáles son las características básicas de seguridad en Istio? El servicio Istio-Auth funciona en varias direcciones. Utiliza un marco público y un conjunto de estándares de autenticación para los servicios
SPIFFE . Si hablamos de flujo de tráfico, entonces tenemos una autoridad de certificación Istio que emite certificados para las cuentas de servicio que ejecutamos dentro del clúster. Estos certificados cumplen con el estándar SPIFFE y son distribuidos por Envoy utilizando el mecanismo de seguridad kubernetes. Envoy utiliza claves para la autenticación TLS bidireccional. Por lo tanto, las aplicaciones de fondo reciben identificadores en función de los cuales ya es posible organizar una política.
Istio mantiene certificados raíz por sí mismo para que no se preocupe por las fechas de revocación y vencimiento. El sistema responderá a la escala automática, por lo que al introducir una nueva entidad, obtendrá un nuevo certificado. Sin ajustes manuales. No necesita configurar un firewall. Los usuarios utilizarán políticas de red y kubernetes para implementar firewalls entre contenedores.
Finalmente, la
aplicación de políticas . Mixer es un punto de integración con backends de infraestructura que puede expandir con Service Mesh. Los servicios pueden moverse fácilmente dentro de un clúster, implementarse en múltiples entornos, en la nube o localmente. Todo está diseñado para el control operativo de las llamadas que pasan por Envoy. , , . , - 20 . 20 , .
, , , , ICL . , , , , . , Mixer , . .
, Istio? . . , . , .
Istio
Istio kubernetes, , , 1.7 . - kubernetes. Google Container Engine Alpha clusters. , .
Istio — github. 0.2. 0.1 kubernetes. 0.2 kubernetes. , . Envoy , . Istio ,
Cloud Foundry .
. Google Container Engine 1.8 -, Istio — .
, 14 DevOops 2018 (): , .