Verteilte Lasttests mit Google Kubernetes Engine

In dieser Anleitung wird erläutert, wie Sie mit Google Kubernetes Engine (GKE) ein Framework für verteilte Lasttests bereitstellen, das mehrere Container verwendet, um Traffic für eine einfache REST-basierte API zu erstellen. In dieser Anleitung wird eine in App Engine bereitgestellte Webanwendung getestet, die REST-artige Endpunkte zur Erfassung eingehender HTTP-POST-Anfragen zur Verfügung stellt.

Sie können dasselbe Muster verwenden, um Lasttest-Frameworks für eine Vielzahl von Szenarien und Anwendungen zu erstellen, z. B. Nachrichtensysteme, Datenstrom-Managementsysteme und Datenbanksysteme.

Ziele

  • Umgebungsvariablen definieren, um die Deployment-Konfiguration zu steuern
  • GKE-Cluster erstellen
  • Lasttest durchführen
  • Anzahl der Nutzer hochskalieren oder Muster auf andere Anwendungsfälle erweitern (optional)

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten der Google Cloud Platform verwendet:

  • Google Kubernetes Engine
  • App Engine
  • Cloud Build
  • Cloud Storage

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen. Neuen GCP-Nutzern steht gegebenenfalls eine kostenlose Testversion zur Verfügung.

Hinweise

  1. Melden Sie sich in Ihrem Google-Konto an.

    Wenn Sie noch kein Konto haben, registrieren Sie sich hier für ein neues Konto.

  2. Wählen Sie in der GCP Console auf der Projektauswahlseite ein GCP-Projekt aus oder erstellen Sie eins.

    Zur Projektauswahl

  3. Prüfen Sie, ob die Abrechnung für Ihr Google Cloud Platform-Projekt aktiviert ist. So bestätigen Sie die Abrechnung für Ihr Projekt.

  4. Aktivieren Sie die Cloud Build, Compute Engine, Container Analysis, and Container Registryerforderlichen APIs.

    APIs aktivieren

Nach Abschluss dieser Anleitung können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Beispiel-Arbeitslast

Das folgende Diagramm zeigt ein Beispiel für eine Arbeitslast, bei der Anfragen vom Client an die Anwendung gesendet werden.

Anfragen, die vom Client zur Anwendung gesendet werden.

Um diese Interaktion zu modellieren, können Sie Locust verwenden, ein verteiltes, Python-basiertes Tool für Lasttests, mit dem sich Anfragen auf mehrere Zielpfade verteilen lassen. Locust kann zum Beispiel Anfragen an die Zielpfade /login und /metrics senden. Die Arbeitslast wird in Locust als eine Reihe von Aufgaben modelliert.

Architektur

Diese Architektur umfasst zwei Hauptkomponenten:

  • Das Locust-Docker-Container-Image
  • Den Mechanismus zur Containerorchestrierung und -verwaltung

Das Locust-Docker-Container-Image enthält die Locust-Software. Sie erhalten eine Docker-Datei, wenn Sie das GitHub-Repository klonen, das als Begleitmaterial zu dieser Anleitung verfügbar ist. Diese Datei verwendet ein Basis-Python-Image und enthält Skripte, um den Locust-Dienst zu starten und die Aufgaben auszuführen. Jede Locust-Aufgabe wird gewichtet, um konkrete Clients anzugleichen. Eine Registrierung erfolgt zum Beispiel bei tausend Clientanfragen einmal.

GKE bietet Containerorchestrierung und -verwaltung. Mit GKE können Sie die Anzahl der Containerknoten angeben, die die Grundlage für Ihr Lasttest-Framework bilden. Sie können Ihre Lasttest-Worker auch in Pods organisieren und angeben, wie viele Pods von GKE weiterhin ausgeführt werden sollen.

Gehen Sie so vor, um die Lasttestaufgaben bereitzustellen:

  1. Stellen Sie einen Lasttest-Master bereit.
  2. Stellen Sie eine Gruppe von Lasttest-Workern bereit. Mit diesen Lasttest-Workern können Sie eine erhebliche Menge an Traffic zu Testzwecken generieren.

Im folgenden Diagramm sehen Sie den Inhalt der Master- und Worker-Knoten:

Der Master enthält den API-Server, den Planer und den Manager. Die 2 Knoten enthalten jeweils ein Kubelet, einen Proxy und ein Docker-Image mit 4 Pods.

Informationen zum Lasttest-Master

Der Locust-Master ist der Einstiegspunkt für die Ausführung der Lasttestaufgaben. In der Locust-Masterkonfiguration sind mehrere Elemente angegeben, einschließlich der Ports, die vom Container freigegeben werden sollen:

  • 8089 für die Weboberfläche
  • 5557 und 5558 für die Kommunikation mit Workern

Diese Informationen werden später verwendet, um die Locust-Worker zu konfigurieren.

Sie stellen einen Dienst bereit, um dafür zu sorgen, dass die freigegebenen Ports für andere Pods über hostname:port innerhalb des Clusters zugänglich sind. Die freigegebenen Ports sind auch über einen beschreibenden Portnamen referenzierbar.

Sie verwenden einen Dienst, um den Locust-Workern zu ermöglichen, den Master einfach zu entdecken und zuverlässig mit ihm zu kommunizieren, auch wenn der Master ausfällt und vom Deployment durch einen neuen Pod ersetzt wird. Der Dienst enthält auch eine Richtlinie, um eine externe Weiterleitungsregel auf Clusterebene zu erstellen, die es ermöglicht, dass der externe Traffic auf die Clusterressourcen zugreifen kann.

Nachdem Sie den Locust-Master bereitgestellt haben, können Sie die Weboberfläche über die öffentliche IP-Adresse der externen Weiterleitungsregel öffnen. Nachdem Sie die Locust-Worker bereitgestellt haben, können Sie die Simulation starten und die Gesamtstatistik über die Locust-Weboberfläche betrachten.

Informationen zu den Lasttest-Workern

Die Locust-Worker führen die Lasttestaufgaben aus. Sie verwenden ein einzelnes Deployment, um mehrere Pods zu erstellen. Die Pods sind über den Kubernetes-Cluster verteilt. Jeder Pod verwendet Umgebungsvariablen, um Konfigurationsinformationen wie den Hostnamen des zu testenden Systems und den Hostnamen des Locust-Masters zu steuern.

Das folgende Diagramm zeigt die Beziehung zwischen dem Locust-Master und den Locust-Workern.

Der Locust-Master steht an der Spitze einer Hierarchie mit mehreren Workern darunter.

Gemeinsame Variablen initialisieren

Sie müssen mehrere Variablen definieren, die steuern, wo Elemente der Infrastruktur bereitgestellt werden.

  1. Öffnen Sie Cloud Shell:

    Zu Cloud Shell

    Alle Terminalbefehle in dieser Anleitung werden über Cloud Shell ausgeführt.

  2. Legen Sie die Umgebungsvariablen fest:

    REGION=us-central1
    ZONE=${REGION}-b
    PROJECT=$(gcloud config get-value project)
    CLUSTER=gke-load-test
    TARGET=${PROJECT}.appspot.com
    SCOPE="https://www.googleapis.com/auth/cloud-platform"
    
  3. Legen Sie die Standardzone und die Projekt-ID fest, damit Sie diese Werte nicht bei jedem nachfolgenden Befehl angeben müssen:

    gcloud config set compute/zone ${ZONE}
    gcloud config set project ${PROJECT}
    

Umgebung einrichten

  1. Klonen Sie das Beispiel-Repository aus GitHub:

    git clone https://github.com/GoogleCloudPlatform/distributed-load-testing-using-kubernetes
    
  2. Ändern Sie das Arbeitsverzeichnis in das geklonte Repository:

    cd distributed-load-testing-using-kubernetes
    

GKE-Cluster erstellen

  1. Erstellen Sie den GKE-Cluster:

    gcloud container clusters create $CLUSTER \
       --zone $ZONE \
       --scopes $SCOPE \
       --enable-autoscaling --min-nodes "3" --max-nodes "10" \
       --scopes=logging-write \
       --addons HorizontalPodAutoscaling,HttpLoadBalancing
    
  2. Stellen Sie eine Verbindung zum GKE-Cluster her:

    gcloud container clusters get-credentials $CLUSTER \
       --zone $ZONE \
       --project $PROJECT
    

Docker-Image erstellen

  1. Erstellen Sie das Docker-Image und speichern Sie es in der Container Registry Ihres Projekts:

    gcloud builds submit \
        --tag gcr.io/$PROJECT/locust-tasks:latest docker-image
    
  2. Prüfen Sie, ob sich das Docker-Image im Container-Repository Ihres Projekts befindet:

    gcloud container images list | grep locust-tasks
    

    Die Ausgabe sieht in etwa so aus:

    gcr.io/[PROJECT]/locust-tasks
    Only listing images in gcr.io/[PROJECT]. Use --repository to list images in other repositories.
    

Beispielanwendung bereitstellen

  • Stellen Sie die Beispielanwendung in App Engine bereit:

    gcloud app deploy sample-webapp/app.yaml \
      --project=$PROJECT
    

    Die Ausgabe sollte in etwa so aussehen:

    File upload done.
    Updating service [default]...done.
    Setting traffic split for service [default]...done.
    Deployed service [default] to [https://[PROJECT].appspot.com]
    

Locust-Master und Worker-Knoten bereitstellen

  1. Ersetzen Sie den Zielhost und die Projekt-ID durch den bereitgestellten Endpunkt bzw. die Projekt-ID in den Dateien locust-master-controller.yaml und locust-worker-controller.yaml.

    sed -i -e "s/\[TARGET_HOST\]/$TARGET/g" kubernetes-config/locust-master-controller.yaml
    sed -i -e "s/\[TARGET_HOST\]/$TARGET/g" kubernetes-config/locust-worker-controller.yaml
    sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" kubernetes-config/locust-master-controller.yaml
    sed -i -e "s/\[PROJECT_ID\]/$PROJECT/g" kubernetes-config/locust-worker-controller.yaml
    
  2. Stellen Sie den Locust-Master und Worker-Knoten bereit:

    kubectl apply -f kubernetes-config/locust-master-controller.yaml
    kubectl apply -f kubernetes-config/locust-master-service.yaml
    kubectl apply -f kubernetes-config/locust-worker-controller.yaml
    
  3. Überprüfen Sie die Locust-Deployments:

    kubectl get pods -o wide
    

    Die Ausgabe sollte in etwa so aussehen:

    Der Locust-Master und Worker-Knoten werden bereitgestellt.
  4. Überprüfen Sie die Dienste:

    kubectl get services
    

    Die Ausgabe sollte in etwa so aussehen:

    Die Dienste werden bereitgestellt.
  5. Führen Sie eine Überwachungsschleife aus, während dem Locust-Masterdienst eine externe IP-Adresse zugewiesen ist:

    kubectl get svc locust-master --watch
    
  6. Drücken Sie Ctrl+C, um die Überwachungsschleife zu beenden, und führen Sie dann den folgenden Befehl aus, um die externe IP-Adresse zu notieren:

    EXTERNAL_IP=$(kubectl get svc locust-master -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
    

Last testen

Mithilfe der Weboberfläche des Locust-Masters können Sie die Lasttestaufgaben mit dem zu testenden System ausführen.

  1. Rufen Sie die externe IP-Adresse des Systems ab:

    echo $EXTERNAL_IP
    

  2. Öffnen Sie Ihren Browser und anschließend die Weboberfläche des Locust-Masters. Ersetzen Sie [EXTERNAL_IP] in der folgenden URL durch die IP-Adresse, die Sie im vorherigen Schritt erhalten haben: http://[EXTERNAL_IP]:8089.

    Die Weboberfläche des Locust-Masters bietet ein Dialogfeld zum Starten eines neuen Schwarms und zum Festlegen der Anzahl der Nutzer und der Erzeugungsfrequenz.

  3. Geben Sie unter Number of users to simulate (Anzahl der zu simulierenden Nutzer) insgesamt 10 und bei der Hatch rate (Erzeugungsfrequenz), in der Nutzer kreiert werden sollen, 5 Nutzer pro Sekunde an.

  4. Klicken Sie anschließend auf Start swarming (Swarming starten), um mit der Simulation zu beginnen.

    Nachdem das Swarming von Anfragen begonnen hat, werden nach und nach Statistiken für Simulationsmesswerte zusammengefasst, z. B. die Summe der Anfragen und die Zahl der Anfragen pro Sekunde, wie in der folgenden Abbildung dargestellt:

    Die Locust-Weboberfläche zeigt an, dass die Statistiken mit der Aggregation beginnen.
  5. Klicken Sie auf Stop (Beenden), um den Test zu beenden.

Sie können sich den bereitgestellten Dienst und andere Messwerte über die GCP Console anzeigen lassen.

Das App Engine-Dashboard zeigt eine Grafik an, die eine Stunde von Anfragen abdeckt und sie nach Typ darstellt.

Anzahl der Nutzer hochskalieren (optional)

Wenn Sie eine erhöhte Last auf der Anwendung testen möchten, können Sie simulierte Nutzer hinzufügen. Bevor Sie simulierte Nutzer hinzufügen können, müssen Sie dafür sorgen, dass genügend Ressourcen vorhanden sind, um den Anstieg der Last bewältigen zu können. Mit der GCP können Sie dem Deployment Locust-Worker-Pods hinzufügen, ohne die vorhandenen Pods noch einmal bereitzustellen, sofern Sie die zugrunde liegenden VM-Ressourcen haben, um eine größere Anzahl von Pods zu unterstützen. Der anfängliche GKE-Cluster beginnt mit 3 Knoten und kann automatisch bis zu 10 Knoten skalieren.

  • Skalieren Sie den Pool von Locust-Worker-Pods auf 20.

    kubectl scale deployment/locust-worker --replicas=20
    

    Das Bereitstellen und Starten der neuen Pods dauert einige Minuten.

Wenn der Fehler Pod Unschedulable (Pod nicht planbar) angezeigt wird, müssen Sie dem Cluster weitere Rollen hinzufügen. Weitere Informationen finden Sie unter Größe von GKE-Clustern anpassen.

Kehren Sie nach dem Start der Pods zur Weboberfläche des Locust-Masters zurück und starten Sie den Lasttest noch einmal.

Muster erweitern

Sie können neue Locust-Aufgaben erstellen oder sogar zu einem anderen Lasttest-Framework wechseln, um dieses Muster zu erweitern.

Sie haben die Möglichkeit, die von Ihnen erfassten Messwerte anzupassen. So können Sie zum Beispiel die Anfragen pro Sekunde messen, die Antwortlatenz bei Erhöhung der Last überwachen oder die Ausfallraten und Fehlerarten bei Antworten überprüfen.

Weitere Informationen finden Sie in der Dokumentation zu Stackdriver Monitoring.

Bereinigen

Nachdem Sie die Anleitung abgeschlossen haben, können Sie die auf GCP erstellten Ressourcen bereinigen, sodass Ihnen diese nicht weiter in Rechnung gestellt werden.

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten, wenn Sie das zum Ausführen der Anleitung erstellte Projekt löschen.

So löschen Sie das Projekt:

  1. Rufen Sie in der GCP Console die Seite Ressourcen verwalten auf.

    Zur Seite "Ressourcen verwalten"

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie auf Löschen .
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Beenden, um das Projekt zu löschen.

GKE-Cluster löschen

Wenn Sie nicht das gesamte Projekt löschen möchten, können Sie den folgenden Befehl ausführen, um nur den GKE-Cluster zu löschen:

   gcloud container clusters delete $CLUSTER --zone $ZONE
   

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...