Publicar una sesión de preguntas y respuestas en la malla de servicios. La sesión se llevó a cabo en preparación para el Slurm intensivo en malla de servicios. Hay una grabación en Youtube .
Los expertos respondieron las preguntas más populares sobre la tecnología de malla de servicios y las preguntas de los participantes del evento. Preguntas clave de la sesión de AMA:
- ¿Qué es una malla de servicios?
- Cuando implementar
- Alternativas a Istio,
- ¿Por qué se usa Envoy en la malla de servicios y no Nginx?
Marsel Ibraev, STO Slorm, moderó el evento, y Alexander Lukyanchenko, líder del equipo en el equipo de arquitectura de Avito, e Ivan Kruglov, ingeniero de software de planta en Databricks, compartieron su experiencia.
Ambos ingenieros tienen experiencia no solo trabajando con una implementación de malla de servicio específica, sino también construyendo la suya propia, que es mucho más interesante.
Marsel Ibraev: ¿Qué es una malla de servicios y qué tareas resuelve?
Alexander Lukyanchenko: Comenzaría con la definición básica de que la malla de servicios es, en primer lugar, un enfoque que tiene muchas implementaciones específicas. El punto principal es que cuando tenemos algún tipo de sistema distribuido que funciona, interactúa a través de la red, agregamos una capa de red adicional que nos permite agregar algunas características, cualquier lógica a la interacción entre servicios de los nodos de la red.
En palabras más simples, cuando tenemos un conjunto de microservicios, algunas piezas del sistema, simplemente agregamos un servidor proxy especial a cada una de estas piezas y dejamos el tráfico entre estos microservicios a través de los servidores proxy. Así, obtenemos un gran conjunto de posibilidades diferentes para la gestión del tráfico entre estos servicios, para la recopilación de estadísticas, el seguimiento. De hecho, hay muchas más cosas interesantes en forma de seguridad, TLS mutuo, etc. Pero lo principal es que la malla de servicios es un enfoque.
Ivan Kruglov:Estoy de acuerdo con usted. Todos conocemos los microservicios. Y muchos de nosotros tomamos monolitos y los vimos. Tengo tal observación que cuando la gente habla de cortar un monolito, imagina un ladrillo y comienza a dividirlo en pequeños cubos. Estos cubos son sus servicios. Y cuando pensamos en ellos, nos centramos en los cubos, olvidando que la complejidad, la lógica empresarial que estaba en proceso de romper el monolito, no se ha ido a ningún lado. Parte de la complejidad permaneció en los cubos, pero quedan muchas dificultades y problemas en el espacio entre estos cubos, en las flechas, que la gente suele dibujar con líneas finas. Y hay muchos problemas.
Por ejemplo, una simple llamada a función que anteriormente era solo una llamada a función se convierte en una llamada remota. Es decir, llega a todos los problemas de interacción de la red, además de autorización, autenticación, rastreo, monitoreo; en general, todo un conjunto de características. La malla de servicios está tratando de resolver exactamente el problema de la complejidad de las interacciones entre servicios, estas mismas flechas que conectan nuestros cubos (microservicios) con usted. Esta es mi comprensión de la malla de servicios. También lo considero comunicación como servicio. Algunos servicios que permiten que sus servicios interactúen entre sí, abstrayendo en cierta medida los problemas de interacción en términos de confiabilidad, monitoreo y seguridad.
Marsel Ibraev:Podemos concluir que la malla de servicios no es una tecnología específica, sino un enfoque que, en un sentido práctico, es la adición de servidores proxy a cada microservicio. Esto nos permite gestionar de forma más flexible tanto el tráfico como la seguridad de la conexión entre estos microservicios. Seguramente hay algún tipo de Plano de Control condicional o Demonio que monitoriza todo esto, gestiona esto, distribuye de forma centralizada las configuraciones a estos servidores proxy, etc.
Ivan Kruglov:En general, sí. Sin embargo, el servicio de proxy es un atributo opcional. Para la malla de servicios, creo que será una configuración dinámica, porque en un entorno de microservicios es importante cuando es dinámico. Todo cambia, escala: escala hacia arriba, escala hacia abajo. Y en mi opinión, el dinamismo es el criterio más importante. Y con el resto, estoy de acuerdo.
Alexander Lukyanchenko: También diría que Control Plane es solo una de las partes de la malla de servicios que nos permite personalizarlo y nos dice desde un punto directamente a todo el sistema qué reglas necesitamos, cómo debe interactuar todo. Un control tan flexible sobre todo el sistema desde un punto.
Marsel Ibraev: Pasemos a la siguiente pregunta: ¿Cuándo debemos pensar en cuándo debemos implementar una malla de servicios? ¿Cuáles son los pros y los contras de usarlo? Hasta donde yo sé, la malla de servicios es una tecnología relativamente joven. En el sentido de que ahora solo las grandes empresas se permiten implementarlo, recién están comenzando a hacerlo, en particular, en Rusia. Cuánto debe pensar un profano en el momento de usar la malla de servicio. ¿Qué factores sirven para determinar esto? Bueno, ¿qué implicará esto, cuáles son los pros y los contras de usarlo?
Alexander Lukyanchenko:En cualquier caso, pasaría de necesidades y problemas. Vale recordar que ahora esta tecnología realmente está ganando popularidad y muchos están comenzando a implementarla o quieren implementarla, pero resuelve ciertos problemas. Uno de los casos de uso más extendidos para la implementación es la mejora de la observabilidad, es decir, comprender cómo interactúan todos los cubos en general dentro de nuestro gran sistema. Y con la ayuda de la malla de servicios, obtenemos de manera unificada la oportunidad de hacerlo de manera inmediata y completa para todo el sistema. Este es uno de los casos de solución.
Lo que dijo Ivan sobre la confiabilidad y la resistencia de las redes que obtenemos cuando pasamos a una arquitectura de microservicio. También es uno de los problemas que se puede solucionar con la ayuda de una malla de servicios, introduciendo enfoques como Circuit Breaker, retrays automáticos, es decir, patrones de interacción de red, y todo esto está fuera de nuestra lógica de negocio, fuera de nuestros cubos. , de manera uniforme para todo el sistema.
Teniendo estos problemas en nuestro sistema, podemos simplemente resolverlos implementando una malla de servicios. Obviamente, la solución a estos casos es un plus, tanto en términos de simplicidad como en las especificidades de cómo podemos poner una malla de servicios en nuestro sistema. Porque, por ejemplo, si necesitamos configurar algún tipo de monitoreo unificado en todo el sistema, asegúrese de que se recopilen algunas métricas comunes de todos los servicios: para latencia, solicitudes, errores, etc., esta puede ser una tarea realmente difícil. ... Y no en un entorno homogéneo puede resultar difícil de solucionar. En el caso de la malla de servicios, tenemos la oportunidad de hacerlo más fácilmente agregando estos contenedores proxy y tenemos la capacidad de configurar todo en todo el sistema de manera unificada. Esta es probablemente una de las características clave de la malla de servicios.
También me encanta la definición de que, de hecho, una malla de servicios es una tecnología que podría resolverse completamente dentro de las aplicaciones comerciales, pero debido a la complejidad, no podemos agregar una lógica unificada a cientos y miles de componentes de nuestro sistema y obtener algunos característica, simplemente la movemos a otro nivel de interacción a través de estos proxies de servicio y obtenemos todas estas capacidades, que de hecho podrían implementarse en las propias aplicaciones comerciales. Y en sistemas heterogéneos, esto realmente resulta muy útil. Ésta es una gran ventaja.
De las desventajas, destacaría la actuación. La implementación debe evaluar con precisión cómo interactúan las piezas del sistema. Por ejemplo, hay casos bastante limitados, pero cuando tenemos una gran cantidad de interacción síncrona de red, por ejemplo, a través del protocolo HTTP dentro del sistema, recibimos entradas adicionales a través de cada proxy de servicio. En la mayoría de los casos esto no es un problema, pero vale la pena tenerlo en cuenta al momento de introducir esta tecnología, para entender que trae cierta sobrecarga a nuestro sistema, y le agregamos cada nodo.
Y el segundo inconveniente, que probablemente sea incluso más audaz que el primero, es la complejidad de la configuración y la implementación de esas implementaciones que existen ahora. Aunque la tecnología ya no es muy joven, todavía no es fácil de implementar en un sistema grande o mediano. Esto se debe al hecho de que hay una gran cantidad de posibilidades, grandes configuraciones de dispersión: el umbral para ingresar e introducir esta tecnología en el sistema es bastante alto.
Ivan Kruglov: También intentaré responder a esta pregunta. Vendré de lejos. Intentaré explicar por qué decidí implementar una malla de servicios en mi empresa en 2018. Hablo de Booking.com.
El problema era que teníamos varios servicios y una biblioteca que se encargaba de la comunicación entre servicios. Sabía cómo emitir métricas, pudo emitir retrocesos, es decir, patrones de confiabilidad, y pudo descubrir servicios. Todo funcionó bien, todo parecía ir bien. Pero hubo dos grandes problemas.
Problema número uno: tuve entre 20 y 30 servicios. No estaban bajo mi control. Se desplegaron de acuerdo con su horario por un equipo ubicado en otras zonas horarias, y necesito actualizar alguna versión. Y el proceso de actualización llevó mucho tiempo. Tuve que esperar. Y es mucho tiempo de espera.
En segundo lugar, comenzamos en ese momento a pasar a un enfoque más de microservicios. Y estaba claro que tenemos una sola pila. Sasha habló de pilas homogéneas y heterogéneas. Traduzcamos al ruso. Una pila homogénea es cuando tiene una tecnología, por ejemplo Java, y todos sus servicios están en Java. Heterogéneo es cuando tienes un zoológico. Un servicio en Python, uno en Java, el tercero en Go. En Booking.com, decidimos no apostar en una pila homogénea, decidimos apostar por el hecho de que habrá muchas pilas. Por lo tanto, estaba claro que una biblioteca, en la que todo es hermoso, tendría que reescribirse en 4-5 idiomas potenciales, y luego todo esto aún sería compatible. Y también es deseable hacerlos todos en el mismo tono. Y las métricas para que den lo mismo. Y también implementaron patrones de confiabilidad de manera consistente. En general, estaba claro que se trataba de una hemorroide enorme,y, por lo tanto, se nos ocurrió una solución a estos problemas cambiando a una única plataforma o enfoque, es decir, implementando un proxy que haría todas las métricas, patrones y descubrimientos de la misma manera, independientemente de en qué esté escrita la aplicación detrás. .
Hablando más específicamente sobre el uso de la malla de servicios, entonces no tengo respuesta de que en este punto es necesario usarlo, pero en este punto no es necesario. Pero, en general, cuantos más servicios tenga y en más idiomas estén escritos, es más probable que la malla de servicios le ayude. Hablo de probabilidad, no de confianza, porque allí también hay muchos problemas. Y Sasha habló de ellos. Si sus servicios son responsables de cientos de milisegundos, bueno, un proxy le agregará un par de milisegundos; no sentirá mucha diferencia.
Un problema mucho mayor es la difusión de la tecnología. Istio tiene más entidades que Kubernetes. Es decir, es más complicado. Por supuesto, ahora están trabajando en la simplificación, pero en general, se trata de tecnologías independientes que necesitan apoyo y para las que es necesario asignar recursos. Además del hecho de que debe aprenderlo usted mismo, hasta cierto punto debe capacitar a algunos de sus desarrolladores para que lo usen.
Marsel Ibraev: Sobre los gastos generales, desde el punto de vista de la infraestructura, lo que vi es ejecutar un proxy en cada servicio, pero también el consumo de RAM. Cada pod con nosotros ahora consume 50-70 MB de RAM más, incluso en reposo, si recuerdo correctamente las métricas que miré. Es decir, debe pensar si realmente lo necesita.
Para resumir, si su empresa tiene un clúster en expansión realmente grande, una aplicación en expansión grande con un montón de microservicios, e incluso escrita en diferentes idiomas, existen requisitos serios para la tolerancia a fallas y la solución rápida de problemas, de modo que si algún tipo de Si ocurre una falla, podemos solucionar todo esto rápidamente, lo principal es comprender rápidamente dónde surgió exactamente este problema. Como dijo Ivan, no hay un solo factor o un solo argumento que diga que ahora necesitamos implementar una malla de servicios. Cuanto más se suman estos argumentos, más debe mirar hacia la malla de servicios y preparar algo de terreno, tal vez implementar en un clúster de prueba, profundizar, ver cómo es. Por supuesto, se pone fácilmente en producción, el mismo Istio.
Ivan Kruglov:Este ya es el mercado. Si quieres conquistar el mercado, maximizas tu base de clientes. Y para ello es necesario que la instalación sea lo más sencilla posible. Por tanto, todo está optimizado para ello.
Marsel Ibraev: Sí. La siguiente pregunta que me gustaría discutir es que si la malla de servicios es un enfoque, una metodología, ¿qué productos específicos existen ahora? ¿Qué es relevante? ¿Y a qué debe fijarse si una empresa decide probar una malla de servicios?
Alexander Lukyanchenko:Desde el punto de vista de la implementación, ahora tiene sentido probar diferentes implementaciones. Si hablamos de nombres específicos, entonces la solución más popular ahora es Istio, que ha sido muy poderosa en campañas de marketing durante varios años en cuanto a un conjunto de sus características, tratando de implementarse en todas partes. Probablemente la mayoría de la gente conozca exactamente a Istio. Esta implementación realmente existe desde hace bastante tiempo, tiene una gran cantidad de posibilidades y, en principio, después de las últimas versiones, ya está lo suficientemente madura. Apto para su uso en producción y, en principio, ya ha tenido algunos problemas básicos asociados con el rendimiento, la instalación inicial y la configuración. La personalización se simplifica y la tecnología se vuelve más implementable. Pero hay algunas tecnologías más a las que definitivamente prestaría atención.
El primero es Console Connect. Este es un desarrollo de Hashicorp. Las tecnologías Hashicorp y sus herramientas son de alta calidad. En caso de que ya tenga algo de su pila, es una buena historia para considerar la inclusión de su solución de malla de servicios. En cuanto a la cantidad de posibilidades, generalmente se ponen al día con Istio, pero lo implementan de una manera más reflexiva y detallada, en gran parte debido al hecho de que hashicorp tiene sus propios clientes, en los que inicialmente prueban estos productos y luego los emiten listos. -Soluciones hechas al público.
Y también destacaría Linkerd2. Se llamó Conduit durante mucho tiempo. Vale la pena considerar esta solución en términos de características y rendimiento. Debido a que es bastante diferente al resto, utiliza su propio servidor proxy. Y gracias a esto, puede proporcionar una mejor escalabilidad. En este sentido, Envoy-proxy es bastante adecuado para casi cualquier implementación y se usa en grandes empresas, incluida la nuestra, y desde el punto de vista de la sobrecarga, principalmente en términos de recursos, cuánto uso adicional de tiempo de procesador, RAM, en En principio, la relación de en comparación con el consumo de servicios empresariales es aceptable. Es decir, esta diferencia se encuentra únicamente en la red, la pila de la red, el procesamiento de solicitudes y la funcionalidad real que lleva Envoy-proxy.
En realidad, miraría desde diferentes ángulos hacia tres soluciones: Istio, Console Connect y Linkerd2. Al final del día, es probable que todas las tareas que necesita resolver en su sistema las cumplan. Cuál de estas tecnologías es mejor para usted ya dependerá de lo que le resulte más conveniente y lo que más le guste. Si hablamos de la visión, personalmente me parece que en última instancia, si no los ganadores, entonces en mayor medida los líderes de las soluciones de malla de servicios basadas en Envoy-proxy, simplemente porque ahora está ganando una inmensa popularidad, tiene una muy gran cantidad de funciones listas para usar ... Y, muy probablemente, la mayor parte de la malla de servicios estará en él. Sin embargo, todavía vale la pena mirarlo todo.
Ivan Kruglov:Estoy de acuerdo con Alexander. Istio es el más grande, el más popular, también porque Google está detrás de él. Esta es su tecnología. El resto no se tocó y no lo sé. Pero sé que Hashicorp tiene que ver con la facilidad de uso. Tiene sentido mirar allí. Y si tiene un servicio Discovery o utiliza Consul, también tiene sentido buscar allí. Linkerd2 es la tercera versión disponible actualmente.
Marsel Ibraev: ¿Por qué se utiliza Envoy en la malla de servicios? ¿Por qué no herramientas más sofisticadas como Nginx o Haproxy que tienen mucha funcionalidad? Al parecer, falta algo. ¿Qué?
Ivan Kruglov:La principal característica de una malla de servicios es el dinamismo. Y es precisamente esto lo que está ausente tanto en Nginx como en Haproxy. Nacieron en la era de una configuración más estática que se podía escribir en configuraciones, describir y no cambiaban o no cambiaban con frecuencia. En la malla de servicios, los cambios se realizan cada segundo. Envoy y Linkerd tienen sus propios protocolos que le permiten introducir configuraciones dinámicamente en ellos. Puede escribir un servicio que enviará la configuración allí a través de HTTP2. Y ambos reconstruyen tablas dinámicamente, funcionan muy bien. Para mí, esta es la razón principal por la que Nginx y Haproxy no se arraigan en la malla de servicios.
Alexander Lukyanchenko:Estoy de acuerdo en que el dinamismo es la característica principal y se estableció en el diseño de Envoy. Debo decir que Haproxy también tuvo esta oportunidad en las últimas implementaciones, y ahora están tratando activamente de hacer una malla de servicios sobre esta base. Pero hay un punto más que es muy importante, en mi opinión. Por la misma razón que Envoy se creó como una solución nativa de la nube, puso patrones dentro de sí mismo, como una distribución bastante extensa de métricas en toda la interacción de la red. Nginx tiene estas cosas, pero se logra con la ayuda de módulos y enlaces adicionales, y Envoy-proxy lo tiene y todo sale de la caja, disponible por defecto. Y cuando coloca esto en su sistema, inmediatamente obtiene datos valiosos que tendrían que recopilarse, probarse y perfeccionarse utilizando otras tecnologías.
Marsel Ibraev:Como resultado, resulta que si tenemos servicios de proxy en forma de Envoy, tenemos algunas oportunidades, algunas características. Y la siguiente pregunta está relacionada con esto. Si estamos hablando de la malla de servicios, sobre el hecho de que es realmente difícil, pero parece muy interesante, ahora me gustaría centrarme en qué características hay en la malla de servicios. Seguridad, observabilidad, estrategias de despliegue.
Ivan Kruglov:El término observabilidad generalmente se entiende como una combinación de tres: monitoreo (métricas clásicas), registro, rastreo. Esto es lo que le permite a usted, como operador de servicio, comprender lo que está sucediendo o sucedió en su servicio ahora o en el pasado. Debo decir de inmediato que el registro no afecta la malla del servicio de ninguna manera. Es decir, en el contexto de la malla de servicios, se trata de métricas y seguimiento.
Al responder a esta pregunta, la reformularé primero. ¿Qué aporta la introducción de esta tecnología al negocio? En mi opinión, esto es coherencia. Déjame explicarte ahora. Imagine que tiene, en términos relativos, 100 microservicios y necesita comprender cómo interactúan entre sí. Puede instrumentar servicios y hacer que escuchen métricas HTTP. Pero lo más probable es que todo resulte inconsistente. Alguien informará en segundos, alguien informará en milisegundos, alguien informará una clase de error de 5xx, alguien emitirá 500. Aparece una inconsistencia. Por lo tanto, surge la pregunta de construir un solo tablero para comprender lo que está sucediendo con su sistema. Y todo se convierte en un gran dolor de cabeza. Debido a que sus métricas se llaman de manera diferente, están en diferentes unidades, etc. Con la malla de servicios, este problema se resuelve de una vez,debido a que implementa todo con un Envoy, escupe métricas con el mismo nombre, en las mismas unidades, con los mismos depósitos, etc. Solo se está construyendo un tablero, donde selecciona el servicio deseado y ve una lista de todo lo que le sucede.
El rastreo es un poco más complicado, porque se basa en encabezados, y estos encabezados deben pasarse entre la entrada y la salida de la aplicación. Es decir, se requiere un poco de instrumentación adicional, pero en general el resultado es el mismo. Se le presenta una topología y la capacidad de realizar un seguimiento de una solicitud específica. En una arquitectura de microservicios en expansión, descubrir qué está sucediendo es un gran desafío. El plano de control en la malla de servicios es un panel de control centralizado, por lo que puede impulsar determinadas políticas de forma centralizada. A partir de la frecuencia de reintentos, tiempos de espera. Imagina que has creado un nuevo servicio. Y si ha configurado correctamente las configuraciones predeterminadas, inmediatamente obtiene monitoreo, rastreo, reintentos, retrocesos, interruptores automáticos listos para usar, y en algunas de las mejores implementaciones. Puede enviar certificados, políticas de acceso (por ejemplo,este servicio puede hablar con uno, pero no con el otro).
Resumiendo. La consistencia es cuando los puntos de referencia para el control del servicio aparecen en la arquitectura de microService, y esta es la posibilidad de una gestión centralizada de políticas, configuraciones, etc.
Alexander Lukyanchenko: También me gustaría añadir que, dado que la malla servicio es sobre la introducción en la interacción sincrónica entre nuestro microservicios, existen infinitas posibilidades para administrar el tráfico que va entre servicios. Esta es una oportunidad para realizar implementaciones canarias allí, implementaciones azul-verde: aquellas cosas que son difíciles o imposibles de hacer de inmediato, por ejemplo, en Kubernetes.
Si hablamos de capacidades de equilibrio, también hay un conjunto muy rico de capacidades en términos de configuración interna. Se trata de varias políticas de balanceo con hash para clavar la solicitud a ciertos endpoints, la posibilidad del mismo balanceo de peso, por ejemplo, protección de la conexión entre microservicios, TLS mutuo, que, a diferencia de la configuración manual, son realmente más fáciles de operar, porque la gestión de los certificados, su distribución y rotación se puede realizar a nivel de la malla de servicios, y es posible que los propios servicios empresariales ni siquiera sepan que la interacción entre los servicios tiene lugar a través de algún tipo de protocolo seguro. Generalmente, esto puede ser un punto clave, especialmente para aquellos que trabajan en un entorno de múltiples nubes, que tienen instancias en una nube pública y en otra, o, por ejemplo, instancias manchadas entre centros de datos distribuidos, también casos,en el que esta tecnología es obligatoria para su implementación. Y con la ayuda de la malla de servicios, es posible resolver esto más fácilmente que si se implementa manualmente sin ella.
El conjunto completo de estas posibilidades es una herramienta de solución muy interesante. También hay casos más limitados, pero pueden resultar clave. Por ejemplo, Ingeniería del Caos para implementar la degradación de la interacción o, por ejemplo, la política. Realmente resulta ser una herramienta de solución genial. También hay casos más limitados, pero pueden ser clave para cerrar una necesidad específica de una empresa específica.
Marsel Ibraev:Resulta, en resumen, que la malla de servicios, independientemente de su implementación, representa una única herramienta centralizada que nos permite implementar una serie de características, en particular, tenemos un monitoreo u observabilidad estandarizado tan uniforme, si hablamos en términos de la malla de servicios, recopilamos todas las métricas necesarias, el rastreo y todo lo que necesitas. Al mismo tiempo, podemos cerrar inmediatamente el problema de seguridad: podemos crear políticas de red, cifrado y tenemos opciones muy flexibles para trabajar con el tráfico: varios equilibrios, opciones de implementación complicadas, etc. Esto puede ser suficiente para pensar en la implementación, especialmente en grandes proyectos.
Continuando con el tema de implementación. Digamos le vendimos la idea al negocio y nos saturamos con esta idea, ¿qué pasos deben seguir los especialistas desde el punto de vista técnico y organizativo? ¿Cómo implementar correctamente una malla de servicios en la suya si ya tenemos el mismo Kubernetes? ¿Cómo implementar una malla de servicios sin romper nada?
Alexander Lukyanchenko:Aquí les contaré un poco de nuestra experiencia. La introducción de esta tecnología es posible gradualmente. Podemos elegir claramente las partes del sistema para las que estamos implementando esta tecnología, probarla allí, observar su impacto en el mismo rendimiento, ver si obtenemos el resultado deseado, el conjunto de características deseado. Y despliegue gradualmente. Por ejemplo, Istio permite que Envoy se inyecte automáticamente en cada microservicio mediante la tecnología de webhook que agrega un contenedor a nuestro pod debajo del capó. Y podemos decir claramente que queremos ver Envoy-proxy en tal o cual espacio de nombres o Envoy ya implementado en tal o cual casos. Esto es si hablamos de implementación en producción.
Y si hablamos de la organización, aquí debe comprender cómo funciona técnicamente el sistema, cómo va la interacción con los servicios, para que en la etapa de problemas ya pueda intentar resolverlo. Y patinar todo en la caja de arena. Si tiene un clúster de Kubernetes que repite la producción, pero con menos carga, puede implementarlo, buscarlo y luego ir al clúster de producción. Aquí debe pensar en todos los pasos para desactivar rápidamente este sistema en caso de un problema. Es decir, al hacerlo, puede asegurarse de inmediato de que todo va de forma gradual, incluso para cada servicio. La dificultad de depurar radica en entender qué está pasando realmente en algún momento, lo cual no es una tarea fácil, y para poder recuperarse rápidamente desde el punto de vista de la implementación en producción, definitivamente recomendaría comenzar con un sandbox, porque a pesar de su simplicidad de alto nivel, la tecnología difícilno es fácil de depurar y es necesario tener una comprensión clara de lo que sucede allí para encontrar problemas rápidamente.
:Estoy de acuerdo. Tú, Sasha, hablaste principalmente sobre Istio. Para que quede claro, cuando hablo de una malla de servicios, me refiero a una autoescrita. Cuando comenzamos (en Booking.com), Istio era la versión 0.1 y en ningún caso quería llevarlo a producción, porque la tecnología era terriblemente cruda. Y en retrospectiva, Vanya hizo todo bien. La segunda razón por la que decidí escribir la mía propia, porque en ese momento no había una malla de servicios fuera de Kubernetes. Istio en ese momento tenía a Kubernetes como su única plataforma. Ahora lo están cortando lentamente para que esté fuera de Kubernetes, pero Kubernetes sigue siendo la pieza central. Aquí es donde se almacena la configuración. Y no había Kubernetes en Booking.com hace tres años, y tuve que vivir fuera de eso. Volviendo a la pregunta principal, sí, estoy de acuerdo con Sasha en que las ventajas aquí sonque se puede implementar gradualmente. Eso fue lo que hice. Orientado al servicio. De los menos críticos, pasando a los más críticos. Como resultado, el último servicio que trasladamos a la malla de servicios fue el servicio de búsqueda, que devolvió un millón de RPS por segundo. Fue el servicio más duro de la empresa.
Marsel Ibrayev: Para resumir, simplemente nos adherimos al enfoque correcto, no hacemos movimientos bruscos y, como dijo Alexander, no tomamos la simplicidad del nivel superior al pie de la letra , porque todo es mucho más complicado bajo el capó. ¿Hay algo que agregar sobre la malla de servicios fuera de Kubernetes: Istio y Linkerd2?
Ivan Kruglov:La última vez que miré a Istio fue hace aproximadamente un año, y estaba en un estado semi-funcional. Creo que ahora está en un estado normal. Agregaron la capacidad de agregar a Kubernetes, declarar instancias en él que están fuera del marco de Kubernetes. ¿Por qué no se podía extender Istio a Kubernetes antes? Porque Istio se basó en las primitivas de Kubernetes: servicio, puntos finales. Es decir, Istio lideró su descubrimiento desde allí. Introdujeron un concepto, en mi opinión, se llama servicio virtual o entrada de servicio, con el cual se puede declarar, prescribir que tengo algún tipo de instancia, está disponible a través de algún tipo de dirección IP. Pero según tengo entendido, es su responsabilidad mantener actualizada esta descripción. Si tiene un servicio de hierro en el que está clavada la dirección IP, entonces todo está bien. Si es algo más dinámico,luego hay que escribir con las manos, apoyar con las manos.
: Entendí esta pregunta de esta manera: es incluso posible una malla de servicios, donde no hay tecnologías de Kubernetes. Esto es técnicamente posible. Debido a que Kubernetes es solo un orquestador, existen otras soluciones. Istio fue diseñado originalmente para funcionar con una variedad de soluciones, y había un componente que ahora es parte del cuerpo principal de Control Plane llamado Galay. Simplemente se dedicaba a convertir varios manifiestos en una sola descripción, que Istio ya entiende por configuración. Por lo tanto, podríamos personalizarlo para casi cualquier solución. Y desde el punto de vista de bare-metal, o algún tipo de máquina virtual, donde no hay herramientas de automatización, allí, en principio, puede instalar Envoy, escribir políticas de ruta para que el tráfico pase por Envoy. Pero aquí está la cuestión de los beneficios de esto y las funciones que queremos obtener. Es técnicamente posible poner en cualquier lugar,la única cuestión es la facilidad de uso y la necesidad de esta solución.
:Por cierto, para que los colegas lo entiendan, Envoy es uno de los componentes clave, uno de los dos componentes clave de todas las mallas de servicios modernas. Fue creado por Lyft. Su malla de servicio era muy condicional. Configuraron a sus enviados a través de archivos de configuración. Y solo más tarde desarrollaron algún Plano de Control escrito por ellos mismos. Escribir un plano de control, por cierto, no es tan difícil. Hay un protocolo claramente declarado. Y hay desarrollos de plantillas, algunos enlaces que le permiten crear su propio Plano de Control. De hecho, en las implementaciones actuales, la luz no ha convergido como una cuña, por supuesto, tienen muchas características y soporte de la comunidad, pero en general, si necesitas algunas características específicas que no puedes encontrar en lo que es, entonces hay una posibilidad de escribir el tuyo. Por supuesto, esto es una sobrecarga, lo suficientemente seria,pero existe una posibilidad: la tecnología está abierta, todos los protocolos están descritos. Si estamos considerando la cuestión de si una malla de servicios es posible fuera de Kubernetes, en un sentido amplio, sí, es posible, no hay restricciones. Más concretamente, ¿es posible estirar Istio fuera de Kubernetes, o Consul para estirar fuera de Kubernetes, como dicen, depende. Cuanto más avanzamos, más posible se hace. En Istio, creo que ahora puede ser bastante impresionante. Consul Connect, en mi opinión, entró en esta área sin Kubernetes. Por lo tanto, debería funcionar de inmediato. Creo que en Consul Connect todo está vinculado a Consul Service Discovery. Si sus servicios son visibles en su Discovery, también estarán visibles en la malla de servicios.no hay restricciones. Más concretamente, ¿es posible estirar Istio fuera de Kubernetes, o Consul para estirar fuera de Kubernetes, como dicen, depende. Cuanto más avanzamos, más posible se hace. En Istio, creo que ahora puede ser bastante impresionante. Consul Connect, en mi opinión, entró en esta área sin Kubernetes. Por lo tanto, debería funcionar de inmediato. Creo que en Consul Connect todo está vinculado a Consul Service Discovery. Si sus servicios son visibles en su Discovery, también estarán visibles en la malla de servicios.no hay restricciones. Más concretamente, ¿es posible estirar Istio fuera de Kubernetes, o Consul para estirar fuera de Kubernetes, como dicen, depende. Cuanto más avanzamos, más posible se hace. En Istio, creo que ahora puede ser bastante impresionante. Consul Connect, en mi opinión, entró en esta área sin Kubernetes. Por lo tanto, debería funcionar de inmediato. Creo que en Consul Connect todo está vinculado a Consul Service Discovery. Si sus servicios son visibles en su Discovery, también estarán visibles en la malla de servicios.Entré a esta área sin Kubernetes. Por lo tanto, debería funcionar de inmediato. Creo que en Consul Connect todo está vinculado a Consul Service Discovery. Si sus servicios son visibles en su Discovery, también estarán visibles en la malla de servicios.Entré a esta área sin Kubernetes. Por lo tanto, debería funcionar de inmediato. Creo que en Consul Connect todo está vinculado a Consul Service Discovery. Si sus servicios son visibles en su Discovery, también estarán visibles en la malla de servicios.
Marsel Ibrayev: En la parte superior ahora tenemos una pregunta de Anton, quien pregunta qué habrá en la malla de servicios intensiva. Sí, estamos planeando realizar un intensivo en línea sobre el tema de la malla de servicios del 19 al 21 de marzo. (Nota del editor: el primer intensivo pasó, el segundo intensivo está programado para el 24 y 26 de septiembre de 2021.)Todo esto será tratado por nuestros expertos. Ivan Kruglov es un líder de práctica. Todos nuestros programas educativos provienen de la práctica, por lo que prestamos mucha atención a esto. Y Alexander Lukyanchenko será el orador del intensivo. No habrá suficiente teoría de un capitán así. En su mayor parte, nos centraremos en la práctica, en la aplicación práctica. Vamos a instalar la malla de servicios de inmediato, haremos todo usando Istio como ejemplo. Instalemos, averigüémoslo, ejecutémoslo, averigüémoslo con abstracciones, vayamos directamente a las funciones conmovedoras, estrategias de implementación, multiclúster, mTLS, ingeniería del caos, etc. Definitivamente tocaremos todo lo que tenemos en el concepto de malla de servicios con nuestras propias manos, y al final recibirás algunos conocimientos y habilidades que te ayudarán en el futuro a hacer e implementar todo esto por tu cuenta. Formato de aprendizaje, en vivo, en Zoom.
Esta fue la primera parte de la transcripción de la sesión de AMA. Una continuación con preguntas adicionales de los participantes del evento ya está en proceso, publicaremos pronto. ¿Cuál es el problema de la malla de servicios que le preocupa?