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 die Lösung. Sie setzen einen Ingress-Controller ein, um den Datenverkehr zu lenken, und richten eine Autoscaling-Richtlinie ein, die die Anzahl der Controller-Pods sofort an Schwankungen im Datenverkehr anpasst. Ihre Ingress-Controller-Pods bewältigen nun mühelos Verkehrsspitzen – „Keine Latenz mehr!“ – und reduzieren die Skalierung, um Ressourcen zu schonen, wenn der Datenverkehr zurückgeht – „So sparen Sie Kosten!“ Gut gemacht.
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 🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
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.
apiVersion: apps/v1 kind: Deployment
metadata:
name: podinfo
spec:
selector:
matchLabels:
app: podinfo
template:
metadata:
labels:
app: podinfo
spec:
containers:
- name: podinfo
image: stefanprodan/podinfo
ports:
- containerPort: 9898
---
apiVersion: v1
kind: Service
metadata:
name: podinfo
spec:
ports:
- port: 80
targetPort: 9898
nodePort: 30001
selector:
app: podinfo
type: LoadBalancer
Stellen Sie die App bereit:
$ kubectl apply -f 1-deployment.yaml deployment.apps/podinfo created
service/podinfo created
Bestätigen Sie, dass der Podinfo-Pod bereitgestellt wurde. Dies wird durch den Wert „Wird ausgeführt“
in der Spalte „STATUS“
angezeigt.
$ kubectl get podsNAME READY STATUS RESTARTS AGE
podinfo-5d76864686-rd2s5 1/1 Running 0 3m38s
Öffnen Sie Podinfo in einem Browser. Die Begrüßungsseite von Podinfo zeigt an, dass Podinfo ausgeführt wird.
$ minikube service 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
LAST DEPLOYED: Tue Mar 15 09:49:17 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES: The NGINX Ingress Controller has been installed.
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 podsNAME READY STATUS ...
main-nginx-ingress-779b74bb8b-mtdkr 1/1 Running ...
podinfo-5d76864686-fjncl 1/1 Running ...
... RESTARTS AGE
... 0 18s
... 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.
apiVersion: networking.k8s.io/v1 kind: Ingress
metadata:
name: podinfo
spec:
ingressClassName: nginx
rules:
- host: "example.com"
http:
paths:
- backend:
service:
name: podinfo
port:
number: 80
path: /
pathType: Prefix
Ingress-Ressource bereitstellen:
$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/podinfo created
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 READY STATUS ...
main-nginx-ingress-779b74bb8b-6hdwx 1/1 Running ...
podinfo-5d76864686-nl8ws 1/1 Running ...
... IP NODE NOMINATED NODE READINESS GATES
... 172.17.0.4 minikube <none> <none>
... 172.17.0.3 minikube <none> <none>
Erstellen Sie einen temporären BusyBox- Pod mit einer Shell auf einem Host innerhalb des Kubernetes-Clusters:
$ kubectl run -ti --rm=true busybox --image=busyboxIf you don't see a command prompt, try pressing enter.
/ #
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_address>:9113/metrics
Beenden Sie die Shell, um zum Kubernetes-Server zurückzukehren.
/# exit
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 add prometheus-community https://prometheus-community.github.io/helm-charts
Laden Sie Prometheus herunter und installieren Sie es:
$ helm install 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 podsNAME READY ...
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 RESTARTS AGE
... Running 0 3m23s
... Running 0 5m41s
... ContainerCreating 0 7s
... Running 0 7s
... Running 0 7s
... ContainerCreating 0 7s
... ContainerCreating 0 7s
Öffnen Sie Prometheus. Führen Sie in einer Minikube-Umgebung den folgenden Befehl aus, der das Prometheus-Dashboard in Ihrem Standardbrowser öffnet.
$ minikube service 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.
apiVersion: v1
kind: 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: Deployment
metadata:
name: locust
spec:
selector:
matchLabels:
app: locust
template:
metadata:
labels:
app: locust
spec:
containers:
- name: locust
image: locustio/locust
ports:
- containerPort: 8089
volumeMounts:
- mountPath: /home/locust
name: locust-script
volumes:
- name: locust-script
configMap:
name: locust-script
---
apiVersion: v1
kind: Service
metadata:
name: locust
spec:
ports:
- port: 8089
targetPort: 8089
nodePort: 30015
selector:
app: locust
type: LoadBalancer
Locust einsetzen:
$ kubectl apply -f 3-locust.yaml configmap/locust-script created
deployment.apps/locust created
service/locust created
Öffnen Sie Locust in einem Browser.
$ minikube service locust
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" has been added to your repositories
Installieren Sie KEDA:
$ helm install keda kedacore/keda NAME: keda
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
Ü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 READY STATUS AGE
keda-operator-8644dcdb79-492x5 1/1 Running 59s
keda-operator-metrics-apiserver-66d... 1/1 Running 59s
locust-77c699c94d-dvb5n 1/1 Running 8m59s
main-nginx-ingress-779b74bb8b-v7ggw 1/1 Running 48m
podinfo-5d76864686-c98rb 1/1 Running 50m
prometheus-alertmanager-d6d94cf4b-8... 2/2 Running 37m
prometheus-kube-state-metrics-7cd8f... 1/1 Running 37m
prometheus-node-exporter-j4qf4 1/1 Running 37m
prometheus-pushgateway-56745d8d8b-9n4nl 1/1 Running 37m
prometheus-server-b78c9449f-6ktn9 2/2 Running 37m
Nutzen Sie jetzt die benutzerdefinierte Ressourcendefinition (CRD) KEDA ScaledObject
, um die Parameter festzulegen, nach denen der NGINX Ingress Controller skaliert. 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
.
apiVersion: keda.sh/v1alpha1 kind: ScaledObject
metadata:
name: nginx-scale
spec:
scaleTargetRef:
kind: Deployment
name: main-nginx-ingress
minReplicaCount: 1
maxReplicaCount: 20
cooldownPeriod: 30
pollingInterval: 1
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus-server
metricName: nginx_connections_active_keda
query: |
sum(avg_over_time(nginx_ingress_nginx_connections_active{app="main-nginx-ingress"}[1m]))
threshold: "100"
Stellen Sie das ScaledObject
bereit:
$ kubectl apply -f 4-scaled-object.yaml scaledobject.keda.sh/nginx-scale created
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
NAME REFERENCE ...
keda-hpa-nginx-scale Deployment/main-nginx-ingress ...
... TARGETS MINPODS MAXPODS REPLICAS AGE
... 101500m/100 (avg) 1 20 10 2m45s
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."