Lernpfad: Skalierbare Anwendungen – Skalierung

Autopilot

---

Diese Reihe von Anleitungen richtet sich an IT-Administratoren und Operatoren, die moderne Anwendungsumgebungen bereitstellen, ausführen und verwalten möchten, die in Google Kubernetes Engine (GKE) ausgeführt werden. In diesen Anleitungen erfahren Sie, wie Sie Monitoring und Benachrichtigungen konfigurieren, Arbeitslasten skalieren und Fehler simulieren – und zwar anhand der Beispiel-Mikrodienstanwendung „Cymbal Bank“:

1. Cluster erstellen und Beispielanwendung bereitstellen
2. Umgebungen mit Google Cloud Managed Service for Prometheus überwachen
3. Arbeitslasten skalieren (diese Anleitung)
4. Fehler simulieren

Übersicht und Ziele

Eine Verbraucheranwendung wie Cymbal Bank hat oft unterschiedliche Nutzerzahlen zu unterschiedlichen Zeiten. Im Idealfall kann Ihre Website einen Anstieg des Traffics bewältigen, ohne sich zu verlangsamen oder andere Probleme zu verursachen und ohne, dass das Unternehmen Geld für Cloud-Ressourcen ausgeben muss, die es nicht wirklich benötigt. Eine Lösung, die Google Cloud dafür bietet, ist die automatische Skalierung.

In dieser Anleitung erfahren Sie, wie Sie Cluster und Arbeitslasten in einem GKE-Cluster so konfigurieren, dass sie sowohl mithilfe von integrierten Kubernetes-Messwerten als auch benutzerdefinierten Messwerten aus Cloud Monitoring und Cloud Trace skaliert werden. Sie lernen, wie Sie die folgenden Aufgaben ausführen:

• Aktivieren Sie benutzerdefinierte Messwerte in Cloud Monitoring für Trace.
  • Mit benutzerdefinierten Messwerten können Sie mit zusätzlichen Monitoring-Daten oder externen Eingaben skalieren, die nicht vom Kubernetes-Cluster erfasst werden, z. B. Netzwerkverkehr oder HTTP-Antwortcodes.
• Konfigurieren Sie das horizontale Pod-Autoscaling, eine GKE-Funktion, mit der die Anzahl der Pods für eine Arbeitslast je nach angegebenen Messwerten automatisch erhöht oder verringert werden kann.
• Simulieren Sie die Anwendungslast und sehen Sie sich an, wie der Cluster-Autoscaler und der horizontale Pod-Autoscaler reagieren.

Kosten

Wenn Sie GKE aktivieren und die Beispielanwendung „Cymbal Bank“ für diese Reihe von Anleitungen bereitstellen, fallen für GKE in Google Cloud Gebühren pro Cluster an. Weitere Informationen finden Sie auf der Preisseite, bis Sie GKE deaktivieren oder das Projekt löschen.

Sie sind auch für andere Google Cloud-Kosten verantwortlich, die während der Ausführung der Cymbal Bank-Beispielanwendung anfallen, z. B. Gebühren für Compute Engine-VMs und Trace.

Vorbereitung

Wenn Sie erfahren möchten, wie Sie Ihre Bereitstellungen skalieren, müssen Sie die erste Anleitung zum Erstellen eines GKE-Clusters mit Autopilot und zum Bereitstellen der auf Mikrodiensten basierenden Beispielanwendung „Cymbal Bank“ durcharbeiten.

Wir empfehlen Ihnen, diese Reihe von Anleitungen für skalierbare Apps in der richtigen Reihenfolge durchzugehen. Während Sie die einzelnen Anleitungen durcharbeiten, lernen Sie neue Fähigkeiten kennen und nutzen zusätzliche Google Cloud-Produkte und -Dienste.

Außerdem müssen Sie ein IAM-Dienstkonto erstellen und einige Berechtigungen erteilen, damit das horizontale Pod-Autoscaling ordnungsgemäß funktioniert:

1. IAM-Dienstkonto erstellen. Mit diesem Dienstkonto wird in der Anleitung Zugriff auf benutzerdefinierte Messwerte gewährt, mit denen der Horizontal Pod Autoscaler bestimmen kann, wann hoch- oder herunterskaliert werden soll:

   gcloud iam service-accounts create scalable-apps
   

2. Gewähren Sie dem IAM-Dienstkonto Zugriff, um die erforderlichen Skalierungsaktionen auszuführen:

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --role roles/cloudtrace.agent \
     --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com"
   
   gcloud projects add-iam-policy-binding PROJECT_ID \
     --role roles/monitoring.metricWriter \
     --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com"
   
   gcloud iam service-accounts add-iam-policy-binding "scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
     --role roles/iam.workloadIdentityUser \
     --member "serviceAccount:PROJECT_ID.svc.id.goog[default/default]"
   

   Dem IAM-Dienstkonto wird folgender Zugriff gewährt:

   • roles/cloudtrace.agent: Trace-Daten wie Latenzinformationen in Trace schreiben.
   • roles/monitoring.metricWriter: Messwerte in Cloud Monitoring schreiben.
   • roles/iam.workloadIdentityUser: Einem Kubernetes-Dienstkonto erlauben, die Workload Identity-Föderation für GKE zu verwenden, um als IAM-Dienstkonto zu fungieren.

3. Konfigurieren Sie das Kubernetes-Dienstkonto default im Namespace default so, dass es als von Ihnen erstelltes IAM-Dienstkonto fungiert:

   kubectl annotate serviceaccount default \
       iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
   

   Durch diese Konfiguration können Pods, die das Kubernetes-Dienstkonto default im Namespace default verwenden, auf dieselben Google Cloud-Ressourcen wie das IAM-Dienstkonto zugreifen.

Erfassung benutzerdefinierter Messwerte einrichten

Sie können den horizontalen Pod-Autoscaler so konfigurieren, dass er die grundlegenden integrierten CPU- und Arbeitsspeichermesswerte von Kubernetes verwendet. Sie können aber auch benutzerdefinierte Messwerte aus Cloud Monitoring verwenden, z. B. HTTP-Anfragen pro Sekunde oder die Anzahl der SELECT-Anweisungen. Benutzerdefinierte Messwerte können ohne Anwendungsänderungen verwendet werden und bieten Ihrem Cluster mehr Einblicke in die Gesamtleistung und Anforderungen der Anwendung. In dieser Anleitung erfahren Sie, wie Sie sowohl die integrierten als auch die benutzerdefinierten Messwerte verwenden.

1. Damit der Horizontal Pod Autoscaler benutzerdefinierte Messwerte aus Monitoring lesen kann, müssen Sie den Adapter Benutzerdefinierte Messwerte – Stackdriver-Adapter in Ihrem Cluster installieren.

   Stellen Sie den Stackdriver-Adapter für benutzerdefinierte Messwerte in Ihrem Cluster bereit:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-stackdriver/master/custom-metrics-stackdriver-adapter/deploy/production/adapter.yaml
   

2. Damit der Stackdriver-Adapter benutzerdefinierte Messwerte aus Ihrem Cluster abrufen kann, verwenden Sie die Workload Identity Federation for GKE. Bei diesem Ansatz wird ein IAM-Dienstkonto verwendet, das Berechtigungen zum Lesen von Monitoring-Messwerten hat.

   Weisen Sie dem IAM-Dienstkonto die Rolle roles/monitoring.viewer zu:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member "serviceAccount:scalable-apps@PROJECT_ID.iam.gserviceaccount.com" \
       --role roles/monitoring.viewer
   

3. Konfigurieren Sie den Stackdriver-Adapter für die Verwendung der Workload Identity-Föderation für GKE und des IAM-Dienstkontos, das Berechtigungen zum Lesen der Monitoring-Messwerte hat:

   gcloud iam service-accounts add-iam-policy-binding scalable-apps@PROJECT_ID.iam.gserviceaccount.com \
       --role roles/iam.workloadIdentityUser \
       --member "serviceAccount:PROJECT_ID.svc.id.goog[custom-metrics/custom-metrics-stackdriver-adapter]"
   

4. Kubernetes hat ein eigenes System für Dienstkonten für den Zugriff innerhalb eines Clusters. Damit sich Ihre Anwendungen bei Diensten und Ressourcen außerhalb Ihrer Google Kubernetes Engine-Cluster wie Monitoring authentifizieren können, verwenden Sie die Workload Identity-Föderation für GKE. Bei diesem Ansatz wird das Kubernetes-Dienstkonto so konfiguriert, dass es das IAM-Dienstkonto für GKE verwendet.

   Annotieren Sie dann das vom Adapter verwendete Kubernetes-Dienstkonto:

   kubectl annotate serviceaccount custom-metrics-stackdriver-adapter \
       --namespace=custom-metrics \
       iam.gke.io/gcp-service-account=scalable-apps@PROJECT_ID.iam.gserviceaccount.com
   

5. Starten Sie das Stackdriver-Adapter-Deployment neu, um die Änderungen zu übernehmen:

   kubectl rollout restart deployment custom-metrics-stackdriver-adapter \
       --namespace=custom-metrics
   

Ziel: Herzlichen Glückwunsch! Sie haben jetzt einen Stackdriver-Adapter in Ihrem GKE-Cluster, der so konfiguriert ist, dass benutzerdefinierte Messwerte aus Monitoring gelesen werden.

Horizontales Pod-Autoscaling konfigurieren

GKE Autopilot kann auf verschiedene Arten skaliert werden. In diesem Tutorial erfahren Sie, wie Sie Ihren Cluster mit den folgenden Methoden skalieren können:

• Horizontaler Pod-Autoscaler: Skaliert die Anzahl der Pods für eine Arbeitslast.
• Cluster Autoscaler: Skaliert die im Cluster verfügbaren Knotenressourcen.

Diese beiden Methoden können zusammen verwendet werden, sodass sich, wenn sich die Anzahl der Pods für Ihre Anwendungen ändert, die Knotenressourcen zur Unterstützung dieser Pods ändern.

Mit anderen verfügbaren Implementierungen können Sie Pods skalieren, die auf dem horizontalen Pod-Autoscaling aufbauen. Außerdem können Sie mithilfe von vertikalem Pod-Autoscaling die CPU- und Speicheranforderungen eines Pods anstelle der Anzahl der Pods anpassen.

In dieser Anleitung konfigurieren Sie das horizontale Pod-Autoscaling für das userservice-Deployment mithilfe integrierter Messwerte und für das frontend-Deployment mithilfe benutzerdefinierter Messwerte.

Ermitteln Sie für Ihre eigenen Anwendungen die Anforderungen Ihrer Anwendungsentwickler und Plattformingenieure und konfigurieren Sie die Regeln für das horizontale Pod-Autoscaling.

userservice-Deployment skalieren

Wenn die Anzahl der Nutzer der Beispielanwendung „Cymbal Bank“ zunimmt, verbraucht der userservice-Dienst mehr CPU-Ressourcen. Mit einem HorizontalPodAutoscaler-Objekt können Sie festlegen, wie Ihre Anwendung auf Last reagieren soll. Im YAML-Manifest für HorizontalPodAutoscaler definieren Sie, welches Deployment für das horizontale Pod-Autoscaling skaliert werden soll, welche Messwerte überwacht werden sollen sowie die minimale und maximale Anzahl von Replikaten, die Sie ausführen möchten.

1. Sehen Sie sich das Beispielmanifest HorizontalPodAutoscaler für das Deployment userservice an:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: userservice
   spec:
     behavior:
       scaleUp:
         stabilizationWindowSeconds: 0
         policies:
           - type: Percent
             value: 100
             periodSeconds: 5
         selectPolicy: Max
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: userservice
     minReplicas: 5
     maxReplicas: 50
     metrics:
       - type: Resource
         resource:
           name: cpu
           target:
             type: Utilization
             averageUtilization: 60
   

   Das Manifest tut Folgendes:

   • Legt die maximale Anzahl von Replikaten beim Hochskalieren auf 50 fest.
   • Legt die Mindestanzahl von Replikaten beim Herunterskalieren auf 5 fest.
   • Verwendet einen integrierten Kubernetes-Messwert, um Skalierungsentscheidungen zu treffen. In diesem Beispiel ist der Messwert die CPU-Auslastung und die Zielauslastung beträgt 60 %. Damit werden eine Über- und eine Unterauslastung vermieden.

2. Wenden Sie das Manifest auf den Cluster an:

   kubectl apply -f extras/postgres-hpa/hpa/userservice.yaml
   

frontend-Deployment skalieren

Im vorherigen Abschnitt haben Sie das horizontale Pod-Autoscaling im userservice-Deployment anhand der integrierten Kubernetes-Messwerte für die CPU-Auslastung konfiguriert. Für die Bereitstellung von frontend sollten Sie stattdessen basierend auf der Anzahl der eingehenden HTTP-Anfragen skalieren. Bei diesem Ansatz werden benutzerdefinierte Messwerte aus Monitoring für das HTTP(S) Load Balancer-Ingress-Objekt mit dem Stackdriver-Adapter gelesen.

1. Überprüfen Sie das HorizontalPodAutoscaler-Manifest für das frontend-Deployment:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   ---
   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: frontend
   spec:
     behavior:
       scaleUp:
         stabilizationWindowSeconds: 0
         policies:
           - type: Percent
             value: 100
             periodSeconds: 5
         selectPolicy: Max
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: frontend
     minReplicas: 5
     maxReplicas: 25
     metrics:
       - type: External
         external:
           metric:
             name: loadbalancing.googleapis.com|https|request_count
             selector:
               matchLabels:
                 resource.labels.forwarding_rule_name: FORWARDING_RULE_NAME
           target:
             type: AverageValue
             averageValue: "5"
   

   Dieses Manifest verwendet die folgenden Felder:

   • spec.scaleTargetRef: Die Kubernetes-Ressource, die skaliert werden soll.
   • spec.minReplicas: Die Mindestanzahl von Replikaten, also 5 in diesem Beispiel.
   • spec.maxReplicas: Die maximale Anzahl von Replikaten, also 25 in diesem Beispiel.
   • spec.metrics.*: Der zu verwendende Messwert. In diesem Beispiel ist dies die Anzahl der HTTP-Anfragen pro Sekunde, ein benutzerdefinierter Messwert von Monitoring, der von dem von Ihnen bereitgestellten Adapter zur Verfügung gestellt wird.
   • spec.metrics.external.metric.selector.matchLabels: Das spezifische Ressourcenlabel, nach dem beim Scaling gefiltert werden soll.

2. Suchen Sie den Namen der Weiterleitungsregel vom frontend-Ingress-Load Balancer:

   export FW_RULE=$(kubectl get ingress frontend -o=jsonpath='{.metadata.annotations.ingress\.kubernetes\.io/forwarding-rule}')
   echo $FW_RULE
   

   Die Ausgabe sieht in etwa so aus:

   k8s2-fr-j76hrtv4-default-frontend-wvvf7381
   

3. Fügen Sie dem Manifest Ihre Weiterleitungsregel hinzu:

   sed -i "s/FORWARDING_RULE_NAME/$FW_RULE/g" "extras/postgres-hpa/hpa/frontend.yaml"
   

   Mit diesem Befehl wird FORWARDING_RULE_NAME durch Ihre gespeicherte Weiterleitungsregel ersetzt.

4. Wenden Sie das Manifest auf den Cluster an:

   kubectl apply -f extras/postgres-hpa/hpa/frontend.yaml
   

Ziel: Herzlichen Glückwunsch! Sie haben jetzt Regeln für das horizontale Pod-Autoscaling für Deployments in Ihrem GKE-Cluster mithilfe von integrierten Messwerten aus Kubernetes und benutzerdefinierten Messwerten aus Monitoring konfiguriert.

Last simulieren

In diesem Abschnitt verwenden Sie einen Lastgenerator, um Traffic-Spitzen zu simulieren und zu beobachten, wie die Anzahl der Replikate und die Knotenanzahl vertikal skaliert werden, um die erhöhte Last im Laufe der Zeit zu bewältigen. Anschließend können Sie das Generieren von Traffic beenden und beobachten, wie die Replikat- und die Knotenanzahl als Reaktion herunterskaliert werden.

1. Prüfen Sie vor Beginn den Status des horizontalen Pod-Autoscalings und sehen Sie sich die Anzahl der verwendeten Replikate an.

   Rufen Sie den Zustand Ihrer HorizontalPodAutoscaler-Ressourcen ab:

   kubectl get hpa
   

   Die Ausgabe sieht etwa wie unten aus. Hier wird gezeigt, dass 1 frontend-Replikat und 5 userservice-Replikate vorhanden sind.

   NAME                     REFERENCE                            TARGETS             MINPODS   MAXPODS   REPLICAS   AGE
   frontend                 Deployment/frontend                  <unknown>/5 (avg)   5         25        1          34s
   userservice              Deployment/userservice               0%/60%              5         50        5          4m56s
   

2. Die Beispielanwendung „Cymbal Bank“ enthält einen loadgenerator-Dienst. Dieser Dienst sendet kontinuierlich Anfragen, die Nutzer imitieren, an das Frontend und erstellt regelmäßig neue Konten und simuliert Transaktionen zwischen ihnen.

   Machen Sie die loadgenerator-Weboberfläche lokal verfügbar. Über diese Benutzeroberfläche simulieren Sie eine Last für die Beispielanwendung „Cymbal Bank“:

   kubectl port-forward svc/loadgenerator 8080
   

   Wenn eine Fehlermeldung angezeigt wird, versuchen Sie es noch einmal, wenn der Pod ausgeführt wird.

3. Öffnen Sie in einem Browser auf Ihrem Computer die Weboberfläche des Lastgenerators:

   • Wenn Sie eine lokale Shell verwenden, öffnen Sie einen Browser und rufen Sie http://127.0.0.1:8080 auf.
   • Wenn Sie Cloud Shell verwenden, klicken Sie auf Webvorschau und dann auf Vorschau auf Port 8080.

4. Wenn der Wert Fehler in der Weboberfläche des Lastgenerators 100% anzeigt, führen Sie die folgenden Schritte aus, um die Testeinstellungen zu aktualisieren:

   1. Klicken Sie neben dem Zähler für die Ausfallrate auf die Schaltfläche Beenden.
   2. Klicken Sie unter Status auf die Option Neuer Test.
   3. Aktualisieren Sie den Wert Host auf die IP-Adresse Ihres Cymbal Bank-Ingress.
   4. Klicken Sie auf Start swarming (Swarm starten).

5. Klicken Sie in der Weboberfläche des Lastgenerators auf den Tab Diagramme, um die Leistung im Zeitverlauf zu beobachten. Sehen Sie sich die Anzahl der Anfragen und die Ressourcennutzung an.

6. Öffnen Sie ein neues Terminalfenster und beobachten Sie die Anzahl der Replikate Ihrer frontend- und userservice-Pods:

   kubectl get hpa -w
   

   Die Anzahl der Replikate erhöht sich, wenn die Last zunimmt. Die scaleUp-Aktionen können etwa zehn Minuten dauern, da der Cluster erkennt, dass die konfigurierten Messwerte den definierten Grenzwert erreichen und das horizontale Pod-Autoscaling verwendet wird, um die Anzahl der Pods hochzuskalieren.

   Die folgende Beispielausgabe zeigt, dass sich die Anzahl der Replikate während des Betriebs des Last Generators erhöht hat:

   NAME                     REFERENCE                            TARGETS          MINPODS   MAXPODS   REPLICAS
   frontend                 Deployment/frontend                  5200m/5 (avg)    5         25        13
   userservice              Deployment/userservice               71%/60%          5         50        17
   

7. Öffnen Sie ein anderes Terminalfenster und prüfen Sie die Anzahl der Knoten im Cluster:

   gcloud container clusters list \
       --filter='name=scalable-apps' \
       --format='table(name, currentMasterVersion, currentNodeVersion, currentNodeCount)' \
       --region="REGION"
   

   Ersetzen Sie REGION durch die Region, in der Ihr Cluster ausgeführt wird.

   Die Anzahl der Knoten wurde ebenfalls von der Startmenge aus erhöht, um die neuen Replikate unterzubringen. Diese Erhöhung der Anzahl der Knoten wird durch GKE Autopilot ermöglicht. Für diese Knotenskala müssen Sie nichts konfigurieren.

8. Öffnen Sie die Benutzeroberfläche des Lastgenerators und klicken Sie auf Beenden, um den Test zu beenden.

9. Prüfen Sie die Replikatanzahl und die Knotenanzahl noch einmal und beobachten Sie, wie sich die Zahlen mit der geringeren Last verringern. Das Herunterskalieren kann einige Zeit dauern, da das standardmäßige Stabilisierungsfenster für Replikate in der Kubernetes-HorizontalPodAutoscaler-Ressource fünf Minuten beträgt.

In einer echten Umgebung würden sowohl die Anzahl der Knoten als auch die der Pods in Ihrer Umgebung automatisch auf die gleiche Weise wie bei dieser simulierten Last skaliert. Die Beispielanwendung „Cymbal Bank“ ist für diese Art der Skalierung ausgelegt. Fragen Sie Ihre App-Betreiber und Site Reliability Engineers (SREs) oder Anwendungsentwickler, ob ihre Arbeitslasten von diesen Skalierungsfunktionen profitieren können.

Ziel: Herzlichen Glückwunsch! Sie können GKE jetzt so konfigurieren, dass es je nach Last skaliert, einschließlich anhand benutzerdefinierter Messwerte aus Monitoring.

Bereinigen

Die Cymbal Bank-Anleitungen sind so konzipiert, dass sie nacheinander abgeschlossen werden. Während Sie die einzelnen Anleitungen durcharbeiten, lernen Sie neue Fähigkeiten kennen und nutzen zusätzliche Google Cloud-Produkte und -Dienste.

Wenn Sie eine Pause beim Durcharbeiten der Anleitungen einlegen möchten und nicht möchten, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden, löschen Sie das erstellte Projekt.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

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.

Nächste Schritte

In der nächsten Anleitung erfahren Sie, wie Sie einen Ausfall in GKE simulieren.