Pruebas de rendimiento del controlador de ingreso NGINX y el enrutador Red Hat OpenShift

Red Hat OpenShift Container Platform (OCP) es una de las plataformas de Kubernetes administradas más populares y, al igual que sus competidores, OCP incluye herramientas de gestión de tráfico predeterminadas para ayudar a los usuarios a comenzar rápidamente. El enrutador OCP , basado en HAProxy , es el punto de entrada predeterminado para los clústeres OCP. Puede equilibrar la carga del tráfico HTTP y WebSocket, admite la terminación TLS y TLS entre el enrutador y las instancias de la aplicação , y puede equilibrar la carga de las conexiones TLS en un modo de paso a través.

Los clientes a menudo nos preguntan: "¿Por qué debería usar NGINX Ingress Controller en OpenShift cuando el enrutador está disponible de forma gratuita?" En Por qué necesita un controlador de ingreso de nivel empresarial en OpenShift , el bloguero invitado Max Mortillaro de GigaOm comparte algunas razones cualitativas por las que podría querer usar el controlador de ingreso NGINX : administración avanzada del tráfico, facilidad de uso, validación JWT e integración WAF. Pero también es importante responder esa pregunta desde un punto de vista cuantitativo, por eso probamos el rendimiento del enrutador y del controlador de ingreso NGINX basado en NGINX Plus ( nginxinc/kubernetes-ingress ) en el entorno OCP, en una implementación dinámica en la que escalamos la cantidad de servidores ascendentes (backend) hacia arriba y hacia abajo durante la prueba.

Cuando realizamos pruebas de rendimiento, observamos dos factores para evaluar el rendimiento de las herramientas:

• Factor 1: Resultados de latencia para implementaciones dinámicas

  Descubrimos que la métrica más eficaz para medir la experiencia del usuario final en una implementación dinámica es la distribución del percentil de latencia. Cuanto más latencia agregue un sistema, más se verá afectada la experiencia del usuario. También descubrimos que para obtener una imagen real de la experiencia del usuario, es necesario incluir las latencias en los percentiles superiores de la distribución; para obtener una explicación detallada, consulte la sección Resultados de rendimiento de NGINX y HAProxy: Probando la experiencia de usuario en la nube en nuestro blog.

• Factor 2: Tiempos de espera y errores

  Cuando un sistema bajo prueba provoca latencia en una implementación dinámica, generalmente se debe a que el sistema tiene problemas para gestionar recargas dinámicas, experimenta tiempos de espera o errores.

Resultados de las pruebas de rendimiento

Vayamos directamente a la parte interesante y repasemos los resultados. A continuación se detallan la topología y el método de prueba .

Como se discutió anteriormente, consideramos dos factores al evaluar el rendimiento: latencia y tiempos de espera/errores.

Factor 1: Distribución de percentiles de latencia

Como lo ilustra el siguiente gráfico, NGINX Ingress Controller agregó una latencia insignificante durante toda la prueba, alcanzando un máximo de menos de 700 ms en el percentil 99,999. Por el contrario, el enrutador OCP agregó latencia en percentiles bastante bajos, y la latencia aumentó exponencialmente hasta que se estabilizó en un poco más de 25 000 ms (25 segundos) en el percentil 99,99. Esto demuestra que, cuando está bajo carga y se aplican cambios con frecuencia en el entorno del clúster, el enrutador puede generar una mala experiencia de usuario.

Factor 2: Tiempos de espera y errores

La latencia observada anteriormente se puede atribuir a tiempos de espera y errores: el enrutador OCP produjo 260 tiempos de espera de conexión y 85 errores de socket de lectura, mientras que el controlador de ingreso NGINX no produjo ninguno. Como hemos visto con otras pruebas de rendimiento (consulte Pruebas de rendimiento de controladores de ingreso NGINX en un entorno de nube Kubernetes dinámico ), los tiempos de espera y los errores del enrutador se deben a la forma en que HAproxy maneja las recargas dinámicas. El controlador de ingreso NGINX basado en NGINX Plus no causa tiempos de espera ni errores porque utiliza la API NGINX Plus para actualizar dinámicamente la configuración de NGINX cuando cambian los puntos finales.

Configuración y metodología de pruebas

Topología de prueba

Ejecutamos las mismas pruebas tanto en el controlador de ingreso NGINX como en el enrutador OpenShift como sistema bajo prueba (SUT). El SUT finalizó las conexiones TLS 1.3 del cliente y reenvió la solicitud del cliente a través de una conexión separada a la implementación del backend.

El cliente estaba alojado en una máquina separada que ejecutaba CentOS 7, ubicada en la misma LAN que el clúster OpenShift.

La implementación de SUT y backend se ejecutó en un clúster OCP alojado en VMware vSphere 6.7.0.45100.

Para el cifrado TLS, utilizamos RSA con un tamaño de clave de 2048 bits y Perfect Forward Secrecy.

Cada respuesta de la aplicação backend consistió en aproximadamente 1 KB de metadatos básicos del servidor, junto con el 200 DE ACUERDO Código de estado HTTP.

Metodología de pruebas

Implementación del cliente

Usando wrk2 (versión 4.0.0), ejecutamos el siguiente script en la máquina cliente, ejecutando la prueba durante 60 segundos (configurado con la opción -d ) a un rendimiento constante de 1000 solicitudes por segundo (RPS, configurado con la opción -R ):

./wrk -t 2 -c 50 -d 60s -R 1000 -L https:// url de entrada : 443/

Software SUT utilizado

• Versión 4.8 de OpenShift Platform, que incluye el enrutador basado en HAProxy de forma predeterminada
• Controlador de ingreso NGINX versión 1.11.0 (NGINX Plus R22)

Implementación de backend

Realizamos ejecuciones de prueba con una implementación dinámica de la aplicação backend, utilizando el siguiente script para escalar la cantidad de réplicas backend hacia arriba y hacia abajo periódicamente. Esto emula un entorno OpenShift dinámico y mide la eficacia con la que el controlador de ingreso NGINX o el enrutador OCP se adaptan a los cambios de los puntos finales.

mientras [ 1 -eq 1 ]
hacer
Implementación a escala oc nginx-backend --replicas=4
dormir 10
Implementación a escala oc nginx-backend --replicas=2
dormir 10
Listo

CONCLUSIÓN

La mayoría de las empresas que adoptan metodologías de microservicios están impulsando nuevos desarrollos a través de sus canales de CI/CD con una frecuencia más alta que nunca. Por este motivo, es fundamental aprovechar un plano de datos que crezca con estas nuevas metodologías en capacidad y rendimiento, sin interrumpir la experiencia del usuario final. Ofrecer una experiencia óptima al usuario final implica ofrecer constantemente una latencia baja para todas las conexiones del cliente, bajo todas las circunstancias.

Según los resultados de rendimiento, el controlador de ingreso NGINX ofrece una experiencia de usuario final óptima en entornos en contenedores donde la necesidad de iterar y mejorar el desarrollo es alta.

Para comenzar, descargue una prueba gratuita del controlador de ingreso NGINX y descubra cómo implementarlo utilizando el operador de ingreso NGINX .