BLOG | NGINX

NGINX-Tutorial: Reduzieren Sie die Kubernetes-Latenz mit Autoscaling

Daniele Polencic Miniaturbild
Daniele Polencic
Veröffentlicht am 15. März 2022

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.

Übersicht über Labor und Tutorial

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:

  • 2 CPUs oder mehr
  • 2 GB freier Speicher
  • 20 GB freier Speicherplatz
  • Internetverbindung
  • Container- oder Virtual Machine Manager, wie etwa Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox oder VMware Fusion/Workstation
  • Minikube installiert
  • Helm installiert
  • Eine Konfiguration, die Ihnen das Öffnen eines Browserfensters ermöglicht. Ist dies nicht möglich, muss nach einer Möglichkeit gesucht werden, über einen Browser auf die entsprechenden Dienste zuzugreifen.

Um den größtmöglichen Nutzen aus dem Labor und dem Lernprogramm zu ziehen, empfehlen wir Ihnen, vor dem Beginn Folgendes zu tun:

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:

  1. Konfigurieren einer einfachen App auf einem Kubernetes-Cluster
  2. Verwenden Sie den NGINX Ingress Controller, um den Datenverkehr an die App weiterzuleiten
  3. Generieren und Überwachen von Datenverkehr
  4. Autoscale NGINX Ingress Controller

Herausforderung 1: Konfigurieren einer einfachen App auf einem Kubernetes-Cluster

In dieser Herausforderung erstellen Sie einen Minikube-Cluster und installieren Podinfo als Beispiel-App.

Erstellen eines Minikube-Clusters

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 

Installieren Sie die Podinfo-App

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.

  1. 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 
    
  2. Stellen Sie die App bereit:

    $ kubectl apply -f 1-deployment.yaml deployment.apps/podinfo created 
    service/podinfo created
    
  3. 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
    
  4. Öffnen Sie Podinfo in einem Browser. Die Begrüßungsseite von Podinfo zeigt an, dass Podinfo ausgeführt wird.

    $ minikube service podinfo
    

Herausforderung 2: Verwenden Sie den NGINX Ingress Controller, um den Datenverkehr an die App weiterzuleiten

Bei dieser Herausforderung stellen Sie den NGINX Ingress Controller bereit und konfigurieren ihn so, dass der Datenverkehr an die Podinfo-App weitergeleitet wird .

Bereitstellen des NGINX Ingress Controllers

Am schnellsten lässt sich NGINX Ingress Controller mit Helm installieren.

  1. Fügen Sie das NGINX-Repository zu Helm hinzu:

    $ helm repo add nginx-stable https://helm.nginx.com/stable 
    
  2. 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.
    
  3. 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
    

Leiten Sie den Datenverkehr an Ihre App weiter

  1. 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 
    
  2. Ingress-Ressource bereitstellen:

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

Herausforderung 3: Generieren und Überwachen von Datenverkehr

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.

Auflisten der verfügbaren Metriken

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.

  1. 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>
    
  2. 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. 
    / # 
    
  3. 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
    
  4. Beenden Sie die Shell, um zum Kubernetes-Server zurückzukehren.

    /# exit 
    

Bereitstellen von Prometheus

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.

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

    $ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
    
  2. Laden Sie Prometheus herunter und installieren Sie es:

    $ helm install prometheus prometheus-community/prometheus \ 
    --set server.service.type=NodePort --set server.service.nodePort=30010
    
  3. Ü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
    
  4. Ö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.

  5. 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.

Installieren Sie Locust

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.

  1. 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 
    
  2. Locust einsetzen:

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

Simulieren Sie einen Datenverkehrsanstieg und beobachten Sie die Auswirkungen auf die Leistung

  1. Öffnen Sie Locust in einem Browser.

    $ minikube service locust
    

  2. Geben Sie in die Felder folgende Werte ein:

    • Anzahl der Benutzer – 1000
    • Spawnrate – 10
    • Host – http://main-nginx-ingress
  3. Klicken Sie auf die Schaltfläche „Swarming starten“, um Datenverkehr an die Podinfo-App zu senden.

  4. 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.

Herausforderung 4: Autoscale NGINX Ingress Controller

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 installieren

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.

  1. Fügen Sie KEDA zum Helm-Repository hinzu:

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

    $ helm install keda kedacore/keda NAME: keda 
    NAMESPACE: default 
    STATUS: deployed 
    REVISION: 1 
    TEST SUITE: None
    
  3. Ü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
    

Erstellen einer Autoscaling-Richtlinie

Nutzen Sie jetzt die benutzerdefinierte Ressourcendefinition (CRD) KEDA ScaledObject, um die Parameter festzulegen, nach denen der NGINX Ingress Controller skaliert. 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 vorhandene Pods jeweils 100 aktive Verbindungen erreichen
  • Automatische Skalierung von NGINX Ingress Controller-Pods von einem einzelnen Pod auf bis zu 20 Pods

Führen Sie die folgenden Schritte aus:

  1. 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" 
    
  2. Stellen Sie das ScaledObject bereit:

    $ kubectl apply -f 4-scaled-object.yaml scaledobject.keda.sh/nginx-scale created 
    

Simulieren Sie einen Datenverkehrsanstieg und beobachten Sie die Auswirkungen der automatischen Skalierung auf die Leistung

Um die Wirksamkeit der automatischen Skalierung wirklich zu testen, verdoppeln Sie die Anzahl der Verbindungen im Vergleich zu Challenge 3.

  1. 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“ :

    • Anzahl der Benutzer – 2000
    • Spawnrate – 10
    • Host – http://main-nginx-ingress
  2. 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.

  3. 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
    

Nächste Schritte

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."