Leistungstests für NGINX Ingress Controller und Red Hat OpenShift Router

Red Hat OpenShift Container Platform (OCP) ist eine der beliebtesten verwalteten Kubernetes-Plattformen und wie seine Konkurrenten umfasst OCP standardmäßige Tools zur Verkehrsverwaltung, um Benutzern einen schnellen Einstieg zu ermöglichen. Der OCP-Router – basierend auf HAProxy – ist der Standardeinstiegspunkt für OCP-Cluster. Es kann den HTTP- und WebSocket-Verkehr ausgleichen, unterstützt TLS-Terminierung und TLS zwischen dem Router und den Anwendungsinstanzen und kann den Lastenausgleich für TLS-Verbindungen im Passthrough-Modus durchführen.

Kunden fragen uns oft: „Warum sollte ich den NGINX Ingress Controller in OpenShift verwenden, wenn der Router kostenlos verfügbar ist?“ In „Warum Sie einen Ingress Controller der Enterprise-Klasse für OpenShift benötigen “ nennt Gastblogger Max Mortillaro von GigaOm einige qualitative Gründe, warum Sie möglicherweise den NGINX Ingress Controller verwenden möchten: erweitertes Verkehrsmanagement, Benutzerfreundlichkeit, JWT-Validierung und WAF-Integration. Es ist aber auch wichtig, diese Frage aus quantitativer Sicht zu beantworten. Deshalb haben wir die Leistung des Routers und des auf NGINX Plus basierenden NGINX Ingress Controllers ( nginxinc/kubernetes-ingress ) in der OCP-Umgebung in einer dynamischen Bereitstellung getestet, bei der wir die Anzahl der Upstream-Server (Backend-Server) während des Tests nach oben und unten skaliert haben.

Bei der Durchführung von Leistungstests berücksichtigen wir zwei Faktoren, um die Leistung der Tools zu beurteilen:

• Faktor 1: Latenzergebnisse für dynamische Bereitstellungen

  Unserer Meinung nach ist die Latenz-Perzentilverteilung die effektivste Messgröße zur Messung der Endbenutzererfahrung bei einer dynamischen Bereitstellung. Je mehr Latenz ein System hinzufügt, desto stärker wird das Benutzererlebnis beeinträchtigt. Wir haben außerdem festgestellt, dass zur Darstellung eines wahren Bilds der Benutzererfahrung Latenzen in den oberen Perzentilen der Verteilung einbezogen werden müssen. Eine ausführliche Erklärung finden Sie im Abschnitt „Leistungsergebnisse“ von NGINX und HAProxy: Testen der Benutzererfahrung in der Cloud in unserem Blog.

• Faktor 2: Zeitüberschreitungen und Fehler

  Wenn ein zu testendes System bei einer dynamischen Bereitstellung zu Latenzen führt, liegt dies normalerweise daran, dass das System Probleme mit der Verarbeitung dynamischer Neuladungen hat und es zu Timeouts oder Fehlern kommt.

Ergebnisse der Leistungstests

Kommen wir direkt zum interessanten Teil und überprüfen die Ergebnisse. Details zur Testtopologie und -methode folgen.

Wie oben erläutert, berücksichtigen wir bei der Leistungsbewertung zwei Faktoren: Latenz und Timeouts/Fehler.

Faktor 1: Latenz-Perzentilverteilung

Wie das folgende Diagramm zeigt, fügte NGINX Ingress Controller während des gesamten Tests nur eine vernachlässigbare Latenz hinzu und erreichte beim 99,999. Perzentil ein Maximum von weniger als 700 ms. Im Gegensatz dazu fügte der OCP-Router Latenz bei ziemlich niedrigen Perzentilen hinzu und die Latenz stieg exponentiell an, bis sie beim 99,99. Perzentil bei etwas über 25.000 ms (25 Sekunden) ein Plateau erreichte. Dies zeigt, dass der Router bei hoher Belastung und häufigen Änderungen in der Clusterumgebung zu einer negativen Benutzererfahrung führen kann.

Faktor 2: Zeitüberschreitungen und Fehler

Die oben beobachtete Latenz kann auf Timeouts und Fehler zurückgeführt werden: Der OCP-Router erzeugte 260 Verbindungstimeouts und 85 Read-Socket-Fehler, während der NGINX Ingress Controller keine erzeugte. Wie wir bei anderen Leistungstests gesehen haben (siehe Leistungstests von NGINX-Ingress-Controllern in einer dynamischen Kubernetes-Cloud-Umgebung ), werden die Timeouts und Fehler des Routers durch die Art und Weise verursacht, wie HAproxy dynamische Neuladungen verarbeitet. Der auf NGINX Plus basierende NGINX Ingress Controller verursacht keine Timeouts oder Fehler, da er die NGINX Plus-API verwendet, um die NGINX-Konfiguration dynamisch zu aktualisieren, wenn sich Endpunkte ändern.

Testaufbau und -methodik

Testen der Topologie

Wir haben sowohl auf dem NGINX Ingress Controller als auch auf dem OpenShift Router als zu testendes System (SUT) dieselben Tests ausgeführt. Das SUT beendete TLS 1.3-Verbindungen vom Client und leitete die Client-Anforderung über eine separate Verbindung an die Back-End-Bereitstellung weiter.

Der Client wurde auf einer separaten Maschine mit CentOS 7 gehostet, die sich im selben LAN wie der OpenShift-Cluster befand.

Die SUT- und Backend-Bereitstellung wurde in einem OCP-Cluster ausgeführt, der auf VMware vSphere 6.7.0.45100 gehostet wurde.

Für die TLS-Verschlüsselung haben wir RSA mit einer Schlüsselgröße von 2048 Bit und Perfect Forward Secrecy verwendet.

Jede Antwort der Backend-Anwendung bestand aus etwa 1 KB grundlegender Server-Metadaten sowie der200 OK HTTP-Statuscode.

Testmethodik

Clientbereitstellung

Mit wrk2 (Version 4.0.0) haben wir das folgende Skript auf dem Client-Computer ausgeführt und den Test 60 Sekunden lang (eingestellt mit der Option -d ) bei einem konstanten Durchsatz von 1000 Anfragen pro Sekunde (RPS, eingestellt mit der Option -R ) ausgeführt:

./wrk -t 2 -c 50 -d 60s -R 1000 -L https:// Eingangs-URL :443/

Verwendete SUT-Software

• OpenShift-Plattformversion 4.8, die standardmäßig den HAProxy-basierten Router enthält
• NGINX Ingress Controller Version 1.11.0 (NGINX Plus R22)

Backend-Bereitstellung

Wir haben Testläufe mit einer dynamischen Bereitstellung der Back-End-Anwendung durchgeführt und dabei das folgende Skript verwendet, um die Anzahl der Back-End-Replikate regelmäßig nach oben und unten zu skalieren. Dies emuliert eine dynamische OpenShift-Umgebung und misst, wie effektiv sich der NGINX Ingress Controller oder OCP-Router an Endpunktänderungen anpasst.

während [ 1 -eq 1 ]
machen
oc scale deployment nginx-backend --replicas=4 
sleep 10 
oc scale deployment nginx-backend --replicas=2
sleep 10
fertig

Abschluss

Die meisten Unternehmen, die Microservices-Methoden einführen, bringen neue Entwicklungen häufiger als je zuvor durch ihre CI/CD-Pipelines. Aus diesem Grund ist es wichtig, dass Sie eine Datenebene nutzen, deren Kapazität und Leistung mit diesen neuen Methoden wächst, ohne das Endbenutzererlebnis zu beeinträchtigen. Um ein optimales Endbenutzererlebnis zu bieten, muss für alle Clientverbindungen unter allen Umständen durchgängig eine geringe Latenz gewährleistet sein.

Basierend auf den Leistungsergebnissen bietet der NGINX Ingress Controller das optimale Endbenutzererlebnis in Containerumgebungen, in denen ein hoher Bedarf an Iteration und Verbesserung der Entwicklung besteht.

Laden Sie zunächst eine kostenlose Testversion des NGINX Ingress Controller herunter und erfahren Sie, wie Sie die Bereitstellung mit dem NGINX Ingress Operator durchführen.