NGINX-Tutorial: Kubernetes-Latenz durch Autoscaling reduzieren

NGINX | 15. März 2022

Dieses Tutorial ist eines von vier Tutorials, in denen Konzepte aus „Microservices March 2022: Kubernetes Networking“ praktisch umgesetzt werden:

Kubernetes-Latenz durch automatische Skalierung reduzieren (dieser Beitrag)
Kubernetes-APIs durch Ratenbegrenzung schützen
Kubernetes-Anwendungen vor SQL-Injection schützen
Verbessern Sie Verfügbarkeit und Ausfallsicherheit mit einem Canary-Deployment

Sie wünschen sich eine ausführliche Anleitung zur Verwendung von NGINX für noch mehr Kubernetes-Netzwerkszenarien? Laden Sie unser kostenloses E-Book herunter: „Kubernetes-Datenverkehr mit NGINX verwalten: Ein Praxisleitfaden“.

Ihr Unternehmen hat eine Anwendung in Kubernetes entwickelt, die nun immer beliebter wird! Statt nur weniger Besucher verzeichnen Sie inzwischen Hunderte (und manchmal Tausende) pro Tag. Doch es gibt ein Problem: Der gestiegene Datenverkehr stößt auf einen Engpass, was bei Ihren Kunden zu Verzögerungen und Zeitüberschreitungen führt. Wenn Sie das Nutzungserlebnis nicht verbessern können, werden die Nutzer die Anwendung nicht mehr verwenden.

Sie – der mutige Kubernetes-Engineer – haben eine Lösung. Sie stellen einen Ingress-Controller zur Weiterleitung des Datenverkehrs bereit und richten eine Autoscaling-Richtlinie ein, sodass die Anzahl der Ingress-Controller-Pods sofort erhöht oder verringert wird, um sich an Schwankungen des Datenverkehrs anzupassen. Nun bewältigen Ihre Ingress-Controller-Pods Lastspitzen mühelos – „Auf Wiedersehen, Latenz!“ – und werden bei sinkendem Datenverkehr herunterskaliert, um Ressourcen zu sparen – „Hallo, Kosteneinsparungen!“ Gut gemacht.

Überblick über das Lab und das Tutorial

Dieser Blog begleitet das Lab zu Einheit 1 des Microservices March 2022 – „Kubernetes-Cluster für Websites mit hohem Datenverkehr konzipieren“. Darin wird gezeigt, wie Sie mit dem NGINX Ingress Controller eine App bereitstellen und anschließend die Pods des Ingress Controllers bei hohem Datenverkehr automatisch skalieren.

Um das Tutorial durchzuführen, benötigen Sie einen Rechner mit:

2 CPUs oder mehr
2 GB freier Arbeitsspeicher
20 GB freier Speicherplatz
Internetverbindung
Container- oder VM-Manager wie Docker, Hyperkit, Hyper‑V, KVM, Parallels, Podman, VirtualBox oder VMware Fusion/Workstation
minikube installiert
Helm installiert
Eine Konfiguration, mit der Sie ein Browserfenster öffnen können. Falls das nicht möglich ist, müssen Sie herausfinden, wie Sie über einen Browser auf die entsprechenden Dienste zugreifen können.

Damit Sie das Labor und das Tutorial optimal nutzen können, empfehlen wir Ihnen, vor Beginn Folgendes zu tun:

Sehen Sie sich die Aufzeichnung des per Livestream übertragenen konzeptionellen Überblicks an
Lesen Sie die Hintergrundartikel
Sehen Sie sich die 20-minütige Videozusammenfassung des Labs an: &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;nbsp;

In diesem Tutorial werden folgende Technologien verwendet:

NGINX Ingress Controller (basierend auf NGINX Open Source)
Helm
KEDA
Locust
minikube
Podinfo
Prometheus

Die Anleitungen für jede Aufgabe enthalten den vollständigen Text der YAML-Dateien, die zur Konfiguration der Apps verwendet werden. Sie können den Text auch aus unserem GitHub-Repository kopieren. Neben dem Text jeder YAML-Datei finden Sie einen Link zu GitHub.

Dieses Tutorial umfasst vier Aufgaben:

Eine einfache App in einem Kubernetes-Cluster konfigurieren
NGINX Ingress Controller verwenden, um Datenverkehr an die App weiterzuleiten
Datenverkehr erzeugen und überwachen
NGINX Ingress Controller automatisch skalieren

Aufgabe 1: Eine einfache Anwendung in einem Kubernetes-Cluster konfigurieren

In dieser Aufgabe erstellen Sie einen Minikube-Cluster und installieren Podinfo als Beispielanwendung.

Minikube-Cluster erstellen

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-App installieren

Podinfo ist eine „mit Go entwickelte Webanwendung, die Best Practices für den Betrieb von Microservices in Kubernetes veranschaulicht“. Aufgrund ihres geringen Ressourcenbedarfs verwenden wir sie als Beispielanwendung.

Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens 1-deployment.yaml mit dem folgenden Inhalt (oder kopieren Sie sie von GitHub). Sie definiert ein Deployment mit einem einzelnen Replikat und einen Service.

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

Vergewissern Sie sich, dass der Podinfo-Pod bereitgestellt wurde. Dies erkennen Sie am Wert „Running“ in der Spalte „STATUS“.

$ kubectl get podsNAME                       READY   STATUS   RESTARTS   AGE 
podinfo-5d76864686-rd2s5   1/1     Running  0          3m38s

Öffnen Sie Podinfo in einem Browser. Die Seite „greetings from podinfo“ zeigt an, dass Podinfo ausgeführt wird.

$ minikube service podinfo

Aufgabe 2: NGINX Ingress Controller verwenden, um den Datenverkehr zur App weiterzuleiten

In dieser Aufgabe stellen Sie den NGINX Ingress Controller bereit und konfigurieren ihn so, dass er den Datenverkehr an die Podinfo-App weiterleitet.

NGINX Ingress Controller bereitstellen

Am schnellsten lässt sich der 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 NGINX Open Source basierenden NGINX Ingress Controller herunter und installieren Sie ihn. Er wird von F5 NGINX gepflegt. 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.

Vergewissern Sie sich, dass der Pod des NGINX Ingress Controllers bereitgestellt wurde. Dies erkennen Sie am Wert Running in der Spalte STATUS (zur besseren Lesbarkeit wird 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

Datenverkehr an Ihre App weiterleiten

Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens 2-ingress.yaml mit folgendem Inhalt (oder kopieren Sie sie von GitHub). Sie definiert das Ingress-Manifest, das erforderlich ist, um den Datenverkehr an Podinfo weiterzuleiten.

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

Stellen Sie die Ingress-Ressource bereit:

$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/podinfo created

Aufgabe 3: Datenverkehr erzeugen und überwachen

In dieser Aufgabe beobachten Sie die Leistung des NGINX Ingress Controllers bei unterschiedlicher Datenverkehrslast. Zur Vorbereitung listen Sie die Metriken auf, die der NGINX Ingress Controller bereitstellt, stellen Prometheus bereit und installieren Locust. Anschließend verwenden Sie Locust, um einen plötzlichen Anstieg des Datenverkehrs zu simulieren und dessen Auswirkungen auf die Leistung zu verfolgen – und zwar in Prometheus.

Wie Sie bereits festgestellt haben, ist ein Ingress-Controller ein regulärer Kubernetes-Pod, der einen Reverse-Proxy (in unserem Fall NGINX) mit Code für die Integration in Kubernetes kombiniert. Wenn Ihre App viel Datenverkehr empfängt, müssen Sie wahrscheinlich die Anzahl der Pod-Replikate des NGINX Ingress Controllers erhöhen, um Latenzen zu vermeiden, die durch eine Überlastung des NGINX Ingress Controllers entstehen.

Verfügbare Metriken auflisten

Um zu wissen, wann und in welchem Umfang Sie skalieren müssen, benötigen Sie genaue Informationen zur Leistung des NGINX Ingress Controllers. In diesem Tutorial wird die Anzahl der aktiven Verbindungen als NGINX-Metrik verwendet, um zu bestimmen, wann skaliert werden muss (nginx_connections_active). Hier überprüfen Sie, ob Ihr NGINX Ingress Controller diese Metrik erfasst.

NGINX Ingress Controller stellt mehrere Metriken bereit: 8 Metriken mit dem auf NGINX Open Source basierenden Modell, das wir in diesem Tutorial verwenden, und mehr als 80 Metriken mit dem auf NGINX Plus basierenden Modell.

Ermitteln Sie die IP-Adresse des NGINX Ingress Controller-Pods, damit Sie dessen Metrikliste abfragen können. Die Adresse wird im Feld „IP“ angezeigt und lautet hier „172.17.0.4“. (Zur besseren Lesbarkeit wurden 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. Ersetzen Sie <IP_address> durch den Wert aus Schritt 1.

/# wget -qO- <IP_address>:9113/metrics

Beenden Sie die Shell, um zum Kubernetes-Server zurückzukehren.

/# exit

Prometheus bereitstellen

Da Sie nun wissen, dass Ihr NGINX Ingress Controller die Metrik „nginx_connections_active“ erfasst, benötigen Sie ein Tool, um die Metriken abzurufen („Scraping“) – in diesem Tutorial wird dafür Prometheus verwendet.

Wie beim NGINX Ingress Controller ist Helm der schnellste Weg, Prometheus zu installieren.

Fügen Sie das Prometheus-Repository zu Helm hinzu:

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

Prometheus herunterladen und installieren:

$ helm install prometheus prometheus-community/prometheus \ --set server.service.type=NodePort --set server.service.nodePort=30010

Überprüfen Sie die Installation, die in der Regel innerhalb von 60 Sekunden abgeschlossen ist. In der folgenden Beispielausgabe wurde der Überprüfungsbefehl nur wenige Sekunden nach dem Befehl helm install ausgeführt. Daher sehen wir, dass die Installation noch läuft und für einige Prometheus-Pods im Feld ContainerCreating unter STATUS angezeigt wird. Die Installation ist abgeschlossen, wenn alle Pods den Status Running aufweisen. (Zur besseren Lesbarkeit ist die Ausgabe 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. Dadurch wird das Prometheus-Dashboard in Ihrem Standardbrowser geö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. Es wird eine aktive Verbindung angezeigt, was plausibel ist, da Sie einen NGINX-Ingress-Controller-Pod bereitgestellt haben.

Locust installieren

Im nächsten Abschnitt verwenden Sie Locust, ein Open-Source-Tool für Lasttests, um einen plötzlichen Anstieg des Datenverkehrs zu simulieren und so die Leistung des NGINX Ingress Controllers in Prometheus zu beobachten. Hier stellen Sie Locust bereit.

Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens „3-locust.yaml“ mit folgendem Inhalt (oder kopieren Sie sie von GitHub). Die Deployment- und Service-Objekte definieren den Locust-Pod. Das ConfigMap-Objekt definiert ein Skript namens „locustfile.py“, das Anfragen mit den korrekten Headern generiert und an den Pod sendet.

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 bereitstellen:

$ kubectl apply -f 3-locust.yaml configmap/locust-script created 
deployment.apps/locust created 
service/locust created

Simulieren Sie einen plötzlichen Anstieg des Datenverkehrs und beobachten Sie die Auswirkungen auf die Leistung

Öffnen Sie Locust in einem Browser.

$ minikube service locust

Geben Sie die folgenden Werte in die Felder ein:
- Anzahl der Benutzer – 1000
- Spawn-Rate – 10
- Host – http://main-nginx-ingress
Klicken Sie auf die Schaltfläche „Schwarm 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 ausführen, damit Änderungen sichtbar werden. Wie in der folgenden Bildschirmausgabe zu sehen ist, hat der einzelne NGINX Ingress Controller-Pod Schwierigkeiten, den erhöhten Datenverkehr ohne zusätzliche 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 den Schwellenwert darstellen, ab dem die Latenz sprunghaft ansteigt. Anhand dieser Informationen können Sie bestimmen, wann Sie die Anzahl der NGINX Ingress Controller-Pods erhöhen müssen, um eine höhere Latenz zu vermeiden.

Aufgabe 4: NGINX Ingress Controller automatisch skalieren

In der letzten Aufgabe erstellen Sie eine Konfiguration, die Ressourcen bei steigendem Datenverkehrsaufkommen automatisch skaliert. In diesem Tutorial wird KEDA für die automatische Skalierung verwendet. Daher müssen Sie KEDA zunächst installieren und anschließend eine Richtlinie erstellen, die festlegt, wann und wie die Skalierung erfolgt. Wie in Aufgabe 3 verwenden Sie dann Locust, um einen plötzlichen Anstieg des Datenverkehrs zu simulieren, und Prometheus, um die Leistung des NGINX Ingress Controllers bei aktivierter automatischer Skalierung zu beobachten.

KEDA installieren

KEDA, ein ereignisgesteuerter Autoscaler für Kubernetes, integriert einen Metrikserver (die Komponente, die Metriken für Kubernetes speichert und transformiert) und kann Metriken direkt aus Prometheus (sowie aus anderen Tools) abrufen. KEDA erstellt mit diesen Metriken einen Horizontal Pod Autoscaler (HPA), überträgt die von Prometheus erfassten Metriken und stellt sie Kubernetes bereit.

Wie bei NGINX Ingress Controller und Prometheus wird in diesem Tutorial Helm zur Installation von KEDA verwendet.

Fügen Sie KEDA zum Helm-Repository hinzu:

$ helm repo add kedacore https://kedacore.github.io/charts 
"kedacore" has been added to your repositories

KEDA installieren:

$ helm install keda kedacore/keda NAME: keda 
NAMESPACE: default 
STATUS: deployed 
REVISION: 1 
TEST SUITE: None

Überprüfen Sie, ob KEDA in Form von zwei Pods ausgeführt wird. (Zur besseren Lesbarkeit sind einige Werte in der Spalte „NAME“ gekürzt. Außerdem wurde die Spalte „RESTARTS“ weggelassen; der Wert ist für alle Pods „0“.)

$ 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

Eine Richtlinie für die automatische Skalierung erstellen

Verwenden Sie nun die benutzerdefinierte Ressourcendefinition (CRD) ScaledObject von KEDA, um die Parameter festzulegen, die bestimmen, wie der NGINX Ingress Controller skaliert wird. Die folgende Konfiguration:

Löst die automatische Skalierung basierend auf dem Wert der von Prometheus erfassten Metrik nginx_connections_active aus
Stellt einen neuen Pod bereit, wenn die vorhandenen Pods jeweils 100 aktive Verbindungen erreichen
Skaliert NGINX Ingress Controller-Pods automatisch von einem einzelnen Pod auf bis zu 20 Pods

Führen Sie die folgenden Schritte aus:

Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens „4-scaled-object.yaml“ mit folgendem Inhalt (oder kopieren Sie sie von GitHub). Darin wird ein KEDA-ScaledObject definiert.

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

Simulieren Sie einen plötzlichen Anstieg des Datenverkehrs und beobachten Sie die Auswirkungen der automatischen Skalierung auf die Leistung

Um die Effektivität der automatischen Skalierung wirklich zu testen, verdoppeln Sie die Anzahl der Verbindungen im Vergleich zu Aufgabe 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 „Schwarm starten“:
- Anzahl der Benutzer – 2000
- Erzeugungsrate – 10
- Host – http://main-nginx-ingress
Kehren Sie zu den Prometheus- und Locust-Dashboards zurück. Das rosafarbene Feld unter dem Prometheus-Diagramm zeigt, wie die Anzahl der Pods des NGINX Ingress Controllers hoch- und herunterskaliert wird.
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 an. (Zur besseren Lesbarkeit ist die Ausgabe 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

Nächste Schritte

Wenn die automatische Skalierung ausschließlich auf der Anzahl aktiver Verbindungen basiert, kann dies zu Problemen führen. Ist der NGINX Ingress Controller (selbst bei aktivierter Skalierung) so stark ausgelastet, dass er Verbindungen verwerfen muss, registriert der Autoscaler weniger aktive Verbindungen, deutet dies als Rückgang der Anfragen und reduziert die Anzahl der Replikate. Dadurch kann sich die Leistung weiter verschlechtern. Die Verwendung einer Kombination verschiedener Metriken kann dies jedoch verhindern. Beispielsweise erfasst nginxplus_connections_dropped (verfügbar mit dem auf NGINX Plus basierenden NGINX Ingress Controller) diese verworfenen Clientverbindungen.

Wenn Sie NGINX Ingress Controller mit NGINX Plus und NGINX App Protect ausprobieren möchten, 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 beziehen oder einen vorgefertigten Container von DockerHub herunterladen.