BLOG | NGINX

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

NGINX-Teil-von-F5-horiz-schwarz-Typ-RGB
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 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.

Ü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 🏄 Fertig! kubectl ist jetzt so konfiguriert, dass es standardmäßig den Cluster „minikube“ und den Namespace „default“ verwendet 

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.

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

    $ kubectl apply -f 1-deployment.yaml deployment.apps/podinfo erstellt service/podinfo erstellt
    
  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 pods NAME BEREIT STATUS NEUSTART ALTER podinfo-5d76864686-rd2s5 1/1 Läuft 0 3m38s
    
  4. Öffnen Sie Podinfo in einem Browser. Die Begrüßungsseite von Podinfo zeigt an, dass Podinfo ausgeführt wird.

    $ Minikube-Dienst 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 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.
    
  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 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
    

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.

    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 
    
  2. Stellen Sie die Ingress-Ressource bereit:

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

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 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
    
  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=busybox Wenn keine Eingabeaufforderung angezeigt wird, drücken Sie die Eingabetaste. / # 
    
  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_Adresse>:9113/Metriken
    
  4. Beenden Sie die Shell, um zum Kubernetes-Server zurückzukehren.

    /# Ausfahrt 
    

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 fügt Prometheus-Community hinzu https://prometheus-community.github.io/helm-charts
    
  2. Laden Sie Prometheus herunter und installieren Sie es:

    $ helm installiere 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 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
    
  4. Ö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.

  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.

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

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

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

  1. Öffnen Sie Locust in einem Browser.

    $ Minikube-Dienst Heuschrecke
    

  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" wurde zu Ihren Repositories hinzugefügt 
    
  2. Installieren Sie KEDA:

    $ helm install keda kedacore/keda NAME: keda NAMESPACE: Standard STATUS: bereitgestellt REVISION: 1 TESTSUITE: Keiner
    
  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 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
    

Erstellen einer Autoscaling-Richtlinie

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:

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

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

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

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 NAMENSREFERENZ … keda-hpa-nginx-scale Bereitstellung/main-nginx-ingress … … ZIELE, MINPODS, MAXPODS, REPLIKATE, ALTER ... 101500 m/100 (Durchschnitt) 1 20 10 2 m45 s
    

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