Pruebas de rendimiento de NGINX Ingress Controller y Red Hat OpenShift Router

Amir RawdatIngeniero de soluciones

Red Hat OpenShift Container Platform (OCP) es una de las plataformas de Kubernetes gestionadas más populares y, al igual que sus competidores, OCP incluye herramientas predeterminadas de gestión del tráfico para ayudar a los usuarios a empezar rápidamente. El OCP Router —basado en HAProxy— es el punto de entrada predeterminado de los clústeres de OCP. Puede equilibrar la carga del tráfico HTTP y WebSocket, admite la terminación TLS y el uso de TLS entre el Router y las instancias de la aplicación, y puede equilibrar la carga de las conexiones TLS en modo passthrough.

Los clientes suelen preguntarnos: «¿Por qué debería usar NGINX Ingress Controller en OpenShift si el Router está disponible de forma gratuita?». En Por qué necesita un controlador de Ingress de nivel empresarial en OpenShift, Max Mortillaro, de GigaOm y autor invitado del blog, expone algunas razones cualitativas por las que podría interesarle usar NGINX Ingress Controller: gestión avanzada del tráfico, facilidad de uso, validación de JWT e integración con WAF. Pero también es importante responder a esa pregunta desde un punto de vista cuantitativo. Por eso, realizamos pruebas de rendimiento del Router y de NGINX Ingress Controller basado en NGINX Plus (nginxinc/kubernetes-ingress) en el entorno OCP, mediante un despliegue dinámico en el que aumentamos y redujimos el número de servidores ascendentes (backend) durante la prueba.

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

• Factor 1: resultados de latencia para implementaciones dinámicasConsideramos que la métrica más eficaz para medir la experiencia del usuario final en una implementación dinámica es la distribución de percentiles de latencia. Cuanta más latencia añada un sistema, más se verá afectada la experiencia del usuario. También hemos comprobado que, para obtener una imagen fiel de la experiencia del usuario, deben incluirse las latencias de los percentiles superiores de la distribución. Para obtener una explicación detallada, consulte la sección Resultados de rendimiento de NGINX y HAProxy: análisis de la experiencia del usuario en la nube en nuestro blog.
• Factor 2: Tiempos de espera y erroresCuando un sistema sometido a pruebas provoca latencia en un despliegue dinámico, normalmente se debe a que tiene dificultades para gestionar las recargas dinámicas, lo que ocasiona tiempos de espera o errores.

Resultados de las pruebas de rendimiento

Vayamos directamente a la parte interesante y revisemos los resultados. A continuación se ofrecen detalles sobre la topología y el método de las pruebas.

Como se ha explicado anteriormente, tenemos en cuenta dos factores al evaluar el rendimiento: la latencia y los tiempos de espera agotados/errores.

Factor 1: distribución de percentiles de latencia

Como muestra el siguiente gráfico, NGINX Ingress Controller añadió una latencia insignificante durante toda la prueba, con un máximo inferior a 700 ms en el percentil 99,999. En cambio, OCP Router añadió latencia ya en percentiles bastante bajos, y esta aumentó exponencialmente hasta estabilizarse en algo más de 25.000 ms (25 segundos) en el percentil 99,99. Esto demuestra que, cuando está sometido a carga y se aplican cambios frecuentes en el entorno del clúster, el Router puede provocar una mala experiencia de usuario.

Factor 2: Tiempos de espera y errores

La latencia observada anteriormente puede atribuirse a tiempos de espera agotados y errores: OCP Router registró 260 tiempos de espera de conexión agotados y 85 errores de lectura de socket, mientras que NGINX Ingress Controller no registró ninguno. Como hemos visto en otras pruebas de rendimiento (consulte Pruebas de rendimiento de los controladores de entrada NGINX en un entorno dinámico de nube de Kubernetes), los tiempos de espera agotados y los errores de Router se deben a la forma en que HAproxy gestiona las recargas dinámicas. NGINX Ingress Controller, basado en NGINX Plus, no provoca tiempos de espera agotados ni errores porque utiliza la API de NGINX Plus para actualizar dinámicamente la configuración de NGINX cuando cambian los endpoints.

Configuración y metodología de las pruebas

Topología de las pruebas

Ejecutamos las mismas pruebas tanto en el controlador de entrada NGINX como en el router de OpenShift, que actuaron como sistema sometido a 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 independiente al despliegue del backend.

El cliente estaba alojado en una máquina independiente con CentOS 7, ubicada en la misma red LAN que el clúster de OpenShift.

El SUT y el despliegue del backend se ejecutaron en un clúster de OCP alojado en VMware vSphere 6.7.0.45100.

Para el cifrado TLS, utilizamos RSA con una clave de 2048 bits y secreto perfecto hacia adelante.

Cada respuesta de la aplicación backend contenía aproximadamente 1 KB de metadatos básicos del servidor, junto con el código de estado HTTP 200 OK.

Metodología de las pruebas

Implementación del cliente

Mediante wrk2 (versión 4.0.0), ejecutamos el siguiente script en la máquina cliente durante 60 segundos (configurados con la opción -d) y con 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://ingress-url:443/

Software utilizado en el SUT

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

Despliegue del backend

Realizamos pruebas con un despliegue dinámico de la aplicación backend, utilizando el siguiente script para aumentar y reducir periódicamente el número de réplicas del backend. Esto simula un entorno dinámico de OpenShift y permite medir la eficacia con la que el controlador de entrada NGINX o el enrutador de OCP se adaptan a los cambios en los endpoints.

while [ 1 -eq 1 ]
do
  oc scale deployment nginx-backend --replicas=4  
  sleep 10 
  oc scale deployment nginx-backend --replicas=2
  sleep 10
done

Conclusión

La mayoría de las empresas que adoptan metodologías de microservicios implementan nuevos desarrollos a través de sus canalizaciones de CI/CD con más frecuencia que nunca. Por este motivo, es fundamental utilizar un plano de datos que evolucione junto con estas nuevas metodologías en cuanto a capacidad y rendimiento, sin perjudicar la experiencia del usuario final. Ofrecer una experiencia óptima al usuario final implica mantener sistemáticamente una baja latencia en todas las conexiones de los clientes, sean cuales sean las circunstancias.

Según los resultados de rendimiento, NGINX Ingress Controller ofrece una experiencia óptima al usuario final en entornos en contenedores donde existe una gran necesidad de iterar y mejorar el desarrollo.

Para empezar, descargue una versión de prueba gratuita de NGINX Ingress Controller y descubra cómo realizar la implementación con NGINX Ingress Operator.

Sobre el autor

Amir RawdatIngeniero de soluciones

Más artículos de Amir Rawdat