Dieses Tutorial ist eines von vier, die Konzepte aus „Microservices March 2022“ in die Praxis umsetzen: Kubernetes-Netzwerk :
Möchten Sie detaillierte Anleitungen zur Verwendung von NGINX für noch mehr Anwendungsfälle von Kubernetes-Netzwerken? Laden Sie unser kostenloses E-Book „Verwaltung des Kubernetes-Verkehrs mit NGINX“ herunter: Ein praktischer Leitfaden .
Ihre Organisation hat eine App in Kubernetes erstellt und jetzt erfreut sie sich großer Beliebtheit! Von einigen wenigen Besuchern sind es inzwischen Hunderte (und manchmal Tausende) pro Tag. Es gibt jedoch ein Problem: Der erhöhte Datenverkehr führt zu einem Engpass und verursacht Latenzen und Zeitüberschreitungen für Ihre Kunden. Wenn Sie das Erlebnis nicht verbessern können, werden die Leute die App nicht mehr nutzen.
Sie – der mutige Kubernetes-Ingenieur – haben eine Lösung. Sie setzen einen Ingress-Controller ein, um den Datenverkehr weiterzuleiten, und richten eine Autoscaling-Richtlinie ein, sodass die Anzahl der Ingress-Controller-Pods je nach Datenverkehrsschwankungen sofort erweitert oder verkleinert wird. Jetzt bewältigen Ihre Ingress-Controller-Pods Verkehrsspitzen nahtlos – „Auf Wiedersehen, Latenz!“ – und skalieren herunter, um Ressourcen zu sparen, wenn der Verkehr abnimmt – „Hallo, Kosteneinsparungen!“ Gut gemacht, du.
Dieser Blog begleitet das Labor für Einheit 1 von Microservices vom März 2022 – „Entwerfen von Kubernetes-Clustern für Websites mit hohem Datenverkehr“ und zeigt, wie Sie mit dem NGINX Ingress Controller eine App verfügbar machen und dann die Ingress-Controller-Pods als Reaktion auf hohen Datenverkehr automatisch skalieren.
Zum Ausführen des Lernprogramms benötigen Sie einen Computer mit:
Um den größtmöglichen Nutzen aus dem Labor und dem Lernprogramm zu ziehen, empfehlen wir Ihnen, vor dem Beginn Folgendes zu tun:
Sehen Sie sich die Aufzeichnung des live gestreamten konzeptionellen Überblicks an
Lesen Sie die Hintergrundblogs
Sehen Sie sich die 20-minütige Videozusammenfassung des Labors an:
In diesem Tutorial werden die folgenden Technologien verwendet:
Die Anweisungen für jede Herausforderung enthalten den vollständigen Text der YAML-Dateien, die zum Konfigurieren der Apps verwendet werden. Sie können den Text auch aus unserem GitHub-Repository kopieren. Zusammen mit dem Text jeder YAML-Datei wird ein Link zu GitHub bereitgestellt.
Dieses Tutorial umfasst vier Herausforderungen:
In dieser Herausforderung erstellen Sie einen Minikube-Cluster und installieren Podinfo als Beispiel-App.
Erstellen Sie einen Minikube- Cluster. Nach einigen Sekunden bestätigt eine Meldung, dass die Bereitstellung erfolgreich war.
$ minikube start 🏄 Fertig! kubectl ist jetzt so konfiguriert, dass es standardmäßig den Cluster „minikube“ und den Namespace „default“ verwendet
Podinfo ist eine „mit Go erstellte Webanwendung, die Best Practices zum Ausführen von Microservices in Kubernetes demonstriert“. Wir verwenden es aufgrund seines geringen Platzbedarfs als Beispiel-App.
Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens 1-deployment.yaml mit dem folgenden Inhalt (oder kopieren Sie sie von GitHub ). Es definiert eine Bereitstellung mit einer einzelnen Replik und einem Dienst.
API-Version: Apps/v1 Art: Bereitstellung
Metadaten:
Name: podinfo
Spezifikation:
Selektor:
MatchLabels:
App: podinfo
Vorlage:
Metadaten:
Labels:
App: podinfo
Spezifikation:
Container:
-Name: podinfo
Bild: stefanprodan/podinfo
Ports:
-ContainerPort: 9898
---
API-Version: v1
Art: Dienst
Metadaten:
Name: podinfo
Spezifikation:
Ports:
-Port: 80
ZielPort: 9898
KnotenPort: 30001
Selektor:
App: podinfo
Typ: Lastenausgleich
Stellen Sie die App bereit:
$ kubectl apply -f 1-deployment.yaml deployment.apps/podinfo erstellt service/podinfo erstellt
Bestätigen Sie, dass der Podinfo-Pod bereitgestellt wurde. Dies wird durch den Wert „Wird ausgeführt“
in der Spalte „STATUS“
angezeigt.
$ kubectl get pods NAME BEREIT STATUS NEUSTART ALTER podinfo-5d76864686-rd2s5 1/1 Läuft 0 3m38s
Öffnen Sie Podinfo in einem Browser. Die Begrüßungsseite von Podinfo zeigt an, dass Podinfo ausgeführt wird.
$ Minikube-Dienst Podinfo
Bei dieser Herausforderung stellen Sie den NGINX Ingress Controller bereit und konfigurieren ihn so, dass der Datenverkehr an die Podinfo-App weitergeleitet wird .
Am schnellsten lässt sich NGINX Ingress Controller mit Helm installieren.
Fügen Sie das NGINX-Repository zu Helm hinzu:
$ helm repo add nginx-stable https://helm.nginx.com/stable
Laden Sie den auf Open Source basierenden NGINX Ingress Controller herunter und installieren Sie ihn, der von F5 NGINX verwaltet wird. Die letzte Ausgabezeile bestätigt die erfolgreiche Installation.
$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30005 NAME: main LETZTE BEREITSTELLUNG: Di., 15. März 2022, 09:49:17 NAMESPACE: Standard STATUS: bereitgestellt REVISION: 1 TESTSUITE: Keine ANMERKUNGEN: Der NGINX Ingress Controller wurde installiert.
Bestätigen Sie, dass der NGINX Ingress Controller-Pod bereitgestellt wurde. Dies wird durch den Wert „Running“
in der Spalte „STATUS“
angezeigt (der Lesbarkeit halber ist die Ausgabe auf zwei Zeilen verteilt).
$ kubectl get pods NAME BEREIT STATUS ... main-nginx-ingress-779b74bb8b-mtdkr 1/1 Wird ausgeführt ... podinfo-5d76864686-fjncl 1/1 Wird ausgeführt ... ... STARTET DAS ALTER NEU ... 0 18 s ... 0 2m36s
Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens 2-ingress.yaml mit dem folgenden Inhalt (oder kopieren Sie sie von GitHub ). Es definiert das Ingress-Manifest, das zum Weiterleiten des Datenverkehrs an Podinfo erforderlich ist.
API-Version: networking.k8s.io/v1 Art: Ingress
Metadaten:
Name: podinfo
Spezifikation:
IngressClassName: nginx
Regeln:
- Host: „example.com“
http:
Pfade:
- Backend:
Dienst:
Name: podinfo
Port:
Nummer: 80
Pfad: /
Pfadtyp: Präfix
Stellen Sie die Ingress-Ressource bereit:
$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/podinfo erstellt
In dieser Herausforderung beobachten Sie die Leistung des NGINX Ingress Controllers unter unterschiedlichen Verkehrslasten. Als vorbereitende Schritte listen Sie die vom NGINX Ingress Controller verfügbaren Metriken auf , stellen Prometheus bereit und installieren Locust . Anschließend verwenden Sie Locust, um einen Verkehrsanstieg zu simulieren und die Auswirkungen auf die Leistung in Prometheus zu verfolgen .
Wie Sie bereits festgestellt haben, ist ein Ingress-Controller ein regulärer Kubernetes-Pod, der einen Reverse-Proxy (in unserem Fall NGINX) mit etwas Code für die Integration mit Kubernetes bündelt. Wenn Ihre App viel Datenverkehr empfängt, müssen Sie wahrscheinlich die Anzahl der NGINX Ingress Controller-Pod-Replikate erhöhen, um die Latenz zu vermeiden, die durch eine Überlastung des NGINX Ingress Controllers entsteht.
Um zu wissen, wann und wie stark skaliert werden muss, benötigen Sie genaue Informationen zur Leistung des NGINX Ingress Controllers. In diesem Tutorial wird zur Bestimmung des Skalierungszeitpunkts die Anzahl der aktiven Verbindungen ( nginx_connections_active
) als NGINX-Metrik verwendet. Hier überprüfen Sie, ob Ihr NGINX Ingress Controller diese Metrik verfolgt.
NGINX Ingress Controller stellt mehrere Metriken bereit : 8 Metriken mit dem auf Open Source basierenden NGINX-Modell, das wir in diesem Tutorial verwenden, und über 80 Metriken mit dem auf NGINX Plus basierenden Modell.
Besorgen Sie sich die IP-Adresse des NGINX Ingress Controller-Pods, damit Sie dessen Metrikliste abfragen können. Die Adresse erscheint im IP-
Feld und hier ist sie172.17.0.4
. (Aus Gründen der Lesbarkeit werden die Spalten RESTARTS
und AGE
weggelassen und die Ausgabe auf zwei Zeilen verteilt.)
$ kubectl get pods -o wide NAME BEREIT STATUS ... main-nginx-ingress-779b74bb8b-6hdwx 1/1 Wird ausgeführt ... podinfo-5d76864686-nl8ws 1/1 Wird ausgeführt ... ... IP-NODE NOMINIERTE KNOTENBEREITSCHAFTS-GATES
... 172.17.0.4 minikube <keine> <keine>
... 172.17.0.3 minikube
Erstellen Sie einen temporären BusyBox- Pod mit einer Shell auf einem Host innerhalb des Kubernetes-Clusters:
$ kubectl run -ti --rm=true busybox --image=busybox Wenn keine Eingabeaufforderung angezeigt wird, drücken Sie die Eingabetaste. / #
Listen Sie die von Ihrem NGINX Ingress Controller generierten Metriken auf und überprüfen Sie, ob sie nginx_connections_active
enthalten. Für <IP_Adresse>
Ersetzen Sie den Wert aus Schritt 1.
/# wget -qO- <IP_Adresse>:9113/Metriken
Beenden Sie die Shell, um zum Kubernetes-Server zurückzukehren.
/# Ausfahrt
Da Sie nun wissen, dass Ihr NGINX Ingress Controller die Metrik nginx_connections_active
verfolgt, benötigen Sie ein Tool zum Sammeln („Scrapen“) der Metriken – dieses Tutorial verwendet Prometheus .
Für den NGINX Ingress Controller ist Helm die schnellste Möglichkeit, Prometheus zu installieren.
Fügen Sie das Prometheus-Repository zu Helm hinzu:
$ Helm-Repo fügt Prometheus-Community hinzu https://prometheus-community.github.io/helm-charts
Laden Sie Prometheus herunter und installieren Sie es:
$ helm installiere prometheus prometheus-community/prometheus \ --set server.service.type=NodePort --set server.service.nodePort=30010
Überprüfen Sie die Installation. Normalerweise dauert der Abschluss bis zu 60 Sekunden. In der folgenden Beispielausgabe wurde der Überprüfungsbefehl nur wenige Sekunden nach dem Helm-
Installationsbefehl
ausgeführt. Daher sehen wir, dass die Installation ausgeführt wird und im STATUS-
Feld für einige Prometheus-Pods „ContainerCreating“
gemeldet wird. Die Installation ist abgeschlossen, wenn alle Pods den Status „ Wird ausgeführt“
haben. (Die Ausgabe ist der Lesbarkeit halber auf zwei Zeilen verteilt.)
$ kubectl get pods NAME BEREIT ... main-nginx-ingress-779b74bb8b-mtdkr 1/1 ... podinfo-5d76864686-fjncl 1/1 ... prometheus-alertmanager-d6d94cf4b-85ww5 0/2 ... prometheus-kube-state-metrics-7cd8f95cb-86hhs 0/1 ... prometheus-node-exporter-gqxfz 1/1 ... prometheus-pushgateway-56745d8d8b-qnwcb 0/1 ... prometheus-server-b78c9449f-kwhzp 0/2 ... ... STATUS STARTET ALTER NEU ... Läuft 0,3 Min. und 23 Min. ... Läuft 0,5 min. 41 s … ContainerErstellen 0,7 s ... Läuft 0,7 Sekunden ... Läuft 0,7 Sekunden ... ContainerErstellen 0,7 s ... Containererstellung 0 7 s
Öffnen Sie Prometheus. Führen Sie in einer Minikube-Umgebung den folgenden Befehl aus, der das Prometheus-Dashboard in Ihrem Standardbrowser öffnet.
$ Minikube-Dienst Prometheus-Server
Eine Seite wie die folgende bestätigt, dass der Server funktioniert.
Geben Sie nginx_ingress_nginx_connections_active
in die Suchleiste ein, um den aktuellen Wert der Metrik für aktive Verbindungen anzuzeigen. Sie sehen eine aktive Verbindung, was Sinn macht, da Sie einen NGINX Ingress Controller-Pod bereitgestellt haben.
Im nächsten Abschnitt verwenden Sie Locust , ein Open Source-Tool für Lasttests, um einen Verkehrsanstieg zu simulieren, sodass Sie die Leistung des NGINX Ingress Controllers in Prometheus beobachten können. Hier setzt du Locust ein.
Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens 3-locust.yaml mit dem folgenden Inhalt (oder kopieren Sie sie von GitHub ). Die Bereitstellungs- und Serviceobjekte definieren den Locust-Pod. Das ConfigMap-Objekt definiert ein Skript namens locustfile.py , das Anfragen generiert, die mit den richtigen Headern an den Pod gesendet werden.
API-Version: v1
Art: ConfigMap
metadata:
name: locust-script
data:
locustfile.py: |-
from locust import HttpUser, task, between
class QuickstartUser(HttpUser):
wait_time = between(0.7, 1.3)
@task
def hello_world(self):
self.client.get("/", headers={"Host": "example.com"})
---
apiVersion: apps/v1
kind: Bereitstellung
Metadaten:
Name: locust
Spezifikation:
Selektor:
MatchLabels:
App: locust
Vorlage:
Metadaten:
Labels:
App: locust
Spezifikation:
Container:
- Name: locust
Bild: locustio/locust
Ports:
- ContainerPort: 8089
volumeMounts:
- mountPath: /home/locust
Name: locust-script
volumes:
- Name: locust-script
configMap:
Name: locust-script
---
apiVersion: v1
kind: Dienst
Metadaten:
Name: locust
Spezifikation:
Ports:
-Port: 8089
ZielPort: 8089
KnotenPort: 30015
Selektor:
App: Heuschrecke
Typ: Lastenausgleich
Locust einsetzen:
$ kubectl apply -f 3-locust.yaml configmap/locust-script erstellt deployment.apps/locust erstellt service/locust erstellt
Öffnen Sie Locust in einem Browser.
$ Minikube-Dienst Heuschrecke
Geben Sie in die Felder folgende Werte ein:
Klicken Sie auf die Schaltfläche „Swarming starten“, um Datenverkehr an die Podinfo-App zu senden.
Kehren Sie zum Prometheus-Dashboard zurück, um zu sehen, wie der NGINX Ingress Controller reagiert. Möglicherweise müssen Sie eine neue Abfrage für nginx_ingress_nginx_connections_active
durchführen, um Änderungen anzuzeigen.
Wie in der folgenden Bildschirmausgabe gezeigt, hat der einzelne NGINX Ingress Controller-Pod Schwierigkeiten, den erhöhten Datenverkehr ohne Latenz zu verarbeiten, da eine große Anzahl von Verbindungen hergestellt wird. Das Prometheus-Diagramm zeigt, dass etwa 100 aktive Verbindungen pro NGINX Ingress Controller-Pod der Wendepunkt für einen Latenz-Anstieg sind. Anhand dieser Informationen können Sie ermitteln, wann Sie die Anzahl der NGINX Ingress Controller-Pods erhöhen müssen, um eine erhöhte Latenz zu vermeiden.
In der letzten Herausforderung erstellen Sie eine Konfiguration, die die Ressourcen automatisch skaliert, wenn das Verkehrsaufkommen zunimmt. Das Tutorial verwendet KEDA zur automatischen Skalierung. Installieren Sie es daher zunächst und erstellen Sie eine Richtlinie , die definiert, wann und wie die Skalierung erfolgt. Wie in Herausforderung 3 verwenden Sie dann Locust, um einen Verkehrsanstieg zu simulieren , und Prometheus, um die Leistung des NGINX Ingress Controllers zu beobachten, wenn die automatische Skalierung aktiviert ist.
KEDA , ein ereignisgesteuerter Autoscaler von Kubernetes, integriert einen Metrikserver (die Komponente, die Metriken für Kubernetes speichert und transformiert) und kann Metriken direkt von Prometheus (sowie anderen Tools) nutzen. Es erstellt mit diesen Metriken einen Horizontal Pod Autoscaler (HPA), überbrückt die von Prometheus gesammelten Metriken und speist sie in Kubernetes ein.
Wie bei NGINX Ingress Controller und Prometheus verwendet das Tutorial Helm, um KEDA zu installieren.
Fügen Sie KEDA zum Helm-Repository hinzu:
$ helm repo add kedacore https://kedacore.github.io/charts "kedacore" wurde zu Ihren Repositories hinzugefügt
Installieren Sie KEDA:
$ helm install keda kedacore/keda NAME: keda NAMESPACE: Standard STATUS: bereitgestellt REVISION: 1 TESTSUITE: Keiner
Überprüfen Sie, ob KEDA als zwei Pods ausgeführt wird. (Aus Gründen der Lesbarkeit sind einige Werte in der Spalte NAME
gekürzt. Außerdem wird die Spalte RESTARTS
weggelassen; der Wert ist0
für alle Pods.)
$ kubectl get pods NAME BEREIT STATUS ALTER keda-operator-8644dcdb79-492x5 1/1 Läuft 59 s keda-operator-metrics-apiserver-66d... 1/1 Läuft 59 s locust-77c699c94d-dvb5n 1/1 Läuft 8 m59 s main-nginx-ingress-779b74bb8b-v7ggw 1/1 Läuft 48 m podinfo-5d76864686-c98rb 1/1 Läuft 50 m prometheus-alertmanager-d6d94cf4b-8... 2/2 Wird ausgeführt, 37 m prometheus-kube-state-metrics-7cd8f … 1/1 Läuft 37 m prometheus-node-exporter-j4qf4 1/1 Läuft 37 m prometheus-pushgateway-56745d8d8b-9n4nl 1/1 Läuft 37 m prometheus-server-b78c9449f-6ktn9 2/2 Läuft 37 m
Verwenden Sie jetzt die benutzerdefinierte Ressourcendefinition (CRD) von KEDA ScaledObject,
um die Parameter zu definieren, die die Skalierung des NGINX Ingress Controllers bestimmen. Die folgende Konfiguration:
nginx_connections_active
aus.Führen Sie die folgenden Schritte aus:
Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens 4-scaled-object.yaml mit dem folgenden Inhalt (oder kopieren Sie sie von GitHub ). Es definiert ein KEDA ScaledObject
.
API-Version: keda.sh/v1alpha1 Art: ScaledObject
metadata:
Name: nginx-scale
spec:
scaleTargetRef:
Art: Bereitstellung
Name: main-nginx-ingress
minReplicaCount: 1
maxReplicaCount: 20
Abkühlungsdauer: 30
Abfrageintervall: 1
Trigger:
- Typ: Prometheus
Metadaten:
Serveradresse: http://prometheus-server
Metrikname: nginx_connections_active_keda
Abfrage: |
Summe (Durchschnitt über Zeit (nginx_ingress_nginx_connections_active{app="main-nginx-ingress"}[1m]))
Schwellenwert: "100"
Stellen Sie das ScaledObject
bereit:
$ kubectl apply -f 4-scaled-object.yaml scaledobject.keda.sh/nginx-scale erstellt
Um die Wirksamkeit der automatischen Skalierung wirklich zu testen, verdoppeln Sie die Anzahl der Verbindungen im Vergleich zu Challenge 3.
Kehren Sie in Ihrem Browser zum Locust-Server zurück. Geben Sie die folgenden Werte in die Felder ein und klicken Sie auf die Schaltfläche „Swarming starten“ :
Kehren Sie zu den Dashboards von Prometheus und Locust zurück. Das rosafarbene Kästchen unter dem Prometheus-Diagramm stellt die Anzahl der hoch- und herunterskalierten NGINX Ingress Controller-Pods dar.
Wechseln Sie zurück zu Ihrem Terminal und überprüfen Sie den KEDA HPA manuell. Das Feld REPLICAS
in der Ausgabe zeigt die aktuelle Anzahl der bereitgestellten Pod-Replikate. (Die Ausgabe ist der Lesbarkeit halber auf zwei Zeilen verteilt.)
$ kubectl get hpa NAMENSREFERENZ … keda-hpa-nginx-scale Bereitstellung/main-nginx-ingress … … ZIELE, MINPODS, MAXPODS, REPLIKATE, ALTER ... 101500 m/100 (Durchschnitt) 1 20 10 2 m45 s
Es besteht eine potenzielle Einschränkung, wenn Sie die automatische Skalierung nur auf der Anzahl aktiver Verbindungen basieren. Wenn der NGINX Ingress Controller (selbst mit Skalierung) so ausgelastet ist, dass er Verbindungen trennen muss, erkennt der Autoscaler weniger aktive Verbindungen, interpretiert dies als Hinweis darauf, dass die Anfragen abgelehnt wurden, und reduziert die Anzahl der Replikate. Dadurch kann die Leistung beeinträchtigt werden. Durch die Nutzung einer Kombination aus Messgrößen lässt sich jedoch sicherstellen, dass dies nicht passiert. Beispielsweise verfolgt nginxplus_connections_dropped
(verfügbar mit dem NGINX Ingress Controller basierend auf NGINX Plus) diese unterbrochenen Client-Verbindungen.
Um NGINX Ingress Controller mit NGINX Plus und NGINX App Protect auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .
Um NGINX Ingress Controller mit NGINX Open Source auszuprobieren, können Sie den Quellcode der Version erhalten oder einen vorgefertigten Container von DockerHub herunterladen.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."