Al implementar un clúster de Kubernetes para una aplicación específica, es fundamental comprender los requisitos que presenta la propia aplicación, así como los del negocio y los desarrolladores. Con esta información, se puede proceder a tomar decisiones arquitectónicas y, en particular, elegir un controlador de Ingress específico, de los cuales hoy en día hay una gran cantidad. Para proporcionar una visión básica de las opciones disponibles sin necesidad de estudiar numerosos artículos/documentación, hemos preparado este resumen, incluyendo los principales controladores de Ingress (listos para producción).
Esperamos que esto ayude a nuestros colegas en la elección de la solución arquitectónica; al menos será un punto de partida para obtener más información y realizar experimentos prácticos. Previamente, hemos examinado otros materiales similares en la red y, curiosamente, no encontramos ninguno que sea más o menos completo y, sobre todo, estructurado. ¡Así que llenemos este vacío!
Criterios
Para poder realizar comparaciones y obtener resultados útiles, es necesario entender no solo el área temática, sino también tener una lista concreta de criterios que definirán la dirección de la investigación. Sin pretender analizar todos los posibles casos de uso de Ingress/Kubernetes, hemos intentado destacar los requisitos más comunes para los controladores: estén preparados para que toda su especificidad y particularidades deberán estudiarse por separado.
Pero comenzaré con características que se han vuelto tan habituales que están implementadas en todas las soluciones y no se consideran:
- descubrimiento de servicios dinámico;
- terminación de SSL;
- funcionamiento con websockets.
Ahora, sobre los puntos de comparación:
Protocolos soportados
Uno de los criterios fundamentales para la elección. Su software puede no operar con el estándar HTTP o requerir funcionar con múltiples protocolos a la vez. Si su caso es no estándar, asegúrese de tener en cuenta este factor para evitar tener que reconfigurar el clúster más adelante. La lista de protocolos soportados varía entre todos los controladores.
Software en la base
Hay varias aplicaciones en las que se basa el controlador. Las más populares son nginx, traefik, haproxy, envoy. En general, puede que no influya demasiado en cómo se recibe y se transmite el tráfico, pero siempre es útil conocer los matices y características de lo que hay "bajo el capó".
Enrutamiento de tráfico
¿En qué se basa la decisión sobre la dirección del tráfico hacia un servicio determinado? Por lo general, son el host y el path, pero también hay posibilidades adicionales.
Espacio de nombres dentro del clúster
El espacio de nombres (namespace) es la capacidad de dividir lógicamente los recursos en Kubernetes (por ejemplo, en stage, producción, etc.). Hay controladores Ingress que deben instalarse por separado en cada namespace (y entonces pueden dirigir el tráfico solo a los pods de ese espacio). Y hay otros (la gran mayoría de ellos) que funcionan globalmente en todo el clúster; en ellos, el tráfico se dirige a cualquier pod del clúster, sin importar el espacio de nombres.
Sondeos para upstreams
¿Cómo se asegura la dirección del tráfico hacia instancias saludables de la aplicación o de los servicios? Hay opciones con chequeos activos y pasivos, reintentos (retries), interruptores de circuito (para más detalles consúltese, por ejemplo, en ), implementaciones propias de chequeos de salud (custom health checks), etc. Es un parámetro muy importante si tiene altos requisitos de disponibilidad y para sacar oportunamente a los servicios que hayan fallado de la balanceo.
Algoritmos de balanceo
Aquí hay muchas opciones: desde las tradicionales hasta exóticas como , así como funcionalidades específicas como .
Autenticación
¿Qué esquemas de autorización soporta el controlador? Basic, digest, oauth, external-auth; creo que estas opciones deberían ser familiares. Este es un criterio importante si se utilizan muchos entornos para desarrolladores (y/o simplemente cerrados), cuyo acceso se realiza a través de Ingress.
Distribución de tráfico
¿El controlador soporta mecanismos comunes para la distribución de tráfico, como despliegues canarios (canary), pruebas A/B, y espejeo de tráfico (mirroring/shadowing)? Este es un tema realmente delicado para las aplicaciones que requieren una gestión cuidadosa y precisa del tráfico para las pruebas productivas, la depuración de errores de productos sin estar en producción (o con pérdidas mínimas), el análisis de tráfico, etc.
Suscripción paga
¿Hay una opción de pago para el controlador, con funciones avanzadas y/o soporte técnico?
Interfaz Gráfica (Web UI)
¿Existen interfaces gráficas para gestionar la configuración del controlador? Principalmente para la 'comodidad' y/o para aquellos que necesitan realizar cambios en la configuración de Ingress, pero trabajar con plantillas 'crudas' es incómodo. Puede ser útil en caso de que los desarrolladores deseen experimentar con el tráfico sobre la marcha.
Validación JWT
Disponibilidad de una verificación integrada de tokens web JSON para autorizar y validar al usuario en la aplicación final.
Opciones de personalización de la configuración
Extensibilidad de las plantillas en el sentido de contar con mecanismos que permitan agregar directivas, banderas, etc., propias a las plantillas de configuración estándar.
Mecanismos básicos de protección contra DDOS
Algoritmos sencillos de limitación de tasa o versiones más complejas para filtrar tráfico basado en direcciones, listas blancas, países, etc.
Seguimiento de solicitudes
Capacidades de observación, seguimiento y depuración de solicitudes desde Ingress hacia servicios/pods específicos, y en ideal, también entre servicios/pods.
WAF
Soporte .
Controladores Ingress
La lista de controladores fue formulada basada en y . Algunos de ellos los hemos excluido de la revisión debido a su especificidad o baja difusión (etapa temprana de desarrollo). Los restantes se describen a continuación. Comenzaremos con una descripción general de las soluciones y continuaremos con una tabla resumen.
Ingress de Kubernetes
Sitio web:
Licencia: Apache 2.0
Este es el controlador oficial para Kubernetes, que es desarrollado por la comunidad. Como es evidente por el nombre, se basa en nginx y se complementa con un conjunto de plugins de Lua que se utilizan para implementar funcionalidades adicionales. Gracias a la popularidad de nginx y a las modificaciones mínimas que se realizan sobre él al utilizarlo como controlador, esta opción puede ser la más sencilla y comprensible de configurar para un ingeniero promedio (con experiencia en web).
Ingress de NGINX Inc
Sitio web:
Licencia: Apache 2.0
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 hacia atrás constante, ausencia de módulos externos y la velocidad mejorada declarada (en comparación con el controlador oficial), lograda al prescindir de Lua.
La versión gratuita está significativamente reducida, incluso en comparación con el controlador oficial (debido a la falta de los mismos módulos de Lua). La versión de pago, sin embargo, tiene una funcionalidad adicional bastante amplia: métricas en tiempo real, validación JWT, verificaciones de salud activas y más. Una ventaja importante sobre NGINX Ingress es el soporte completo para tráfico TCP/UDP (¡y también en la versión comunitaria!). Desventaja — funciones para la distribución de tráfico, lo cual, sin embargo, 'tiene la máxima prioridad para los desarrolladores', pero requiere tiempo para su implementación.
Kong Ingress
Sitio web:
Licencia: Apache 2.0
Producto desarrollado por Kong Inc. en dos versiones: comercial y gratuita. Se basa en nginx, cuyas capacidades se han ampliado con un gran número de módulos en Lua.
Originalmente estaba diseñado para procesar y enrutar solicitudes de API, es decir, como un API Gateway, sin embargo, actualmente se ha convertido en un controlador Ingress completo. Principales ventajas: muchos módulos adicionales (incluidos de desarrolladores externos), que son fáciles de instalar y configurar y que permiten implementar una amplia gama de funcionalidades adicionales. Sin embargo, las funciones integradas ya ofrecen muchas posibilidades. La configuración se realiza mediante recursos CRD.
Una característica importante del producto — trabajar dentro de un solo entorno (en lugar de cross-namespaced) es un tema controvertido: a algunos les parecerá una desventaja (hay que crear entidades para cada entorno), mientras que para otros es una característica (unmayor audiencia.mayor nivel de aislamiento, ya que si un controlador falla, el problema se limita a un solo entorno).
Traefik
Sitio web:
Licencia: MIT
Proxy que fue creado inicialmente para trabajar con la gestión de solicitudes en microservicios y su entorno dinámico. De ahí provienen muchas funcionalidades útiles: actualización de la configuración sin reinicios, soporte para múltiples métodos de balanceo, interfaz web, envío de métricas, soporte para varios protocolos, API REST, lanzamientos canary y mucho más. Una característica agradable es el soporte integrado para certificados Let’s Encrypt. La desventaja es que para organizar alta disponibilidad (HA), el controlador necesitará instalar y conectar su propio almacenamiento KV.
HAProxy
Sitio web:
Licencia: Apache 2.0
HAProxy es conocido desde hace mucho tiempo como proxy y equilibrador de tráfico. En el marco de un clúster de Kubernetes, se ofrece una actualización de configuración "suave" (sin pérdida de tráfico), descubrimiento de servicios basado en DNS, y configuración dinámica a través de API. La personalización completa de la plantilla de configuraciones mediante la sustitución de CM, así como la posibilidad de utilizar funciones de la biblioteca Sprig, pueden resultar atractivas. En general, la solución se centra en la alta velocidad de operación, su optimización y eficiencia en el uso de recursos. La ventaja del controlador es el soporte para un número récord de métodos de balanceo diversos.
Voyager
Sitio web:
Licencia: Apache 2.0
Un controlador basado en HAproxy que se posiciona como una solución universal, con amplias funcionalidades en numerosos proveedores. Ofrece la posibilidad de balancear tráfico en L7 y L4, siendo el balanceo de tráfico TCP L4 una de las características clave de la solución.
Contour
Sitio web:
Licencia: Apache 2.0
Esta solución no solo se basa en Envoy: fue desarrollada junto con los autores de este popular proxy. Una característica importante es la capacidad de dividir el control de recursos Ingress mediante recursos IngressRoute CRD. Para organizaciones con múltiples equipos de desarrollo que utilizan un solo clúster, esto ayuda a maximizar la seguridad en el manejo del tráfico en contornos adyacentes y protegerlos de errores al modificar recursos Ingress.
También se ofrece un conjunto ampliado de métodos de balanceo (incluye la duplicación de solicitudes, reintentos automáticos, limitación del rate de solicitudes y mucho más), monitoreo detallado del flujo de tráfico y fallas. Tal vez para algunos será un inconveniente significativo la falta de soporte para sesiones persistentes (aunque ya se está trabajando en ello) ).
Istio Ingress
Sitio web:
Licencia: Apache 2.0
Una solución integral de service mesh que no solo actúa como controlador Ingress, gestionando el tráfico entrante desde el exterior, sino que también controla todo el tráfico dentro del clúster. "Detrás de las cámaras", como proxy sidecar para cada servicio, se utiliza Envoy. Es, en esencia, una gran herramienta que "puede hacer de todo", y su idea principal es la máxima gestionabilidad, escalabilidad, seguridad y transparencia. Con ello, puedes ajustar la ruta de tráfico, la autorización de acceso entre servicios, el balanceo, el monitoreo, lanzamientos canarios y mucho más. Lee más sobre Istio en la serie de artículos "».
Ambassador
Sitio web:
Licencia: Apache 2.0
Otra solución basada en Envoy. Tiene versiones gratuitas y comerciales. Se posiciona como "totalmente nativa de Kubernetes", lo que ofrece ventajas correspondientes (integración estrecha con los métodos y entidades del clúster K8s).
Tabla comparativa
Entonces, la culminación del artículo es esta enorme tabla:
Es clicable para permitir una visualización más detallada, así como disponible en formato .
Resumiendo
El objetivo del artículo es proporcionar una comprensión más completa (aunque no exhaustiva) de qué opción elegir en su caso particular. Como suele ser, cada controlador tiene sus ventajas y desventajas…
El Ingress clásico de Kubernetes es valorado por su accesibilidad y confiabilidad, ofreciendo suficientes características en general. Sin embargo, si hay requisitos más altos en términos de estabilidad, funciones y desarrollo, deberías considerar el Ingress con NGINX Plus y una suscripción paga. Kong tiene un extenso conjunto de complementos (y, por ende, las capacidades que ofrecen), aumentando incluso más en su versión paga. Ofrece amplias posibilidades como API Gateway, y configuración dinámica basada en recursos CRD, además de los servicios básicos de Kubernetes.
Si tienes requisitos más altos en balanceo y métodos de autorización, considera Traefik y HAProxy. Estos son proyectos de código abierto, probados a lo largo de los años, muy estables y en activo desarrollo. Contour apareció hace un par de años, pero todavía luce demasiado joven y solo tiene funcionalidades básicas añadidas sobre Envoy. Si hay requisitos de tener/usar un WAF antes de la aplicación, deberías considerar el mismo Ingress de Kubernetes o HAProxy.
Los productos más ricos en funcionalidades son aquellos construidos sobre la base de Envoy, especialmente Istio. Se presenta como una solución integral que "puede hacerlo todo", lo que, sin embargo, implica un umbral de entrada significativamente más alto en términos de configuración/lanzamiento/administración, en comparación con otras soluciones.
Hemos elegido y seguimos utilizando como controlador estándar el Ingress de Kubernetes, que cubre el 80-90% de nuestras necesidades. Es bastante confiable, fácil de configurar y expandir. En general, en ausencia de requisitos específicos, debería ser adecuado para la mayoría de clústeres/aplicaciones. De productos igualmente versátiles y relativamente simples, se pueden recomendar Traefik y HAProxy.
P.D.
También puedes leer en nuestro blog:
- «Regreso a los microservicios junto con Istio»: , , ;
- «»;
- «».
Fuente: habr.com
