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

Amir RawdatLösungsingenieur

Bei NGINX suchen wir ständig nach Möglichkeiten, Ihnen dabei zu helfen, unsere Software optimal zu nutzen. Unsere Lösungsbeschreibungen und Dimensionierungsleitfäden sind eine wichtige Ressource, die wir Ihnen zur Verfügung stellen. Durch empirische Tests der Leistung, die Sie bei unterschiedlicher Rechenleistung erwarten können, helfen wir Ihnen, die Performance der Anwendungsbereitstellung mit Ihrer vorhandenen Infrastruktur zu maximieren und die Betriebskosten für die angestrebte Leistung und Skalierung präzise zu ermitteln.

Wir haben kürzlich die Lösungsübersicht zum NGINX Ingress Controller um Dimensionierungsrichtlinien für Amazon Elastic Kubernetes Service (EKS) ergänzt. Die Übersicht beschreibt die Leistung, die Sie mit dem NGINX Ingress Controller auf verschiedenen Instanztypen in Amazon EKS erzielen können, sowie die geschätzten monatlichen Gesamtbetriebskosten (TCO). In diesem Blogbeitrag erläutern wir, wie wir diese Zahlen ermittelt haben, und stellen Ihnen alle Informationen bereit, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Topologie

Das folgende Diagramm zeigt die für die Tests verwendete Topologie.

• Admin 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 Docker-Image des NGINX Plus Ingress Controllers, das für die Tests verwendet wird. Siehe „Bereitstellen des NGINX Plus Ingress Controllers“.
• Amazon EC2 (Elastic Compute Cloud) hostet das c5n.9xlarge-Image, auf dem wrk ausgeführt wird und die Anfragen 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 an die Backend-Anwendung weiter und gibt die Antworten der Anwendung zurück. Siehe Bereitstellen des NGINX Plus Ingress Controllers.
• 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 die folgenden Schritte auf dem lokalen Rechner aus, der im Diagramm durch das Symbol „Admin“ dargestellt wird:

1. Laden Sie eksctl, die offizielle Befehlszeilenschnittstelle für Amazon EKS, herunter. Wenn Sie eksctl bereits auf Ihrem Rechner installiert haben, aktualisieren Sie es unbedingt auf die neueste Version.
2. Fügen Sie die entsprechenden AWS-Administrator-Anmeldedaten zur Datei „${HOME}/.aws/credentials“ 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.

Führen Sie zum Bereitstellen des EKS-Clusters den folgenden Befehl eksctl auf dem lokalen Rechner aus. (Das Flag --nodes wird weggelassen, da der Befehl standardmäßig die beiden für den Test benötigten Knoten erstellt: einen für den NGINX Plus Ingress Controller und einen für die grundlegende Backend-Anwendung.)

Hinweis: Sie können den EKS-Cluster in jeder Region außer us-west-1 bereitstellen. Das Abonnieren des Images für den NGINX Plus Ingress Controller im Amazon Marketplace for Containers (siehe den nächsten Abschnitt) wird in dieser Region nicht unterstützt.

# eksctl create cluster --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/path/to/public-key

Führen Sie diesen Befehl aus, um über SSH eine Verbindung zu einem Clusterknoten herzustellen. Während des Tests müssen Sie eine Verbindung zum Knoten des NGINX Plus Ingress Controllers herstellen, um den Befehl htop auszuführen und zu überprüfen, ob die vom wrk-Client erzeugte Last ausreicht, um die CPU-Auslastung des Knotens auf 100 % zu erhöhen.

# ssh -i /path/to/private-key ec2-user@<public-IP-address-of-EKS-node>

Bereitstellen des NGINX Plus Ingress Controllers

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

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

1. Erstellen Sie iamserviceaccount, die standardmäßige Kombination aus IAM-Rolle und Servicekonto (IRSA) für EKS, und fügen Sie die AWSMarketplaceMeteringRegisterUsage-IAM-Richtlinie hinzu, um die Nutzung des NGINX Plus Ingress Controller-Images zu überwachen und die Bereitstellung zu autorisieren. Dieser Befehl erstellt automatisch ein Servicekonto mit einer Annotation, die auf iamserviceaccount verweist.

# eksctl create iamserviceaccount --name <service-account-name> --namespace nginx-ingress --cluster <eks-cluster-name> --region <eks-cluster-region> --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve

1. Bearbeiten Sie in der YAML-Datei für RBAC den Wert von name im Feld subjects so, dass er mit dem im vorherigen Schritt festgelegten service-account-name übereinstimmt. Dieser befindet sich in Zeile 104 in rbac.yaml und in Zeile 23 in ap-rbac.yaml. Bearbeiten Sie bei Bedarf auch den Wert des Namespace (Zeile 105 bzw. Zeile 24). Der obige Befehl verwendet jedoch den Standardwert nginx-ingress.
2. Wenden Sie die YAML-Datei an (ersetzen Sie sie gegebenenfalls durch „ap-rbac.yaml“).

# kubectl apply –f rbac.yaml

1. Installieren Sie die Docker-Client-Software auf dem lokalen Rechner.
2. Abonnieren Sie das Angebot für den „NGINX Plus Ingress Controller (Premium Edition)“ im Amazon Marketplace for Containers.
3. Authentifizieren Sie Ihren Docker-Client bei Amazon ECR, wo das Docker-Image des NGINX Plus Ingress Controllers gehostet wird.
4. Bearbeiten Sie die folgenden Werte in „nginx-ingress.yaml“:
   • kubernetes.io/hostname im Feld nodeSelector (Zeile 23) – Die Bezeichnung für den Knoten des NGINX Plus Ingress Controllers im EKS-Cluster, die mit dem Befehl kubectl get nodes --show-labels abgerufen wird
   • serviceAccountName (Zeile 24) – Der Name des iamserviceaccount-IRSA, der in service-account-name unter Schritt 2 angegeben wurde.
   • image im Feld containers (Zeile 26) – Der Speicherort des Docker-Images für den NGINX Plus Ingress Controller in Amazon ECR
5. 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 das Label, das Sie mit dem Befehl „kubectl get nodes --show-labels“ ermittelt haben.
2. Wenden Sie das YAML-Manifest an:

# kubectl apply –f backend-deployment.yaml

1. Skalieren Sie die Backend-Anwendung auf drei Replikate, damit sie die von wrk erzeugte Last bewältigen kann:

# kubectl scale deployment web-server-payload --replicas=3

Testmethodik

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

# wrk -t <number-of-threads> -c <number-of-connections> -d 180s http[s]://<address-of-NGINX-Plus-Ingress-Controller>

• Die Option –c gibt die Anzahl der zu erstellenden TCP-Verbindungen an. Legen Sie diese Option nach Bedarf so fest, dass eine CPU-Auslastung von 100 % erreicht wird, wobei maximal 500 Verbindungen möglich sind.
• Die Option –d gibt an, wie lange Datenverkehr erzeugt werden soll (die Dauer jedes Testlaufs). Legen Sie diese Option auf 180 Sekunden (3 Minuten) fest.
• Die Option „–t“ gibt die Anzahl der zu erstellenden Threads an. Legen Sie diese Option so fest, dass eine CPU-Auslastung von 100 % erreicht wird, jedoch auf höchstens 16 Threads (einen für jede während des Testlaufs auf dem Client verwendete CPU).

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 Leistungskennzahlen zu erfassen:

• Anfragen pro Sekunde (RPS) – Die Anzahl der Anfragen, die der NGINX Plus Ingress Controller pro Sekunde verarbeiten kann, gemittelt über einen festgelegten Zeitraum. Verwenden Sie in diesem Fall das Schema http:// im Befehl wrk. Der NGINX Plus Ingress Controller nimmt die Anfragen für eine 1-KB-Datei (statischer Inhalt) entgegen und verteilt sie auf die Backend-Anwendungs-Pods. Die Datei entspricht ungefähr der Größe einer kleinen CSS- oder JavaScript-Datei oder eines sehr kleinen Bildes.
• SSL/TLS-Transaktionen pro Sekunde (TPS) – Die Anzahl neuer HTTPS-Verbindungen, die der NGINX Plus Ingress Controller pro Sekunde herstellen und bedienen kann. Verwenden Sie in diesem Fall das Schema https:// im Befehl wrk. Verwenden Sie RSA mit einer Schlüssellänge von 2048 Bit und Perfect Forward Secrecy; als SSL-Verschlüsselungsverfahren wird ECDHE-RSA-AES256-GCM-SHA384 verwendet. 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 Anfrage und gibt eine 0-KB-Antwort zurück. Die Verbindung wird geschlossen, nachdem die Anfrage bearbeitet wurde.

Wie unter Erstellen des Amazon EKS-Clusters erwähnt, können Sie den NGINX Plus Ingress Controller der Einfachheit halber bei jedem Testlauf auf einer c5n.9xlarge-Instanz ausführen. Um festzulegen, wie viele CPUs bei jedem Testlauf verfügbar sind (zwischen 1 und 36, wie in der Tabelle unter Leistungsanalyse angegeben), legen Sie den Parameter der Direktive worker_processes entsprechend fest.

Verwendete Software

Für die Tests haben wir die folgende Software verwendet:

• Der Clientcomputer, auf dem wrk ausgeführt wurde, erzeugte den Datenverkehr, den der Ingress Controller weiterleitete. Wir verwendeten die Version von wrk, 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 Rechnern 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 mithilfe der Direktive „worker_processes“ gesteuert, wie viele CPUs verwendet wurden. In der folgenden Tabelle geben wir für jede CPU-Anzahl den entsprechenden Instanztyp der c5n-Familie sowie dessen monatliche Gesamtbetriebskosten (TCO) an.

Die Tabelle zeigt die Anzahl der RPS und SSL-TPS, die mit einer unterschiedlichen Anzahl von CPUs erzielt wurden, die dem NGINX Plus Ingress Controller zur Verfügung standen. Die Ergebnisse stammen aus den unter „Testmethodik“ beschriebenen Tests.

Beachten Sie, dass die RPS bei einer größeren Anzahl von CPUs nicht linear steigen. Tatsächlich nimmt die prozentuale Verbesserung mit zunehmender CPU-Anzahl tendenziell ab. Bei mehr als 16 Kernen fällt die Verbesserungsrate noch weiter ab, da c5n.9xlarge-Instanzen Hyperthreading unterstützen und mit 18 Kernen sowie 2 Threads pro Kern ausgestattet sind, sodass insgesamt bis zu 36 CPUs zur Verfügung stehen. Hyperthreading erhöht die Anzahl der RPS nur geringfügig.

Auch der Zusammenhang zwischen SSL-TPS und der Anzahl der CPUs ist nicht linear, allerdings fällt die Leistung erst bei einer Skalierung auf mehr als 16 CPUs deutlich ab. Hyperthreading verbessert die Leistung CPU-gebundener, parallelisierbarer Vorgänge wie TLS-Handshakes. Daher steigt die SSL-TPS-Leistung selbst dann noch, wenn wir auf mehr als 18 CPUs skalieren.

Fazit

Wir haben Bereitstellungsdetails bereitgestellt, anhand derer Sie die erwartete Leistung des in Amazon EKS ausgeführten NGINX Plus Ingress Controllers ermitteln können. Mithilfe dieser Details können Sie weitere EKS-Instanzfamilien testen und eine kostengünstige Lösung bereitstellen, die Ihre Leistungs- und Skalierungsanforderungen für Produktionsworkloads in Kubernetes erfüllt.

Unsere Ergebnisse für HTTP-RPS zeigen, dass die prozentuale Leistungssteigerung mit jeder Verdopplung der CPU-Anzahl abnimmt und sich bei etwa 300.000 RPS einpendelt. Die Ergebnisse für SSL-TPS zeigen, dass die Leistung mit jeder Verdopplung der CPU-Anzahl nahezu linear steigt – selbst wenn Hyperthreading zum Einsatz kommt (zwei Threads pro Kern), da TLS-Handshakes CPU-gebunden sind.

Lesen Sie die Lösungsübersicht, und testen Sie die Leistung des NGINX Plus Ingress Controllers selbst – legen Sie noch heute los!

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

Über den Autor

Amir RawdatLösungsingenieur

Weitere Blogbeiträge von Amir Rawdat