NGINX-Tutorial: Kubernetes-APIs mit Ratenbegrenzung schützen

NGINX | 21. 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 Autoscaling reduzieren
Kubernetes-APIs mit Ratenbegrenzung schützen (dieser Beitrag)
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 gerade seine erste App und API in Kubernetes eingeführt. Sie wurden darauf hingewiesen, dass mit einem hohen Datenverkehrsaufkommen zu rechnen ist (und haben bereits die automatische Skalierung implementiert, damit der NGINX Ingress Controller den Datenverkehr schnell weiterleiten kann). Es bestehen jedoch Bedenken, dass die API Ziel eines böswilligen Angriffs werden könnte. Wenn die API eine große Anzahl von HTTP-Anfragen erhält – etwa durch Brute-Force-Angriffe zum Erraten von Passwörtern oder DDoS-Angriffe –, könnten sowohl die API als auch die App überlastet werden oder sogar abstürzen.

Aber Sie haben Glück! Die als Ratenbegrenzung bezeichnete Technik zur Datenverkehrssteuerung ist ein Anwendungsfall für API-Gateways, bei dem die Rate eingehender Anfragen auf einen für echte Benutzer typischen Wert begrenzt wird. Sie konfigurieren den NGINX Ingress Controller so, dass er eine Richtlinie zur Ratenbegrenzung umsetzt. Dadurch wird verhindert, dass die App und die API durch zu viele Anfragen überlastet werden. Gute Arbeit!

Überblick über das Lab und das Tutorial

Dieser Blogbeitrag begleitet das Lab zu Einheit 2 des Microservices March 2022 – „APIs in Kubernetes bereitstellen“. Dabei wird gezeigt, wie sich mehrere NGINX Ingress Controller mit Ratenbegrenzung kombinieren lassen, um eine Überlastung von Apps und APIs zu verhindern.

Zum Durchführen des Tutorials 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 Hintergrund-Blogbeiträge und sehen Sie sich das Webinar und das Video an
Sehen Sie sich die 18-minütige Videozusammenfassung des Labs an: &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;nbsp;

In diesem Tutorial werden die folgenden Technologien verwendet:

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

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 drei Aufgaben:

Cluster, App, API und Ingress-Controller bereitstellen
Überlasten Sie Ihre App und API
Schützen Sie Ihre App und API mit zwei Ingress-Controllern und Ratenbegrenzung

Aufgabe 1: Cluster, App, API und Ingress-Controller bereitstellen

In dieser Aufgabe stellen Sie einen minikube-Cluster bereit und installieren Podinfo als Beispielanwendung und -API. Anschließend stellen Sie den NGINX Ingress Controller bereit, konfigurieren das Traffic-Routing und testen die Ingress-Konfiguration.

Einen 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 und Podinfo-API 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 und -API.

Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens „1-apps.yaml“ mit folgendem Inhalt (oder kopieren Sie sie von GitHub). Darin wird ein Deployment mit folgenden Komponenten definiert:

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: api 
spec: 
  selector: 
    matchLabels: 
      app: api 
  template: 
    metadata: 
      labels: 
        app: api 
    spec: 
      containers: 
        - name: api 
          image: stefanprodan/podinfo 
          ports: 
            - containerPort: 9898 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: api 
spec: 
  ports: 
    - port: 80 
      targetPort: 9898 
      nodePort: 30001 
  selector: 
    app: api 
  type: LoadBalancer 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: frontend 
spec: 
  selector: 
    matchLabels: 
      app: frontend 
  template: 
    metadata: 
      labels: 
        app: frontend 
    spec: 
      containers: 
        - name: frontend 
          image: stefanprodan/podinfo 
          ports: 
            - containerPort: 9898 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: frontend 
spec: 
  ports: 
    - port: 80 
      targetPort: 9898 
      nodePort: 30002 
  selector: 
    app: frontend 
  type: LoadBalancer

Eine Web-App (wir nennen sie „Podinfo Frontend“), die eine HTML-Seite rendert
Eine API (Podinfo API), die JSON-Daten zurückgibt

App und API bereitstellen:

$ kubectl apply -f 1-apps.yamldeployment.apps/api created 
service/api created 
deployment.apps/frontend created 
service/frontend created

Vergewissern Sie sich, dass die Pods für Podinfo API und Podinfo Frontend erfolgreich bereitgestellt wurden. Dies erkennen Sie am Wert Running in der Spalte STATUS.

$ kubectl get pods  
NAME                        READY   STATUS    RESTARTS  AGE 
api-7574cf7568-c6tr6        1/1     Running   0         87s 
frontend-6688d86fc6-78qn7   1/1     Running   0         87s

NGINX Ingress Controller bereitstellen

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

Installieren Sie den NGINX Ingress Controller mithilfe von Helm in einem separaten Namespace (nginx).

Erstellen Sie den Namespace:

$ kubectl create namespace nginx

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

$ helm repo add nginx-stable https://helm.nginx.com/stable

Laden Sie den NGINX Ingress Controller herunter und installieren Sie ihn in Ihrem Cluster:

$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true \ --set controller.ingressClass=nginx \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30010 \ --set controller.enablePreviewPolicies=true \ --namespace nginx

Vergewissern Sie sich, dass der Pod des NGINX Ingress Controllers bereitgestellt wurde. Dies wird durch den Wert „Running“ in der Spalte „STATUS“ angezeigt (zur besseren Lesbarkeit ist die Ausgabe auf zwei Zeilen verteilt).

$ kubectl get pods -namespace nginx NAME                                  READY   STATUS   ...
main-nginx-ingress-779b74bb8b-d4qtc   1/1     Running  ...

      ... RESTARTS   AGE 
      ... 0          92s

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 die App und die API weiterzuleiten.

apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
  name: first 
spec: 
  ingressClassName: nginx 
  rules: 
    - host: "example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: frontend 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix 
    - host: "api.example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: api 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix

Stellen Sie die Ingress-Ressource bereit:

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

Ingress-Konfiguration testen

Um sicherzustellen, dass Ihre Ingress-Konfiguration wie erwartet funktioniert, testen Sie sie mit einem temporären Pod. Starten Sie einen kurzlebigen BusyBox-Pod im Cluster:

$ kubectl run -ti --rm=true busybox --image=busybox If you don't see a command prompt, try pressing enter.
/ #

Testen Sie die Podinfo-API, indem Sie eine Anfrage an den Pod des NGINX Ingress Controllers mit dem Hostnamen api.example.com senden. Die angezeigte Ausgabe weist darauf hin, dass die API Datenverkehr empfängt.

/ # wget --header="Host: api.example.com" -qO- main-nginx-ingress.nginx { 
  "hostname": "api-687fd448f8-t7hqk", 
  "version": "6.0.3", 
  "revision": "", 
  "color": "#34577c", 
  "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", 
  "message": "greetings from podinfo v6.0.3", 
  "goos": "linux", 
  "goarch": "arm64", 
  "runtime": "go1.16.9", 
  "num_goroutine": "6", 
  "num_cpu": "4" 
}

Testen Sie Podinfo Frontend mit dem folgenden Befehl im selben BusyBox-Pod, um einen Webbrowser zu simulieren und die Webseite abzurufen. Die angezeigte Ausgabe ist der HTML-Code für den Anfang der Webseite.

/ # wget --header="Host: example.com" --header="User-Agent: Mozilla" -qO- main-nginx-ingress.nginx <!DOCTYPE html> 
<html> 
<head> 
  <title>frontend-596d5c9ff4-xkbdc</title> 
  # ...

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

$ minikube service podinfo

Herzlichen Glückwunsch! Der NGINX Ingress Controller empfängt Anfragen und leitet sie an die App und die API weiter.
Beenden Sie im ursprünglichen Terminal die BusyBox-Sitzung:

/ # exit 
$

Herausforderung 2: Überlaste deine App und API

In dieser Aufgabe installieren Sie Locust, ein Open-Source-Tool zur Lastgenerierung, und verwenden es, um einen plötzlichen Anstieg des Datenverkehrs zu simulieren, der die API überlastet und die App zum Absturz bringt.

Locust installieren

Erstellen Sie mit einem Texteditor Ihrer Wahl eine YAML-Datei namens 3-locust.yaml mit folgendem Inhalt (oder kopieren Sie sie von GitHub). Das ConfigMap-Objekt definiert ein Skript namens locustfile.py, das Anfragen mit den richtigen Headern generiert und an den Pod sendet. Der Datenverkehr wird nicht gleichmäßig zwischen der App und der API verteilt – die Anfragen gehen überwiegend an die Podinfo API, während nur 1 von 5 Anfragen an das Podinfo Frontend geht. Die Objekte Deployment und Service definieren den Locust-Pod.

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(1) 
        def visit_website(self): 
            with self.client.get("/", headers={"Host": "example.com", "User-Agent": "Mozilla"}, timeout=0.2, catch_response=True) as response: 
                if response.request_meta["response_time"] > 200: 
                    response.failure("Frontend failed") 
                else: 
                    response.success() 
  
        @task(5) 
        def visit_api(self): 
            with self.client.get("/", headers={"Host": "api.example.com"}, timeout=0.2) as response: 
                if response.request_meta["response_time"] > 200: 
                    response.failure("API failed") 
                else: 
                    response.success() 
--- 
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

Überprüfen Sie die Locust-Bereitstellung. In der folgenden Beispielausgabe wurde der Überprüfungsbefehl nur wenige Sekunden nach dem Befehl „kubectl apply“ ausgeführt. Daher ist die Installation noch nicht abgeschlossen, was durch den Wert „ContainerCreating“ für den Locust-Pod im Feld „STATUS“ angezeigt wird. Warten Sie, bis der Wert „Running“ lautet, bevor Sie mit dem nächsten Abschnitt fortfahren. (Zur besseren Lesbarkeit ist die Ausgabe auf zwei Zeilen verteilt.)

$ kubectl get pods
NAME                        READY   STATUS            ...           api-7574cf7568-c6tr6        1/1     Running           ...
frontend-6688d86fc6-78qn7   1/1     Running           ...            locust-77c699c94d-hc76t     0/1     ContainerCreating ...

      ... RESTARTS   AGE 
      ... 0          33m
      ... 0          33m
      ... 0           4s

Einen plötzlichen Anstieg des Datenverkehrs simulieren

Öffnen Sie Locust in einem Browser.

$ minikube service locust

Geben Sie die folgenden Werte in die Felder ein:
- Anzahl der Benutzer – 1000
- Spawn-Rate – 30
- Host – http://main-nginx-ingress
Klicken Sie auf die Schaltfläche „Start swarming“, um Datenverkehr an die Podinfo API und das Podinfo Frontend zu senden. Beobachten Sie die Datenverkehrsmuster auf den Locust-Registerkarten „Charts“ und „Failures“:
- Diagramm – Mit zunehmender Anzahl an API-Anfragen verschlechtern sich die Antwortzeiten der Podinfo API.
- Fehler – Da Podinfo API und Podinfo Frontend denselben Ingress-Controller verwenden, führt die steigende Anzahl von API-Anfragen schon bald dazu, dass die Web-App Fehler zurückgibt.

Das ist problematisch, da ein einzelner böswilliger Akteur, der die API nutzt, nicht nur die API, sondern alle vom NGINX Ingress Controller bereitgestellten Anwendungen lahmlegen kann!

Herausforderung 3: Schützen Sie Ihre App und API mit zwei Ingress-Controllern und Ratenbegrenzung

In der letzten Aufgabe stellen Sie zwei NGINX Ingress Controller bereit, um die Einschränkungen der vorherigen Bereitstellung zu beseitigen. Dabei erstellen Sie für jeden einen eigenen Namespace, installieren separate NGINX-Ingress-Controller-Instanzen für Podinfo Frontend und Podinfo API, konfigurieren Locust neu, um den Datenverkehr für die App und die API an die jeweiligen NGINX Ingress Controller weiterzuleiten, und überprüfen, ob die Ratenbegrenzung wirksam ist. Sehen wir uns zunächst an, wie sich das Architekturproblem beheben lässt. In der vorherigen Aufgabe haben Sie den NGINX Ingress Controller mit API-Anfragen überlastet, was sich auch auf die App auswirkte. Dies geschah, weil ein einzelner Ingress Controller für die Weiterleitung des Datenverkehrs sowohl an die Web-App (Podinfo Frontend) als auch an die API (Podinfo API) zuständig war.

Wenn Sie für jeden Ihrer Dienste einen separaten NGINX-Ingress-Controller-Pod ausführen, verhindern Sie, dass Ihre Anwendung durch zu viele API-Anfragen beeinträchtigt wird. Dies ist nicht unbedingt für jeden Anwendungsfall erforderlich, doch in unserer Simulation sind die Vorteile des Betriebs mehrerer NGINX Ingress Controller deutlich zu erkennen.

Der zweite Teil der Lösung, der verhindert, dass die Podinfo API überlastet wird, besteht darin, mithilfe des NGINX Ingress Controllers als API-Gateway eine Ratenbegrenzung zu implementieren.

Was ist Ratenbegrenzung?

Die Ratenbegrenzung beschränkt die Anzahl der Anfragen, die ein Benutzer innerhalb eines bestimmten Zeitraums stellen kann. Um beispielsweise einen DDoS-Angriff abzuwehren, können Sie mithilfe der Ratenbegrenzung die Rate eingehender Anfragen auf einen für echte Benutzer typischen Wert begrenzen. Wenn die Ratenbegrenzung mit NGINX implementiert wird, werden Clients, die zu viele Anfragen senden, auf eine Fehlerseite umgeleitet, sodass sie die API nicht beeinträchtigen können. Weitere Informationen zur Funktionsweise finden Sie in der Dokumentation zum NGINX Ingress Controller.

Was ist ein API-Gateway?

Ein API-Gateway leitet API-Anfragen von Clients an die entsprechenden Dienste weiter. Ein weitverbreitetes Missverständnis dieser einfachen Definition besteht darin, dass es sich bei einem API-Gateway um eine eigenständige Technologie handelt. Das ist nicht der Fall. Vielmehr beschreibt „API-Gateway“ eine Reihe von Anwendungsfällen, die sich mit verschiedenen Arten von Proxys umsetzen lassen – am häufigsten mit einem ADC oder Load Balancer und Reverse Proxy, zunehmend aber auch mit einem Ingress-Controller oder Service Mesh. Die Ratenbegrenzung ist ein häufiger Anwendungsfall für den Einsatz eines API-Gateways. Weitere Informationen zu Anwendungsfällen für API-Gateways in Kubernetes finden Sie im Beitrag „Wie treffe ich die richtige Wahl? API-Gateway vs. Ingress-Controller vs. Service Mesh“ in unserem Blog.

Bereiten Sie Ihren Cluster vor

Bevor Sie die neue Architektur und die Ratenbegrenzung implementieren können, müssen Sie die bisherige Konfiguration des NGINX Ingress Controllers löschen.

Löschen Sie die Konfiguration des NGINX Ingress Controllers:

$ kubectl delete -f 2-ingress.yaml 
ingress.networking.k8s.io "first" deleted

Erstellen Sie einen Namespace namens nginx‑web für das Podinfo Frontend:

$ kubectl create namespace nginx-web 
namespace/nginx-web created

Erstellen Sie einen Namespace namens „nginx‑api“ für die Podinfo API:

$ kubectl create namespace nginx-api 
namespace/nginx-api created

NGINX Ingress Controller für das Podinfo-Frontend installieren

NGINX Ingress Controller installieren:

$ helm install web nginx-stable/nginx-ingress --set controller.ingressClass=nginx-web \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30020 \ --namespace nginx-web

Erstellen Sie ein Ingress-Manifest mit dem Namen 4-ingress-web.yaml für das Podinfo Frontend (oder kopieren Sie es von GitHub). apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: rate-limit-policy spec: rateLimit: rate: 10r/s key: ${binary_remote_addr} zoneSize: 10M --- apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: api-vs spec: ingressClassName: nginx-api host: api.example.com policies: - name: rate-limit-policy upstreams: - name: api service: api port: 80 routes: - path: / action: pass: api
Stellen Sie das neue Manifest bereit:

$ kubectl apply -f 4-ingress-web.yaml 
ingress.networking.k8s.io/frontend created

Locust neu konfigurieren

Konfigurieren Sie nun Locust neu und überprüfen Sie Folgendes:

Podinfo API wird nicht überlastet.
Unabhängig davon, wie viele Anfragen an die Podinfo API gesendet werden, hat dies keine Auswirkungen auf das Podinfo Frontend.

Führen Sie die folgenden Schritte aus:

Ändern Sie das Locust-Skript wie folgt: Da Locust im Dashboard nur eine einzige URL unterstützt, codieren Sie den Wert im Python-Skript fest. Verwenden Sie dazu die YAML-Datei 6-locust.yaml mit folgendem Inhalt (oder kopieren Sie sie von GitHub). Beachten Sie die URLs in jeder task-Definition.


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(1) 
        def visit_website(self): 
            with self.client.get("http://web-nginx-ingress.nginx-web/", headers={"Host": "example.com", "User-Agent": "Mozilla"}, timeout=0.2, catch_response=True) as response: 
                if response.request_meta["response_time"] > 200: 
                    response.failure("Frontend failed") 
                else: 
                    response.success() 
  

        @task(5) 
        def visit_api(self): 
            with self.client.get("http://api-nginx-ingress.nginx-api/", headers={"Host": "api.example.com"}, timeout=0.2) as response: 
                if response.request_meta["response_time"] > 200: 
                    response.failure("API failed") 
                else: 
                    response.success() 
--- 
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

Alle Anfragen an Podinfo Frontend werden an den nginx‑web NGINX Ingress Controller unter http://web-nginx-ingress.nginx-web
All requests to Podinfo API are directed to the nginx‑api NGINX Ingress Controller at http://api-nginx-ingress.nginx-api

Stellen Sie die neue Locust-Konfiguration bereit. Die Ausgabe bestätigt, dass das Skript geändert wurde, während die anderen Elemente unverändert geblieben sind.

$ kubectl apply -f 6-locust.yaml 
configmap/locust-script configured 
deployment.apps/locust unchanged 
service/locust unchanged

Löschen Sie den Locust-Pod, um ein erneutes Laden der neuen ConfigMap zu erzwingen. Um den zu entfernenden Pod zu ermitteln, wird das Argument für den Befehl „kubectl delete pod“ als eine Folge über Pipes verbundener Befehle angegeben, die den Locust-Pod aus der Liste aller Pods auswählen.

$ kubectl delete pod `kubectl get pods | grep locust | awk {'print $1'}`

Überprüfen Sie, ob Locust neu geladen wurde (der Wert für den Locust-Pod in der Spalte „AGE“ beträgt nur wenige Sekunden).

$ kubectl get pods
NAME                        READY   STATUS   ...           api-7574cf7568-jrlvd        1/1     Running  ...
frontend-6688d86fc6-vd856   1/1     Running  ...            locust-77c699c94d-6chsg     0/1     Running  ...

      ... RESTARTS   AGE 
      ... 0        9m57s
      ... 0        9m57s
      ... 0           6s

Ratenbegrenzung überprüfen

Kehren Sie zu Locust zurück und ändern Sie die Parameter in diesen Feldern:
- Anzahl der Benutzer – 400
- Spawn-Rate – 10
- Host – http://main-nginx-ingress
Klicken Sie auf die Schaltfläche „Start swarming“, um Datenverkehr an die Podinfo API und das Podinfo Frontend zu senden. Beobachten Sie in der Locust-Titelleiste oben links, wie mit steigender Benutzerzahl in der Spalte STATUS auch der Wert in der Spalte FAILURES zunimmt. Die Fehler stammen nun jedoch nicht mehr vom Podinfo Frontend, sondern von der Podinfo API, da aufgrund der für die API festgelegten Ratenbegrenzung übermäßige Anfragen abgelehnt werden. Im Trace unten rechts sehen Sie, dass NGINX die Meldung 503 Service Temporarily Unavailable zurückgibt. Diese ist Teil der Ratenbegrenzungsfunktion und kann angepasst werden. Die API ist ratenbegrenzt, während die Webanwendung jederzeit verfügbar ist. Gut gemacht!

Nächste Schritte

In der Praxis reicht eine Ratenbegrenzung allein nicht aus, um Ihre Anwendungen und APIs vor böswilligen Akteuren zu schützen. Sie sollten mindestens eine oder zwei der folgenden Methoden zum Schutz von Kubernetes-Anwendungen, -APIs und -Infrastruktur implementieren:

Authentifizierung und Autorisierung
Web Application Firewall und DDoS-Schutz
Ende-zu-Ende-Verschlüsselung und Zero Trust
Einhaltung branchenspezifischer Vorschriften

Diese und weitere Themen behandeln wir in Teil 3 von „Microservices March 2022“ – Sicherheitsmuster für Microservices in Kubernetes. Wenn Sie NGINX Ingress Controller für Kubernetes mit NGINX Plus und NGINX App Protect testen möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen. Wenn Sie NGINX Ingress Controller mit NGINX Open Source testen möchten, können Sie den Quellcode der Version beziehen oder einen vorkonfigurierten Container von DockerHub herunterladen.