Verteilte Lasttests mit Google Kubernetes Engine

Last reviewed 2024-08-13 UTC

In diesem Dokument wird erläutert, wie Sie mit der 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 diesem Dokument wird eine in der App Engine bereitgestellte Webanwendung mit REST-Endpunkten für eingehende HTTP-POST-Anfragen unter Last getestet.

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 diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

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

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Vorbereitung

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the App Engine, Artifact Registry, Cloud Build, Compute Engine, Resource Manager, Google Kubernetes Engine, and Identity and Access Management APIs.

    Enable the APIs

    5.

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  6. Make sure that billing is enabled for your Google Cloud project.

  7. Enable the App Engine, Artifact Registry, Cloud Build, Compute Engine, Resource Manager, Google Kubernetes Engine, and Identity and Access Management APIs.

    Enable the APIs

    8.

    Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

  8. Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/serviceusage.serviceUsageAdmin, roles/container.admin, roles/appengine.appAdmin, roles/appengine.appCreator, roles/artifactregistry.admin, roles/resourcemanager.projectIamAdmin, roles/compute.instanceAdmin.v1, roles/iam.serviceAccountUser, roles/cloudbuild.builds.builder, roles/iam.serviceAccountAdmin 

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
    • Replace PROJECT_ID with your project ID.

    • Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.

    • Replace ROLE with each individual role.

Beispielarbeitslast

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 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 diesem Dokument 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 Client-Anfragen 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 primären Lasttest bereit, der von Locust als Master bezeichnet wird.
  2. Stellen Sie eine Gruppe von Lasttest-Workern bereit. Mit diesen Lasttest-Workern können Sie eine erhebliche Menge an Traffic zu Testzwecken generieren.

Das folgende Diagramm zeigt die Architektur, die Lasttests mit einer Beispielanwendung veranschaulicht. Der Master-Pod stellt die Weboberfläche bereit, die zum Ausführen und Überwachen von Lasttests verwendet wird. Die Worker-Pods generieren den REST-Anfrage-Traffic für die zu testende Anwendung und senden Messwerte an den Master.

Der primäre Pod stellt die Weboberfläche bereit, die zum Ausführen und Überwachen von Lasttests verwendet wird. Die Worker-Pods generieren den REST-Anfrage-Traffic für die Anwendung, die getestet wird.

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 vom Container verwendeten Standardports:

  • 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 Service bereit, damit die nötigen Ports über hostname:port für andere Pods im Cluster zugänglich sind. Die Ports können auch über einen beschreibenden Portnamen referenziert werden.

Mit diesem Service können die Locust-Worker den Master einfach erkennen und zuverlässig mit ihm kommunizieren, auch wenn der Master ausfällt und vom Deployment durch einen neuen Pod ersetzt wird.

Ein zweiter Service wird mit der erforderlichen Annotation bereitgestellt, um einen internen Passthrough-Network-Load-Balancer zu erstellen, der den Locust-Webanwendungsdienst für Clients außerhalb Ihres Clusters zugänglich macht, die dasselbe VPC-Netzwerk verwenden und sich in derselben Google Cloud-Region wie Ihr Cluster befinden.

Nachdem Sie den Locust-Master bereitgestellt haben, können Sie die Weboberfläche über die interne IP-Adresse öffnen, die vom internen Passthrough-Network Load Balancer bereitgestellt wird. 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:

    Cloud Shell öffnen

    Alle Terminalbefehle in diesem Dokument werden über Cloud Shell ausgeführt.

  2. Legen Sie die Umgebungsvariablen fest, die angepasst werden müssen:

    export GKE_CLUSTER=GKE_CLUSTER
export AR_REPO=AR_REPO
export REGION=REGION
export ZONE=ZONE
export SAMPLE_APP_LOCATION=SAMPLE_APP_LOCATION

    Ersetzen Sie Folgendes:

    • GKE_CLUSTER: der Name Ihres GKE-Cluster.
    • AR_REPO: der Name Ihres Artifact Registry-Repositorys
    • REGION: die Region, in der Ihr GKE-Cluster und das Artifact Registry-Repository erstellt werden.
    • ZONE: die Zone in Ihrer Region, in der Ihre Compute Engine-Instanz erstellt wird.
    • SAMPLE_APP_LOCATION: der (regionale) Standort, an dem die App Engine-Beispielanwendung bereitgestellt wird

    Die Befehle sollten wie im folgenden Beispiel aussehen:

    export GKE_CLUSTER=gke-lt-cluster
export AR_REPO=dist-lt-repo
export REGION=us-central1
export ZONE=us-central1-b
export SAMPLE_APP_LOCATION=us-central

  3. Legen Sie die folgenden zusätzlichen Umgebungsvariablen fest:

    export GKE_NODE_TYPE=e2-standard-4
export GKE_SCOPE="https://www.googleapis.com/auth/cloud-platform"
export PROJECT=$(gcloud config get-value project)
export SAMPLE_APP_TARGET=${PROJECT}.appspot.com

  4. Legen Sie die Standardzone fest, damit Sie diese Werte nicht in nachfolgenden Befehlen angeben müssen:

    gcloud config set compute/zone ${ZONE}

GKE-Cluster erstellen

  1. Erstellen Sie ein Dienstkonto mit den für den Cluster erforderlichen Mindestberechtigungen:

    gcloud iam service-accounts create dist-lt-svc-acc
gcloud projects add-iam-policy-binding  ${PROJECT} --member=serviceAccount:dist-lt-svc-acc@${PROJECT}.iam.gserviceaccount.com --role=roles/artifactregistry.reader
gcloud projects add-iam-policy-binding  ${PROJECT} --member=serviceAccount:dist-lt-svc-acc@${PROJECT}.iam.gserviceaccount.com --role=roles/container.nodeServiceAccount

  2. Erstellen Sie den GKE-Cluster:

    gcloud container clusters create ${GKE_CLUSTER} \
--service-account=dist-lt-svc-acc@${PROJECT}.iam.gserviceaccount.com \
--region ${REGION} \
--machine-type ${GKE_NODE_TYPE} \
--enable-autoscaling \
--num-nodes 3 \
--min-nodes 3 \
--max-nodes 10 \
--scopes "${GKE_SCOPE}"

  3. Stellen Sie eine Verbindung zum GKE-Cluster her:

    gcloud container clusters get-credentials ${GKE_CLUSTER} \
   --region ${REGION} \
   --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

Container-Image erstellen

  1. Erstellen Sie ein Artifact Registry-Repository:

    gcloud artifacts repositories create ${AR_REPO} \
    --repository-format=docker  \
    --location=${REGION} \
    --description="Distributed load testing with GKE and Locust"

  2. Erstellen Sie das Container-Image und speichern Sie es in Ihrem Artifact Registry-Repository:

    export LOCUST_IMAGE_NAME=locust-tasks
export LOCUST_IMAGE_TAG=latest
gcloud builds submit \
    --tag ${REGION}-docker.pkg.dev/${PROJECT}/${AR_REPO}/${LOCUST_IMAGE_NAME}:${LOCUST_IMAGE_TAG} \
    docker-image

    Das zugehörige Locust-Docker-Image bettet eine Testaufgabe ein, die die Endpunkte /login und /metrics in der Beispielanwendung aufruft. In diesem Beispielsatz von Testaufgaben beträgt das jeweilige Verhältnis von Anfragen, die an diese beiden Endpunkte gesendet werden, 1 zu 999. 

    
class MetricsTaskSet(TaskSet):
    _deviceid = None

    def on_start(self):
        self._deviceid = str(uuid.uuid4())

    @task(1)
    def login(self):
        self.client.post(
            '/login', {"deviceid": self._deviceid})

    @task(999)
    def post_metrics(self):
        self.client.post(
            "/metrics", {"deviceid": self._deviceid, "timestamp": datetime.now()})


class MetricsLocust(FastHttpUser):
    tasks = {MetricsTaskSet}

  3. Prüfen Sie, ob sich das Docker-Image in Ihrem Artifact Registry-Repository befindet:

    gcloud artifacts docker images list ${REGION}-docker.pkg.dev/${PROJECT}/${AR_REPO} | \
    grep ${LOCUST_IMAGE_NAME}

    Die entsprechende Ausgabe sieht etwa so aus:

    Listing items under project PROJECT, location REGION, repository AR_REPO

REGION-docker.pkg.dev/PROJECT/AR_REPO/locust-tasks  sha256:796d4be067eae7c82d41824791289045789182958913e57c0ef40e8d5ddcf283  2022-04-13T01:55:02  2022-04-13T01:55:02

Beispielanwendung bereitstellen

  1. Erstellen Sie die Beispiel-Webapp als App Engine und stellen Sie sie bereit:

    gcloud app create --region=${SAMPLE_APP_LOCATION}
gcloud app deploy sample-webapp/app.yaml \
--project=${PROJECT}

  2. Geben Sie bei Aufforderung y ein, um mit der Bereitstellung fortzufahren.

    Die Ausgabe sieht in etwa so aus:

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

    Die App Engine-Beispielanwendung implementiert die Endpunkte /login und /metrics: 

    @app.route('/login',  methods=['GET', 'POST'])
def login():
    deviceid = request.values.get('deviceid')
    return '/login - device: {}\n'.format(deviceid)

@app.route('/metrics',  methods=['GET', 'POST'])
def metrics():
    deviceid = request.values.get('deviceid')
    timestamp = request.values.get('timestamp')

    return '/metrics - device: {}, timestamp: {}\n'.format(deviceid, timestamp)

Stellen Sie den Locust-Master und Worker-Pods bereit:

  1. Ersetzen Sie die Umgebungsvariablenwerte für die Zielhost-, Projekt- und Image-Parameter in den locust-master-controller.yaml- und locust-worker-controller.yaml-Dateien und erstellen Sie die Locust-Master- und -Worker-Deployments:

    envsubst < kubernetes-config/locust-master-controller.yaml.tpl | kubectl apply -f -
envsubst < kubernetes-config/locust-worker-controller.yaml.tpl | kubectl apply -f -
envsubst < kubernetes-config/locust-master-service.yaml.tpl | kubectl apply -f -

  2. Überprüfen Sie die Locust-Deployments:

    kubectl get pods -o wide

    Die Ausgabe sollte in etwa so aussehen:

    NAME                             READY   STATUS    RESTARTS   AGE   IP           NODE
locust-master-87f8ffd56-pxmsk    1/1     Running   0          1m    10.32.2.6    gke-gke-load-test-default-pool-96a3f394
locust-worker-58879b475c-279q9   1/1     Running   0          1m    10.32.1.5    gke-gke-load-test-default-pool-96a3f394
locust-worker-58879b475c-9frbw   1/1     Running   0          1m    10.32.2.8    gke-gke-load-test-default-pool-96a3f394
locust-worker-58879b475c-dppmz   1/1     Running   0          1m    10.32.2.7    gke-gke-load-test-default-pool-96a3f394
locust-worker-58879b475c-g8tzf   1/1     Running   0          1m    10.32.0.11   gke-gke-load-test-default-pool-96a3f394
locust-worker-58879b475c-qcscq   1/1     Running   0          1m    10.32.1.4    gke-gke-load-test-default-pool-96a3f394

  3. Überprüfen Sie die Dienste:

    kubectl get services

    Die Ausgabe sollte in etwa so aussehen:

    NAME                TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
kubernetes          ClusterIP      10.87.240.1     <none>        443/TCP             12m
locust-master       ClusterIP      10.87.245.22    <none>        5557/TCP,5558/TCP    1m
locust-master-web   LoadBalancer   10.87.246.225   <pending>     8089:31454/TCP       1m

  4. Führen Sie eine Überwachungsschleife aus, während die interne IP-Adresse des internen Passthrough-Network Load Balancers (externe GKE-IP-Adresse) für den Locust-Master-Webanwendungs-Service bereitgestellt wird:

    kubectl get svc locust-master-web --watch

  5. Drücken Sie Ctrl+C, um die Überwachungsschleife zu beenden, sobald eine EXTERNAL-IP-Adresse bereitgestellt wurde.

Verbindung zum Locust-Web-Frontend herstellen

Mithilfe der Weboberfläche des Locust-Masters führen Sie die Lasttestaufgaben mit dem zu testenden System aus.

  1. Notieren Sie sich die interne Load-Balancer-IP-Adresse des Webhostdienstes:

    export INTERNAL_LB_IP=$(kubectl get svc locust-master-web  \
                               -o jsonpath="{.status.loadBalancer.ingress[0].ip}") && \
                               echo $INTERNAL_LB_IP

  2. Abhängig von Ihrer Netzwerkkonfiguration gibt es zwei Möglichkeiten, über die bereitgestellte IP-Adresse eine Verbindung zur Locust-Webanwendung herzustellen:

    • Netzwerk-Routing: Wenn Ihr Netzwerk so konfiguriert ist, dass das Routing von Ihrer Workstation zu Ihrem VPC-Netzwerk möglich ist, können Sie direkt von Ihrer Workstation auf die IP-Adresse des internen Passthrough-Network Load Balancers zugreifen.

    • Proxy und SSH-Tunnel: Wenn keine Netzwerkroute zwischen Ihrer Workstation und Ihrem VPC-Netzwerk vorhanden ist, können Sie den Traffic an die IP-Adresse des internen Passthrough-Network Load Balancers weiterleiten. Dazu erstellen Sie eine Compute Engine-Instanz mit einem nginx-Proxy und einen SSH-Tunnel zwischen Ihrer Workstation und der Instanz.

Netzwerk-Routing

Wenn eine Route für Netzwerk-Traffic zwischen Ihrer Workstation und dem VPC-Netzwerk des Google Cloud-Projekts vorhanden ist, öffnen Sie Ihren Browser und anschließend die Weboberfläche des Locust-Masters. Rufen Sie die folgende URL auf, um die Locust-Benutzeroberfläche zu öffnen:

http://INTERNAL_LB_IP:8089

Ersetzen Sie INTERNAL_LB_IP durch die URL und IP-Adresse, die Sie im vorherigen Schritt notiert haben.

Proxy und SSH-Tunnel

  1. Legen Sie eine Umgebungsvariable mit dem Namen der Instanz fest.

    export PROXY_VM=locust-nginx-proxy

  2. Starten Sie eine Instanz mit einem ngnix-Docker-Container, der dafür konfiguriert ist, beim internen Passthrough-Network Load Balancer für den Locust-Webanwendungsport 8089 als Proxy zu dienen:

    gcloud compute instances create-with-container ${PROXY_VM} \
   --zone ${ZONE} \
   --container-image gcr.io/cloud-marketplace/google/nginx1:latest \
   --container-mount-host-path=host-path=/tmp/server.conf,mount-path=/etc/nginx/conf.d/default.conf \
   --metadata=startup-script="#! /bin/bash
     cat <<EOF  > /tmp/server.conf
     server {
         listen 8089;
         location / {
             proxy_pass http://${INTERNAL_LB_IP}:8089;
         }
     }
EOF"

  3. Öffnen Sie einen SSH-Tunnel von Cloud Shell zur Proxy-Instanz:

    gcloud compute ssh --zone ${ZONE} ${PROXY_VM} \
                 -- -N -L 8089:localhost:8089

  4. Klicken Sie auf das Symbol Webvorschau (Symbol: Cloud Shell-Webvorschau) und wählen Sie aus den aufgeführten Optionen Port ändern aus.

  5. Geben Sie auf dem Dialogfeld Vorschauport ändern 8.089 im Feld Portnummer ein und wählen Sie Ändern und Vorschau.

    Nach kurzer Zeit wird mit der Locust-Weboberfläche ein Browsertab geöffnet.

Einfachen Lasttest für Ihre Beispielanwendung ausführen

  1. Nachdem Sie das Locust-Frontend in Ihrem Browser geöffnet haben, wird ein Dialogfeld angezeigt, mit dem ein neuer Lasttest gestartet werden kann.

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

  2. Geben Sie unter Gesamtanzahl der Nutzer (Spitzen Gleichzeitigkeit) die Option 10 und die Spawn-Rate (gestartete Nutzer/Sekunden) als 5-Nutzer pro Sekunde ein.

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

  4. Sehen Sie sich den bereitgestellten Dienst und andere Messwerte über die Google Cloud Console an.

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

  5. Wenn Sie das Verhalten der zu testenden Anwendung beobachtet haben, klicken Sie auf Beenden, um den Test zu beenden.

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 Google Cloud können Sie Locust-Worker-Pods dem Deployment hinzufügen, ohne die vorhandenen Pods noch einmal bereitstellen zu müssen, solange 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 Deployment und Starten der neuen Pods dauert einige Minuten.

Wenn der Fehler Pod Unschedulable angezeigt wird, müssen Sie dem Cluster weitere Knoten 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 beobachten oder die Ausfallraten und Fehlerarten bei Antworten prüfen.

Weitere Informationen finden Sie in der Dokumentation zu Cloud Monitoring.

Bereinigen

Damit Ihrem Google Cloud-Konto die in diesem Dokument verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder behalten Sie das Projekt und löschen Sie die einzelnen Ressourcen.

Projekt löschen

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

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 ${GKE_CLUSTER} --region ${REGION}

Weitere Informationen