Al iniciar un clúster de Kubernetes para una aplicación específica, debe comprender qué requisitos plantea la aplicación en sí, el negocio y los desarrolladores para este recurso. Si tiene esta información, puede comenzar a tomar una decisión arquitectónica y, en particular, a seleccionar un controlador Ingress específico, del cual ya hay un gran número hoy. Para tener una idea básica de las opciones disponibles sin tener que estudiar muchos artículos / documentación, etc., preparamos esta revisión incluyendo los principales controladores de Ingress (listos para producción).
Esperamos que ayude a sus colegas a elegir una solución arquitectónica, al menos será el 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. ¡Entonces, llena este vacío!
Criterios
Para hacer una comparación en principio y obtener un resultado útil, debe comprender no solo el área temática, sino también tener una lista específica de criterios que determinarán el vector de investigación. Sin pretender analizar todos los casos posibles de uso de Ingress / Kubernetes, intentamos resaltar los requisitos más generales para los controladores: prepárese para que tenga que estudiar todos sus detalles y detalles en cualquier caso por separado.
Pero comenzaré con las características que se han vuelto tan familiares que se implementan en todas las decisiones y no se consideran:
- descubrimiento dinámico de servicios (descubrimiento de servicios);
- Terminación SSL;
- trabajar con websockets.
Ahora sobre los puntos de comparación:
Protocolos Soportados
Uno de los criterios fundamentales para la selección. Es posible que su software no funcione en HTTP estándar, o puede requerir trabajo en muchos protocolos a la vez. Si su caso no es estándar, asegúrese de tener en cuenta este factor para no tener que volver a configurar el clúster más adelante. Para todos los controladores, la lista de protocolos admitidos varía.
Basado en software
Hay varias opciones de aplicación en las que se basa el controlador. Los populares son nginx, traefik, haproxy, enviado. En el caso general, puede no afectar la forma en que se recibe y transmite el tráfico, pero siempre es útil conocer los posibles matices y características de lo que está "bajo el capó".
Enrutamiento de tráfico
¿Sobre qué podemos decidir sobre la dirección del tráfico a un servicio en particular? Esto suele ser host y ruta, pero hay características adicionales.
Espacio de nombres de clúster
Espacio de nombres (espacio de nombres): la capacidad de dividir lógicamente los recursos en Kubernetes (por ejemplo, en el escenario, producción, etc.). Hay controladores de Ingress que deben configurarse por separado en cada espacio de nombres (y luego solo puede dirigir el tráfico a los pods de este espacio). Y hay algunos (y su abrumadora mayoría) que funcionan globalmente en 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 comprobaciones activas y pasivas, reintentos, disyuntores
(para obtener más detalles, véalas , por ejemplo, en el artículo sobre Istio ) , implementaciones de comprobaciones de estado personalizadas, etc. Un parámetro muy importante si tiene altos requisitos de accesibilidad y retiro oportuno de los servicios fallidos del saldo.
Algoritmos de equilibrio
Hay muchas opciones: desde el
round robin tradicional hasta los exóticos como
las cookies rdp , así como algunas características como
las sesiones fijas .
Autenticació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 utiliza muchos circuitos para desarrolladores (y / o simplemente cerrados) a los que se accede a través de Ingress.
Distribución del tráfico
¿El controlador admite mecanismos de distribución de tráfico de uso común, como despliegues de canarios, pruebas A / B, duplicación del tráfico (duplicación / sombreado)? Este es un tema realmente doloroso para aplicaciones que requieren un control de tráfico preciso y exacto para pruebas productivas, depuración de errores del producto que no están en combate (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 (IU web)
¿Existe alguna interfaz gráfica para controlar la configuración del controlador? Básicamente, para "manejabilidad" y / o para aquellos que necesitan hacer algunos cambios en la configuración de Ingress, pero trabajar con plantillas "en bruto" es inconveniente. Puede ser útil si los desarrolladores desean realizar algún experimento con el tráfico sobre la marcha.
Validación JWT
La presencia de verificación JSON incorporada de tokens web para la autorización y validación del usuario de la aplicación final.
Características para la personalización de la configuración
Extensibilidad de plantillas en el sentido de tener mecanismos para 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 más sofisticadas para filtrar el tráfico en función de direcciones, listas blancas, países, etc.
Solicitar seguimiento
Posibilidades para observar, rastrear y depurar solicitudes de Ingresss a servicios / pods específicos, e idealmente, también entre servicios / pods.
WAF
Soporte para
firewall de aplicaciones .
Controladores de entrada
La lista de controladores se basó en la
documentación oficial de Kubernetes y en
esta tabla . Se excluyeron algunos de ellos de la revisión debido a su especificidad o baja prevalencia (etapa temprana de desarrollo). Los restantes se discuten a continuación. Comenzamos con una descripción general de las soluciones y continuamos con la tabla dinámica.
Ingress por Kubernetes
Sitio web: github.com/kubernetes/ingress-nginxLicencia: Apache 2.0Este es el controlador oficial de Kubernetes, que está siendo desarrollado por la comunidad. Obviamente, por el nombre, se basa en nginx y se complementa con un conjunto diferente de complementos Lua utilizados para implementar funciones adicionales. Debido a la popularidad de nginx en sí y a las modificaciones mínimas cuando se usa como controlador, esta opción puede ser el ingeniero promedio de configuración más simple y comprensible (con experiencia en la web).
Ingreso de NGINX Inc
Sitio web: github.com/nginxinc/kubernetes-ingressLicencia: Apache 2.0El producto oficial de los desarrolladores de nginx. Tiene una versión paga basada en
NGINX Plus . La idea principal es un alto nivel de estabilidad, compatibilidad con versiones anteriores constante, la ausencia de módulos extraños y el aumento de velocidad declarado (en comparación con el controlador oficial) logrado debido al rechazo de Lua.
La versión gratuita se ha reducido significativamente, incluso en comparación con el controlador oficial (debido a la falta de los mismos módulos Lua). Pagado al mismo tiempo tiene una funcionalidad adicional bastante amplia: métricas en tiempo real, validación JWT, comprobaciones de estado activas 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!). La desventaja es la
falta de características para la distribución del tráfico, que, sin embargo, "tiene la máxima prioridad para los desarrolladores", pero lleva tiempo implementarla.
Kong Ingress
Sitio web: github.com/Kong/kubernetes-ingress-controllerLicencia: Apache 2.0Producto desarrollado por Kong Inc. en dos versiones: comercial y gratuita. Se basa en nginx, cuyas capacidades se expanden mediante una gran cantidad de módulos en Lua.
Inicialmente, se centró en el procesamiento y enrutamiento de solicitudes de API, es decir como API Gateway, pero en este momento se ha convertido en un controlador Ingress completo. Principales ventajas: muchos módulos adicionales (incluso de desarrolladores externos) que son fáciles de instalar y configurar y con los que se implementa una amplia gama de características adicionales. Sin embargo, las funciones integradas ya ofrecen muchas funciones. La configuración del trabajo se realiza utilizando recursos CRD.
Una característica importante del producto: trabajar dentro del mismo circuito (en lugar de espacios cruzados) es un tema controvertido: para algunos parece un inconveniente (debe producir entidades para cada circuito), y para alguien es una característica (
un mayor nivel de aislamiento, porque Si un controlador está roto, entonces el problema se limita a un solo circuito).
Traefik
Sitio web: github.com/containous/traefikLicencia: MITUn proxy creado originalmente para trabajar con el enrutamiento de solicitudes de microservicios y su entorno dinámico. Por lo tanto, muchas características útiles: actualizar la configuración completamente sin reiniciar, admitir una gran cantidad de métodos de equilibrio, una interfaz web, métricas de reenvío, admitir varios protocolos, API REST, lanzamientos canarios y mucho más. Una buena característica también es la compatibilidad con los certificados Let's Encrypt listos para usar. La desventaja es que para la organización de alta disponibilidad (HA), el controlador necesitará instalar y conectar su propio almacenamiento KV.
HAProxy
Sitio web: github.com/jcmoraisjr/haproxy-ingressLicencia: Apache 2.0HAProxy se conoce desde hace mucho tiempo como proxy y equilibrador de tráfico. Como parte del clúster de Kubernetes, ofrece una actualización de configuración "suave" (sin pérdida de tráfico), descubrimiento de servicios basados en DNS, configuración dinámica utilizando la API. La personalización completa de la plantilla de configuración mediante el reemplazo de la CM'a, así como la posibilidad de usar las funciones de la biblioteca Sprig en ella, pueden ser atractivas. En general, el enfoque principal de la solución está en la alta velocidad, su optimismo y eficiencia en los recursos consumidos. La ventaja del controlador es el soporte de un número récord de diferentes métodos de equilibrio.
Voyager
Sitio web: github.com/appscode/voyagerLicencia: Apache 2.0Controlador basado en HAproxy, que se posiciona como una solución universal que admite amplias capacidades en una gran cantidad de proveedores. Se propone la oportunidad de equilibrar el tráfico en L7 y L4, y equilibrar el tráfico TCP L4 en general se puede llamar una de las características clave de la solución.
Contorno
Sitio web: github.com/heptio/contourLicencia: Apache 2.0El enviado no solo sentó las bases de esta solución: fue desarrollada
conjuntamente con los autores de este popular proxy. Una característica importante es la capacidad de dividir la administración de recursos de Ingress utilizando los recursos de IngressRoute CRD. Para organizaciones con muchos equipos de desarrollo que usan un solo clúster, esto ayuda a maximizar la seguridad del tráfico en los circuitos vecinos y protegerlos de errores al cambiar los recursos de Ingress.
También ofrece un conjunto ampliado de métodos de equilibrio (hay duplicación de solicitudes, reintentos automáticos, restricción en la tasa de solicitudes y mucho más), monitoreo detallado del flujo de tráfico y fallas. Quizás para algunos será un inconveniente significativo la falta de soporte para sesiones fijas (aunque el trabajo
ya está en
marcha ).
Ingreso de Isstio
Sitio web: istio.io/docs/tasks/traffic-management/ingressLicencia: Apache 2.0Una solución integral de malla de servicios, que no solo es un controlador de entrada que controla el tráfico entrante desde el exterior, sino que también controla todo el tráfico dentro del clúster. Bajo el capó, Envoy se utiliza como proxy de sidecar para cada servicio. En esencia, esta es una gran combinación que "puede hacer 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, la supervisión, los lanzamientos de canarios y mucho más. Lea más sobre Istio en la serie de artículos
Volver a microservicios con Istio .
Embajador
Sitio web: github.com/datawire/ambassadorLicencia: Apache 2.0Otra solución basada en Envoy. Tiene una versión gratuita y comercial. Se posiciona como "completamente nativo de Kubernetes", lo que trae las ventajas correspondientes (estrecha integración con los métodos y entidades del clúster K8).
Tabla de comparación
Entonces, el clímax del artículo es esta gran tabla:
Se puede hacer clic para una visualización más detallada, y también está disponible en formato de
Hojas de cálculo de Google .
Para resumir
El propósito del artículo es proporcionar una comprensión más completa (sin embargo, ¡absolutamente no exhaustiva!) De qué elección hacer en su caso particular. Como de costumbre, cada controlador tiene sus propias ventajas y desventajas ...
El clásico Kubernetes Ingress es bueno por su accesibilidad y capacidad de prueba, bastante rico en capacidades, en general, debería ser "suficiente para los ojos". Sin embargo, si hay mayores requisitos de estabilidad, nivel de características y desarrollo, vale la pena prestar atención a Ingress con NGINX Plus y una suscripción paga. Kong tiene un rico conjunto de complementos (y, en consecuencia, las capacidades proporcionadas por ellos), y en la versión paga hay aún más. Tiene amplias oportunidades para trabajar como API Gateway, configurar dinámicamente en función de los recursos de CRD, así como los servicios básicos de Kubernetes.
Con mayores requisitos para métodos de equilibrio 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 existido durante un par de años, pero todavía parece demasiado joven y solo tiene características básicas agregadas sobre Envoy. Si hay requisitos para la presencia / inclusión de WAF antes de la aplicación, debe prestar atención al mismo Ingress de Kubernetes o HAProxy.
Y las características más ricas son los productos creados sobre la base de Envoy, especialmente Istio. Parece ser una solución compleja que "puede hacer cualquier cosa", lo que, sin embargo, también significa un umbral de entrada significativamente mayor para la configuración / lanzamiento / administración que otras soluciones.
Hemos elegido y todavía utilizamos Kubernetes Ingress, que cubre el 80-90% de las necesidades, como el controlador estándar. Es bastante confiable, fácil de configurar, expandir. En el caso general, en ausencia de requisitos específicos, debería adaptarse a la mayoría de los clústeres / aplicaciones. De los mismos productos versátiles y relativamente simples, se pueden recomendar Traefik y HAProxy.
PS
Lea también en nuestro blog: