Al lanzar un clúster de Kubernetes para una aplicación específica, debe comprender qué representan la aplicación en sí, el negocio y los desarrolladores para este recurso. Con esta información, puede comenzar a tomar una decisión arquitectónica y, en particular, elegir un controlador Ingress específico, de los cuales ya hay una gran cantidad en la actualidad. Para tener una idea básica de las opciones disponibles sin tener que leer muchos artículos/documentación, etc., hemos preparado esta descripción general, que incluye los principales controladores de entrada (listos para producción).
Esperamos que ayude a los colegas a elegir una solución arquitectónica; al menos, se convertirá en un punto de partida para obtener información más detallada y experimentos prácticos. Anteriormente, estudiamos otros materiales similares en la red y, curiosamente, no encontramos una sola revisión más o menos completa y, lo más importante, estructurada. ¡Así que llenemos ese vacío!
criterios
En principio, para hacer una comparación y obtener algún resultado útil, es necesario comprender no solo el área temática, sino también tener una lista específica de criterios que establecerán el vector de investigación. Sin pretender analizar todos los casos posibles de uso de Ingress/Kubernetes, tratamos de resaltar los requisitos más generales para los controladores: esté preparado para que, en cualquier caso, tenga que estudiar todos sus detalles por separado.
Pero comenzaré con las características que se han vuelto tan familiares que se implementan en todas las soluciones y no se consideran:
- descubrimiento dinámico de servicios (service discovery);
- terminación SSL;
- trabajando con websockets.
Ahora los puntos de comparación:
Protocolos compatibles
Uno de los criterios de selección fundamentales. Es posible que su software no funcione en HTTP estándar o que requiera trabajar en varios protocolos a la vez. Si su caso no es estándar, asegúrese de tener en cuenta este factor para que no tenga que volver a configurar el clúster más adelante. Para todos los controladores, la lista de protocolos admitidos varía.
software en el centro
Hay varias variaciones de aplicaciones en las que se basa el controlador. Los más populares son nginx, traefik, haproxy, enviado. En el caso general, puede que no tenga mucho efecto sobre cómo se recibe y transmite el tráfico, pero siempre es útil conocer los posibles matices y características de lo que está "debajo del capó".
Enrutamiento de tráfico
¿Sobre la base de qué es posible tomar una decisión sobre la dirección del tráfico a un servicio en particular? Por lo general, estos son el host y la ruta, pero existen posibilidades adicionales.
Espacio de nombres dentro de un clúster
Espacio de nombres (namespace): la capacidad de dividir lógicamente los recursos en Kubernetes (por ejemplo, en el escenario, producción, etc.). Hay controladores de entrada que deben instalarse por separado en cada espacio de nombres (y luego pueden dirigir el tráfico sólo a las vainas de este espacio). Y están aquellos (y su clara mayoría) que funcionan globalmente para todo el clúster; en ellos, el tráfico se dirige a cualquier pod del clúster, independientemente del espacio de nombres.
Muestras para aguas arriba
¿Cómo se dirige el tráfico a instancias saludables de la aplicación, servicios? Hay opciones con controles activos y pasivos, reintentos, disyuntores (Para más detalles, véase, por ejemplo, ), controles de salud personalizados, etc. Un parámetro muy importante si tiene altos requisitos de disponibilidad y eliminación oportuna de los servicios fallidos del equilibrio.
Algoritmos de equilibrio
Hay muchas opciones: desde tradicionales a lo exótico , así como características individuales como .
Autentificación
¿Qué esquemas de autorización admite el controlador? Basic, digest, oauth, external-auth: creo que estas opciones deberían ser familiares. Este es un criterio importante si hay muchos bucles de desarrollador (y/o solo privados) a los que se accede a través de Ingress.
Distribución del tráfico
¿Admite el controlador mecanismos de distribución de tráfico de uso común como canary rollouts (canary), pruebas A/B, duplicación de tráfico (mirroring/shadowing)? Este es un tema realmente delicado para las aplicaciones que requieren una gestión de tráfico precisa y precisa para pruebas productivas, depuración de errores de productos fuera de línea (o con pérdidas mínimas), análisis de tráfico, etc.
suscripción paga
¿Existe una opción paga para el controlador, con funcionalidad avanzada y/o soporte técnico?
Interfaz gráfica de usuario (interfaz de usuario web)
¿Hay alguna GUI para administrar la configuración del controlador? Principalmente para "manualidad" y/o para aquellos que necesitan hacer algunos cambios en la configuración de Ingress'a, pero trabajar con plantillas "en bruto" es un inconveniente. Puede ser útil si los desarrolladores quieren realizar algunos experimentos con el tráfico sobre la marcha.
Validación JWT
La presencia de validación integrada de tokens web JSON para la autorización y validación del usuario en la aplicación final.
Posibilidades de personalización de la configuración
Extensibilidad de plantillas en el sentido de tener mecanismos que le permitan agregar sus propias directivas, banderas, etc. a las plantillas de configuración estándar.
Mecanismos básicos de protección DDOS
Algoritmos de límite de velocidad simples u opciones de filtrado de tráfico más complejas basadas en direcciones, listas blancas, países, etc.
Solicitar seguimiento
La capacidad de monitorear, rastrear y depurar solicitudes de Ingresses a servicios / pods específicos, e idealmente también entre servicios / pods.
WAF
Apoyar .
Controladores
La lista de controladores se formó con base en и . Algunos de ellos se excluyeron de la revisión debido a su especificidad o baja prevalencia (etapa temprana de desarrollo). El resto se comenta a continuación. Comencemos con una descripción general de las soluciones y continuemos con una tabla resumen.
Ingreso desde Kubernetes
Página Web:
Licencia: Apache 2.0
Este es el controlador oficial de Kubernetes y está siendo desarrollado por la comunidad. Obviamente, por el nombre, se basa en nginx y se complementa con un conjunto diferente de complementos de Lua que se utilizan para implementar funciones adicionales. Debido a la popularidad de nginx en sí mismo y a las modificaciones mínimas que se le hacen cuando se usa como controlador, esta opción puede ser la más fácil de configurar para el ingeniero promedio (con experiencia en la web).
Ingreso por NGINX Inc.
Página Web:
Licencia: Apache 2.0
El producto oficial de los desarrolladores de nginx. Tiene una versión de pago basada en . La idea principal es un alto nivel de estabilidad, compatibilidad constante con versiones anteriores, la ausencia de módulos extraños y la mayor velocidad declarada (en comparación con el controlador oficial), lograda debido al rechazo de Lua.
La versión gratuita se reduce significativamente, incluso cuando se compara con el controlador oficial (debido a la falta de los mismos módulos Lua). Al mismo tiempo, el pago tiene una funcionalidad adicional bastante amplia: métricas en tiempo real, validación JWT, controles de salud activos y más. Una ventaja importante sobre NGINX Ingress es el soporte completo para el tráfico TCP / UDP (¡y también en la versión comunitaria!). menos - característica de distribución de tráfico, que, sin embargo, "tiene la máxima prioridad para los desarrolladores", pero lleva tiempo implementarla.
Entrada de Kong
Página Web:
Licencia: Apache 2.0
Producto desarrollado por Kong Inc. en dos versiones: comercial y gratuita. Basado en nginx, que se ha ampliado con una gran cantidad de módulos Lua.
Inicialmente, se centró en procesar y enrutar solicitudes de API, es decir, como API Gateway, pero por el momento se ha convertido en un controlador de entrada completo. Principales ventajas: muchos módulos adicionales (incluidos los de desarrolladores externos) que son fáciles de instalar y configurar y con la ayuda de los cuales se implementa una amplia gama de funciones adicionales. Sin embargo, las funciones integradas ya ofrecen muchas posibilidades. La configuración del trabajo se realiza utilizando recursos CRD.
Una característica importante del producto: trabajar dentro del mismo contorno (en lugar de espacios de nombres cruzados) es un tema controvertido: para algunos parecerá una desventaja (tiene que producir entidades para cada contorno), y para alguien es una característica ( bоMayor nivel de aislamiento, ya que si un controlador está roto, entonces el problema se limita solo al circuito).
Traefik
Página Web:
Licencia: MIT
Un proxy que se creó originalmente para trabajar con el enrutamiento de solicitudes para microservicios y su entorno dinámico. Por lo tanto, muchas funciones útiles: actualización de la configuración sin reiniciar, soporte para una gran cantidad de métodos de balanceo, interfaz web, reenvío de métricas, soporte para varios protocolos, API REST, versiones Canary y mucho más. Otra buena característica es la compatibilidad con los certificados Let's Encrypt listos para usar. La desventaja es que para organizar la alta disponibilidad (HA), el controlador deberá instalar y conectar su propio almacenamiento KV.
HAProxy
Página Web:
Licencia: Apache 2.0
HAProxy ha sido conocido durante mucho tiempo como proxy y equilibrador de tráfico. Como parte de un clúster de Kubernetes, ofrece una actualización de configuración "suave" (sin pérdida de tráfico), detección de servicios basada en DNS, configuración dinámica mediante API. Puede ser atractivo personalizar completamente la plantilla de configuración reemplazando el CM, así como la capacidad de usar las funciones de la biblioteca Sprig en él. En general, el énfasis principal de la solución está en la alta velocidad, su optimización y eficiencia en los recursos consumidos. La ventaja del controlador es el soporte de un número récord de diferentes métodos de balanceo.
Voyager
Página Web:
Licencia: Apache 2.0
Basado en el controlador HAproxy, que se posiciona como una solución universal que admite una amplia gama de funciones en una gran cantidad de proveedores. Se ofrece una oportunidad para equilibrar el tráfico en L7 y L4, y equilibrar el tráfico TCP L4 como un todo puede considerarse una de las características clave de la solución.
Contorno
Página Web:
Licencia: Apache 2.0
Esta solución no solo se basa en Envoy: fue desarrollada por conjuntamente con los autores de este popular proxy. Una característica importante es la capacidad de separar el control de los recursos de Ingress mediante los recursos CRD de IngressRoute. Para organizaciones con muchos equipos de desarrollo que usan el mismo clúster, esto ayuda a maximizar la seguridad de trabajar con tráfico en bucles vecinos y protegerlos de errores al cambiar los recursos de Ingress.
También ofrece un conjunto ampliado de métodos de equilibrio (existe duplicación de solicitudes, repetición automática, limitación de tasa de solicitudes y mucho más), monitoreo detallado del flujo de tráfico y fallas. Quizás para alguien será un inconveniente importante la falta de soporte para sesiones pegajosas (aunque el trabajo ).
Entrada a Istio
Página Web:
Licencia: Apache 2.0
Una solución integral de malla de servicios que no solo es un controlador de ingreso que administra el tráfico entrante desde el exterior, sino que también controla todo el tráfico dentro del clúster. Debajo del capó, Envoy se usa como un proxy sidecar para cada servicio. En esencia, se trata de una gran cosechadora que “puede con cualquier cosa”, y su idea principal es la máxima manejabilidad, extensibilidad, seguridad y transparencia. Con él, puede ajustar el enrutamiento del tráfico, la autorización de acceso entre servicios, el equilibrio, el monitoreo, las liberaciones canary y mucho más. Lea más sobre Istio en la serie de artículos "".
Marca Virtual
Página Web:
Licencia: Apache 2.0
Otra solución basada en Envoy. Tiene versiones gratuitas y comerciales. Se posiciona como "totalmente nativo de Kubernetes", lo que trae las ventajas correspondientes (estrecha integración con los métodos y entidades del clúster K8s).
tabla comparativa
Entonces, la culminación del artículo es esta enorme tabla:
Se puede hacer clic para una vista más cercana, y también está disponible en el formato .
para resumir
El propósito de este artículo es proporcionar una comprensión más completa (¡sin embargo, de ninguna manera exhaustiva!) de qué elección hacer en su caso particular. Como de costumbre, cada controlador tiene sus propias ventajas y desventajas...
El Ingress clásico de Kubernetes es bueno por su disponibilidad y eficacia, características suficientemente ricas; en el caso general, debería ser "suficiente para los ojos". Sin embargo, si existen mayores requisitos de estabilidad, el nivel de funciones y desarrollo, debe prestar atención a Ingress con NGINX Plus y una suscripción paga. Kong tiene el conjunto más rico de complementos (y, en consecuencia, las oportunidades que brindan), y en la versión paga hay aún más. Tiene amplias oportunidades para funcionar como API Gateway, configuración dinámica basada en recursos CRD, así como servicios básicos de Kubernetes.
Con mayores requisitos para los métodos de compensación y autorización, eche un vistazo a Traefik y HAProxy. Estos son proyectos de código abierto, probados a lo largo de los años, muy estables y en desarrollo activo. Contour ha estado disponible durante un par de años, pero todavía parece demasiado joven y solo tiene características básicas agregadas además de Envoy. Si existen requisitos para la presencia/incrustación de WAF frente a la aplicación, debe prestar atención al mismo Ingress de Kubernetes o HAProxy.
Y los más ricos en términos de funciones son los productos construidos sobre Envoy, especialmente Istio. Parece ser una solución completa que "puede hacer cualquier cosa", lo que, sin embargo, también significa un umbral de entrada significativamente más alto para configuración/lanzamiento/administración que otras soluciones.
Hemos elegido y aún usamos Ingress de Kubernetes como controlador estándar, que cubre el 80-90 % de las necesidades. Es bastante confiable, fácil de configurar y expandir. En general, en ausencia de requisitos específicos, debería adaptarse a la mayoría de los clústeres/aplicaciones. De los mismos productos universales y relativamente simples, se pueden recomendar Traefik y HAProxy.
PS
Lea también en nuestro blog:
- "Volver a los microservicios con Istio": , , ;
- «";
- «".
Fuente: habr.com