Usamos envoy como un proxy frontal que redirige el tráfico entrante a múltiples clústeres de Kubernetes (para nuevos servicios) y a los backends de la arquitectura heredada del patrimonio histórico. Aquellos. Combina las funciones de un balanceador ordinario y un punto de terminación ssl y una puerta de enlace api.
Antes de envoy, teníamos nginx allí, como muchos otros. Genial software, me gusta. Toda la historia con Envoy comenzó en el momento en que los microservicios comenzaron en grandes cantidades e incluso las plantillas ansible no lo salvaron del creciente tiempo dedicado a administrar la configuración de nginx. Llevó mucho tiempo implementarlo, además de que los administradores se desanimaron de solicitudes monótonas como "consígame un dominio para un nuevo servicio". Era evidente que se necesitaba una automatización Better ™. Idealmente, para que quien necesite poner en marcha algo pueda hacerlo él mismo y preferiblemente en el mismo lugar donde configuró otros parámetros de su servicio. Además, quería más transparencia en lo que sucede dentro del proxy frontal y en el segmento entre este y los upstream, y más capacidades de equilibrio nativas (solicitudes repetitivas de diferentes tipos, exclusión de hosts en mal estado bajo ciertas condiciones, controles de ayuda). Y atrajo la tecnología de punta,por supuesto.
En pocas palabras, aquí hay una traducción del artículo sobre la transición de Dropbox a Envoy, hay muchos detalles sobre su comparación con nginx. Te contaré más sobre las impresiones personales de los resultados de la transición.
El hecho más importante y obvio para cualquiera que se haya encontrado con el uso de software escalable: esté preparado para pagar por él. La mayor complejidad de la configuración (plano de datos + plano de control), y si hay aguas arriba no solo en kubernetes, quizás incluso escriba su propio plano de control. Además, en el caso de envoy específicamente, por la relativa juventud del software y, por lo tanto, por la ausencia de algunas características comunes de nginx + una mayor frecuencia de actualizaciones, si se agregan estas características. Por ejemplo, puede resultar que en las opciones estándar no hay un valor predeterminado para nginx combinando barras diagonales en: ruta, eliminar el puerto del encabezado del Host o, Dios me perdone, reescribir por expresiones regulares. Por hoy, ya se ha agregado todo lo de esta lista, pero seguramente encontrarás algo más.
Cosas positivas
¡Qué documentación terrible! En el lado positivo, el equipo enviado finalmente contrató a un escritor de tecnología a fines del año pasado y las cosas se han vuelto mucho más amigables. Al menos, ya no necesitas estudiar la forma de procesar una solicitud a través del código fuente y encontrar una descripción del trabajo de algunas opciones exclusivamente en las respuestas de tu problema. Y para encontrar las opciones por sí mismas, sea un maestro de Google de nivel 80. Ahora mucho de esto está en el pasado, aunque los autores todavía no se molestan en marcar en qué versión de enviado apareció esta o aquella opción, o mediante enlaces al tema en las notas de la versión, pero al menos empezaron a resaltar la lista. de cambios importantes en las versiones en una sección dedicada, puede ver que hay progreso.
Telemetría extendida
Aquí todas las esperanzas estaban justificadas, ahora nuestro panel de grafana by envoy mata a todos los navegadores que no están preparados con una serie de gráficos. Pero en serio, ahora puede monitorear convenientemente lo que está sucediendo con el tráfico en todas las etapas de su paso, lo que ayuda especialmente bien en emocionantes historias de detectives: investigaciones después de incidentes. Y, por supuesto, la definición de anomalías.
Anomalía: "Hola". Un fragmento del mismo panel de envoy grafana.
Plano de control
Bueno, y lo más importante, por el bien de que todo se inició, solucionamos el problema del control automático de rutas. Dos palabras sobre el enfoque, si alguien no está en el tema: el plano de control funciona como controlador de datos, administra su almacenamiento y crea una configuración, que luego se envía al envoy (plano de datos sin estado).
Si solo tiene un kubernetes como backend, puede tomar un plano de control listo para usar del tipo embajador. Pero también tuvimos que administrar la infraestructura anterior, además de que había varios clústeres. Así que tuve que tomar una de las implementaciones de la API del plano de datos propuestas por el proyecto enviado y arruinar todas las características que necesitamos, conectando esta parte de la infraestructura con la automatización en kubernetes, pero este es un tema para otra historia interesante.
Impresiones del proceso de cambio a enviado - "por alguna razón no hubo problemas especiales, muy sospechoso".
En resumen, por dónde empezar y para qué estar preparado de inmediato. Después de meditar en la documentación del envoy y aceptar la inutilidad de la existencia, tomamos dos hosts virtuales del antiguo proxy frontal (el más simple, el más típico y el más extenso), los iniciamos en envoy, clasificando las opciones en el camino.
Lo principal a tener en cuenta aquí es que los enfoques para escribir configuraciones entre nginx y envoy son muy diferentes, es decir, debemos estar preparados para giros bruscos de la forma: en lugar de dos simples entradas permitir / denegar, escribimos 26 líneas del árbol de reglas RBAC. En general, aceptar que un poco de cabeza explosiva aquí es normal, ya que la configuración del envoy se realiza con una prioridad en la conveniencia de la automatización y no en la legibilidad humana.
Es posible que deba armar una hoja de trucos para el mapeo de opciones y asegurarse de que realmente hagan lo que usted cree que hacen. Así que una vez llegamos a la conclusión de que el mecanismo para combinar barras en la URL (incluso cuando ya se agregó a envoy) funciona de manera diferente: en nginx no cambió: path, que se envió a upstream, y en envoy, un completo se llevó a cabo la reescritura. y todo estaría bien, pero con esta reescritura, salió un error que cambió: ruta por completo al juego, bueno, en general, después de nuestro problema también se solucionó, pero cuidado.
Por cierto, sobre los problemas, no puedo evitar mencionar una impresión más positiva.
Desarrolladores y comunidad amigable
Dado que envoy es de código abierto alojado en CNCF, tradicionalmente puede simplemente venir al GitHub del proyecto y sugerir su mejora o hacer una pregunta. Los problemas son un número enorme, los desarrolladores claramente no tienen suficientes manos, pero al mismo tiempo lo peor que le puede pasar a su pregunta es que será ignorada. Aunque la mayoría de las veces al menos algo, pero responden, incluso si es algo corto en el espíritu de "lo siento, no planeamos hacer esto". Sin toxicidad, incluso si preguntas de novatos, ambiente muy agradable.
Temas atmosféricos, especialmente corgis. Captura de pantalla del repositorio público de envoy en github.com
Bueno, como de costumbre, las solicitudes de extracción son bienvenidas. Ayudan incluso a aquellos que no son particularmente buenos en C ++. También hay una serie de problemas marcados con la etiqueta de principiante, en caso de que alguien quiera contribuir y no sepa por dónde empezar.
Además de GitHub, también hay boletines informativos por correo electrónico y holgura, pero este último suele ser un desastre. :)
De los eventos, se lleva a cabo EnvoyCon, que, sin embargo, ahora está en línea, pero aún lo recomiendo.
Salir
En general, no se necesita enviado solo porque es moderno y juvenil, "todo el mundo se pasa" y el fundador tiene un peinado divertido. Quédese donde estaba hasta que apriete. Si tiene una startup o solo un proyecto pequeño, definitivamente es mejor dejar nginx, porque es simple y lindo. Lo principal es empezar por ahí.
Si hay muchos servicios, muchos desarrolladores, hay kubernetes y todas las ventajas y desventajas del artículo anterior no le molestan, puede pensar y probar.
¡Buena suerte y tal vez nos vemos en la EnvoyCon!