Bereitstellen des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Bei NGINX suchen wir ständig nach Möglichkeiten, Ihnen zu helfen, das Beste aus unserer Software herauszuholen. Eine wichtige Ressource, die wir bereitstellen, sind unsere Lösungsübersichten und Größenleitfäden . Indem wir die Leistung, die Sie bei verschiedenen Rechenleistungsstufen erwarten können, empirisch testen, helfen wir Ihnen, die Anwendungsbereitstellungsleistung mit der Infrastruktur, die Sie bereits haben, zu maximieren und die genauen Betriebskosten für die Leistung und den Umfang zu ermitteln, auf die Sie sich vorbereiten.

Wir haben vor Kurzem die Lösungsübersicht zum NGINX Ingress Controller mit Größenrichtlinien für den Amazon Elastic Kubernetes Service (EKS) aktualisiert. In der Kurzbeschreibung wird die Leistung beschrieben, die Sie mit dem NGINX Ingress Controller auf verschiedenen Instanztypen in Amazon EKS erwarten können, zusammen mit den geschätzten monatlichen Gesamtbetriebskosten (TCO). In diesem Blog erklären wir, wie wir auf diese Zahlen gekommen sind, und bieten alle Informationen, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Topologie

Das folgende Diagramm zeigt die für den Test verwendete Topologie.

• Der Administrator ist der Benutzer, der die Tests durchführt, indem er die in den folgenden Abschnitten angegebenen Befehle ausführt.
• Amazon ECR (Elastic Container Registry) hostet das offizielle NGINX Plus Ingress Controller Docker-Image, das beim Testen verwendet wurde. Siehe Bereitstellen des NGINX Plus Ingress Controller .
• Amazon EC2 (Elastic Compute Cloud) hostet das Image c5n.9xlarge, auf dem wrk ausgeführt wird und die Anforderungen generiert. Siehe Testmethodik .
• Amazon EKS (Elastic Kubernetes Service) hostet die c5n.9xlarge-Images für den NGINX Plus Ingress Controller und die Backend-Anwendung. Siehe „Erstellen des Amazon EKS-Clusters“ .
• NGINX Plus Ingress Controller leitet die von wrk generierten Anfragen per Proxy an die Backend-Anwendung weiter und gibt die Antworten der Anwendung zurück. Siehe Bereitstellen des NGINX Plus Ingress Controller .
• Die Backend-Anwendung antwortet auf die von NGINX weitergeleiteten Anfragen. Siehe Bereitstellen der Backend-Pods .

Erstellen des Amazon EKS-Clusters

Führen Sie vor der Bereitstellung des EKS-Clusters diese Schritte auf dem lokalen Computer aus, der im Diagramm durch das Admin- Symbol dargestellt wird:

1. Laden Sie eksctl herunter, die offizielle Befehlszeilenschnittstelle für Amazon EKS. Wenn Sie eksctl bereits auf Ihrem Computer installiert haben, aktualisieren Sie es unbedingt auf die neueste Version.
2. Fügen Sie der Datei ${HOME}/.aws/credentials die entsprechenden AWS-Administratoranmeldeinformationen hinzu.
3. Laden Sie die YAML-Dateien für diesen Blog aus unserem Gist-Repository herunter.
4. Laden Sie rbac.yaml (oder ap-rbac.yaml , wenn Sie NGINX App Protect verwenden) aus dem NGINX Ingress Controller- Repository auf GitHub herunter.

Um den EKS-Cluster bereitzustellen, führen Sie den folgenden eksctl -Befehl auf dem lokalen Computer aus. (Das Flag --nodes wird weggelassen, da der Befehl standardmäßig die beiden für den Test erforderlichen Knoten erstellt: einen für den NGINX Plus Ingress Controller und einen für die grundlegende Backend-Anwendung.)

Notiz: Sie können den EKS-Cluster in jeder anderen Region als us-west-1 bereitstellen. Das Abonnieren des NGINX Plus Ingress Controller-Image im Amazon Marketplace für Container (siehe nächsten Abschnitt ) wird in dieser Region nicht unterstützt.

# eksctl create cluster --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/Pfad/zum/öffentlichen Schlüssel

Führen Sie diesen Befehl aus, um über SSH eine Verbindung zu einem Clusterknoten herzustellen. Während des Tests müssen Sie eine Verbindung mit dem NGINX Plus Ingress Controller-Knoten herstellen, um den Befehl htop auszuführen und zu überprüfen, ob die Last vom Wrk -Client ausreicht, um die CPU-Auslastung auf dem Knoten auf 100 % zu bringen.

# ssh -i /Pfad/zum/privaten Schlüssel ec2-user@< öffentliche IP-Adresse des EKS-Knotens >

Bereitstellen des NGINX Plus Ingress Controllers

Die Bereitstellung des NGINX Plus Ingress Controllers auf Amazon EKS ist jetzt einfacher als je zuvor.

1. Erstellen Sie einen OIDC-Identitätsanbieter (IdP) für Ihren EKS-Cluster.

   # eksctl utils associate-iam-oidc-provider --region=< eks-cluster-region > --cluster=< eks-cluster-name > --approve
   

2. Erstellen Sie iamserviceaccount , das standardmäßig gepaarte IAM-Rollen- und Dienstkonto (IRSA) für EKS, und fügen Sie die IAM-Richtlinie AWSMarketplaceMeteringRegisterUsage an, um die Nutzung des NGINX Plus Ingress Controller-Image zu überwachen und die Bereitstellung zu autorisieren. Dieser Befehl erstellt automatisch ein Dienstkonto mit einer Annotation, die auf iamserviceaccount verweist.

   # eksctl erstelle iamserviceaccount --name <Dienstkontoname> --namespace nginx-ingress --cluster <EKS-Clustername> --region <EKS-Cluster-Region> --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve
   

3. Bearbeiten Sie in der YAML-Datei für RBAC den Wert des Namens im Feld „Betreff“ , sodass er mit dem Dienstkontonamen übereinstimmt, den Sie im vorherigen Schritt festgelegt haben. Dies steht in Zeile 104 in rbac.yaml und Zeile 23 in ap-rbac.yaml . Bearbeiten Sie bei Bedarf auch den Wert des Namespace (Zeile 105 oder Zeile 24), aber der obige Befehl verwendet den Standardwert nginx-ingress .

4. Wenden Sie die YAML-Datei an (ersetzen Sie ap-rbac.yaml entsprechend).

   # kubectl apply –f rbac.yaml
   

5. Installieren Sie die Docker- Clientsoftware auf dem lokalen Computer.

6. Abonnieren Sie die Liste des NGINX Plus Ingress Controller (Premium Edition) im Amazon Marketplace für Container .

7. Authentifizieren Sie Ihren Docker-Client mit dem Amazon ECR, der das Docker-Image des NGINX Plus Ingress Controller hostet.

8. Bearbeiten Sie die folgenden Werte in nginx-ingress.yaml :

   • kubernetes.io/hostname im Feld nodeSelector (Zeile 23) – Die Bezeichnung für den NGINX Plus Ingress Controller-Knoten im EKS-Cluster, abgerufen über den Befehl kubectl get nodes --show-labels
   • serviceAccountName (Zeile 24) – Der Name des iamserviceaccount IRSA, angegeben als service-account-name in Schritt 2 .
   • Bild im Containerfeld (Zeile 26) – Der Speicherort des NGINX Plus Ingress Controller Docker-Image in Amazon ECR

9. Wenden Sie das YAML-Manifest an:

   # kubectl apply –f nginx-ingress.yaml
   

Bereitstellen der Backend-Pods

Führen Sie die folgenden Schritte aus, um die Backend-Anwendung bereitzustellen:

1. Bearbeiten Sie in backend-deployment.yaml den Wert von kubernetes.io/hostname im Feld „nodeSelector“ (Zeile 15) und ersetzen Sie ihn durch die Bezeichnung, die Sie mit dem Befehl „kubectl get nodes --show-labels“ erhalten haben.

2. Wenden Sie das YAML-Manifest an:

   # kubectl apply –f backend-deployment.yaml
   

3. Skalieren Sie die Backend-Anwendung auf bis zu drei Replikate, ausreichend, um die durch wrk erzeugte Last zu bewältigen:

   # kubectl-Skalierungsbereitstellung web-server-payload --replicas=3
   

Testmethodik

Führen Sie den folgenden wrk -Befehl auf dem in Amazon EC2 gehosteten Client c5n.9xlarge AMI aus und passen Sie die Werte nach Bedarf an, damit die CPU-Auslastung der NGINX Plus Ingress Controller-Instanz bei jedem Testlauf 100 % erreicht:

# wrk -t < Anzahl Threads > -c < Anzahl Verbindungen > -d 180s http[s]://< Adresse des NGINX-Plus-Ingress-Controllers >

• Die Option –c gibt die Anzahl der zu erstellenden TCP-Verbindungen an. Stellen Sie diese Option nach Bedarf ein, um eine CPU-Auslastung von 100 % (bis zu 500 Verbindungen) zu erreichen.
• Die Option –d gibt an, wie lange Datenverkehr generiert werden soll (die Dauer jedes Testlaufs). Stellen Sie diese Option auf 180 Sekunden (3 Minuten) ein.
• Die Option –t gibt die Anzahl der zu erstellenden Threads an. Stellen Sie diese Option nach Bedarf ein, um eine CPU-Auslastung von 100 % zu erreichen, bis zu 16 Threads (einer für jede CPU, die während des Testlaufs auf dem Client verwendet wird).

Wir haben die im Juli 2021 auf GitHub verfügbare Version von wrk verwendet und empfehlen, bei der Reproduktion der Tests die aktuelle Version zu verwenden.

Führen Sie Tests durch, um zwei Leistungsmetriken zu erfassen:

• Anfragen pro Sekunde (RPS) – Die Anzahl der Anfragen, die NGINX Plus Ingress Controller pro Sekunde verarbeiten kann, gemittelt über einen festen Zeitraum. Verwenden Sie in diesem Fall das Schema http:// im wrk -Befehl.

  NGINX Plus Ingress Controller akzeptiert die Anforderungen für eine 1-KB -Datei (statischer Inhalt) und verteilt die Last auf die Back-End-Anwendungs-Pods. Die Datei hat ungefähr die Größe einer kleinen CSS- oder JavaScript-Datei oder eines sehr kleinen Bildes.

• SSL/TLS-Transaktionen pro Sekunde (TPS) – Die Anzahl der neuen HTTPS-Verbindungen, die NGINX Plus Ingress Controller pro Sekunde herstellen und bereitstellen kann. Verwenden Sie in diesem Fall das Schema https:// im wrk -Befehl. Verwenden Sie RSA mit einer Schlüsselgröße von 2048 Bit und Perfect Forward Secrecy. Die SSL-Verschlüsselung lautet ECDHE-RSA-AES256-GCM-SHA384 .

  Der Client sendet eine Reihe von HTTPS-Anfragen, jeweils über eine neue Verbindung. Der Client und der NGINX Plus Ingress Controller führen einen TLS-Handshake durch, um eine sichere Verbindung herzustellen. Anschließend analysiert der NGINX Plus Ingress Controller die Anforderung und gibt eine 0-KB -Antwort zurück. Die Verbindung wird geschlossen, nachdem die Anforderung erfüllt wurde.

Wie unter „Erstellen des Amazon EKS-Clusters“ erwähnt, können Sie der Einfachheit halber den NGINX Plus Ingress Controller bei jedem Testlauf auf einer c5n.9xlarge-Instance ausführen. Um zu steuern, wie viele CPUs während jedes Testlaufs verfügbar sind (von 1 bis 36, wie in der Tabelle in der Leistungsanalyse angegeben), legen Sie den Parameter auf die Direktive worker_processes fest.

Verwendete Software

Für die Tests haben wir folgende Software verwendet:

• Der Client-Computer, auf dem wrk ausgeführt wird, hat den Datenverkehr generiert, der vom Ingress Controller weitergeleitet wurde. Wir haben die Version von wrk verwendet, die im Juli 2021 auf GitHub verfügbar war, und empfehlen, bei der Reproduktion der Tests die aktuelle Version zu verwenden.
• NGINX Plus Ingress Controller Version 1.11.0
• Auf allen drei Maschinen lief Amazon Linux 2 LTS mit OpenSSL 1.0.2k–fips

Leistungsanalyse

Wie oben erwähnt, haben wir den NGINX Plus Ingress Controller bei jedem Testlauf auf einer c5n.9xlarge-Instanz ausgeführt und dabei die Direktive worker_processes verwendet, um zu steuern, wie viele CPUs verwendet wurden. In der folgenden Tabelle geben wir den Instanztyp in der c5n-Familie an, der jede CPU-Anzahl unterstützt, zusammen mit den monatlichen Gesamtbetriebskosten für diesen Instanztyp.

Die Tabelle gibt die Anzahl der RPS und SSL TPS an, die mit unterschiedlichen für den NGINX Plus Ingress Controller verfügbaren CPU-Zahlen erreicht wurden, aus den unter Testmethodik beschriebenen Tests.

Beachten Sie, dass die RPS bei einer größeren Anzahl von CPUs nicht linear ansteigen. Tatsächlich nimmt die prozentuale Verbesserung tendenziell ab, wenn die Anzahl der CPUs zunimmt. Ab 16 Kernen sinkt die Verbesserungsrate sogar noch weiter, da c5n.9xlarge-Instanzen mit Hyperthreading ausgestattet sind und über 18 Kerne und 2 Threads pro Kern verfügen, also insgesamt bis zu 36 CPUs. Hyperthreading verbessert die RPS-Anzahl nur geringfügig.

Auch die Beziehung zwischen SSL TPS und der Anzahl der CPUs ist nicht ganz linear, fällt aber nicht so drastisch ab, bis wir über 16 CPUs skalieren. Hyperthreading verbessert die Leistung CPU-gebundener, parallelisierbarer Vorgänge wie TLS-Handshakes. Aus diesem Grund verbessert sich die Leistung von SSL TPS, selbst wenn wir über 18 CPUs skalieren.

Abschluss

Wir haben Bereitstellungsdetails bereitgestellt, mit denen Sie die erwartete Leistung des in Amazon EKS ausgeführten NGINX Plus Ingress Controller ermitteln können. Sie können es verwenden, um andere Familien von EKS-Instanzen zu testen und eine kostengünstige Lösung bereitzustellen, die Ihre Leistungs- und Skalierungsanforderungen für Produktionsworkloads in Kubernetes erfüllt.

Unsere Ergebnisse für HTTP RPS zeigen, dass die prozentuale Leistungsverbesserung abnimmt, wenn wir die Anzahl der CPUs verdoppeln, und sich bei etwa 300.000 RPS einpendelt. Die Ergebnisse für SSL TPS zeigen, dass die Leistung nahezu linear zunimmt, wenn wir die Anzahl der CPUs verdoppeln, selbst wenn wir Hyperthreading starten (mit zwei Threads pro Kern), da TLS-Handshakes CPU-gebunden sind.

Schauen Sie sich die Lösungsübersicht an und testen Sie die Leistung des NGINX Plus Ingress Controller selbst – legen Sie noch heute los !

Um den NGINX Ingress Controller mit NGINX Open Source auszuprobieren, können Sie den Quellcode abrufen oder einen vorgefertigten Container von DockerHub herunterladen.