Lernpfad: Skalierbare Anwendungen – Skalierung

---

Diese Reihe von Anleitungen richtet sich an IT-Administratoren und Operatoren, die moderne Anwendungsumgebungen in Google Kubernetes Engine (GKE) Enterprise Edition bereitstellen, ausführen und verwalten möchten. Im weiteren Verlauf dieser Anleitungen erfahren Sie, wie Sie mit der Beispiel-Mikrodienstanwendung "Cymbal Bank" Monitoring und Benachrichtigungen konfigurieren, Arbeitslasten skalieren und Fehler simulieren:

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 von Google Cloud bereitgestellte Lösung ist Autoscaling.

In dieser Anleitung erfahren Sie, wie Sie Cluster und Arbeitslasten in einem GKE-Cluster konfigurieren, um sie sowohl mit integrierten Kubernetes-Messwerten als auch mit benutzerdefinierten Messwerten aus Cloud Monitoring und Cloud Trace zu skalieren. Sie erfahren, wie Sie die folgenden Aufgaben ausführen:

• Benutzerdefinierte Messwerte in Cloud Monitoring für Trace aktivieren
  • Mit benutzerdefinierten Messwerten können Sie die Skalierung mit zusätzlichen Monitoringdaten oder externen Eingaben ausführen, die über die Erkennung des Kubernetes-Clusters hinausgehen, z. B. Netzwerktraffic oder HTTP-Antwortcodes.
• Konfigurieren Sie das horizontale Pod-Autoscaling, eine GKE-Funktion, die die Anzahl der Pods für eine Arbeitslast abhängig von angegebenen Messwerten automatisch erhöhen oder verringern kann.
• Simulieren Sie die Anwendungslast und sehen Sie sich das Cluster-Autoscaling und das horizontale Pod-Autoscaling an.

Kosten

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

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

Hinweise

Um zu erfahren, wie Sie Ihre Bereitstellungen skalieren können, müssen Sie die erste Anleitung befolgen, um einen GKE-Cluster zu erstellen, der Autopilot verwendet, und die auf Mikrodiensten basierende Cymbal Bank-Beispielanwendung bereitzustellen.

Wir empfehlen Ihnen, diese Anleitungen für Cymbal Bank der Reihe nach durchzugehen. Mit den Anleitungen 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. Dieses Dienstkonto wird in der Anleitung verwendet, um Zugriff auf benutzerdefinierte Messwerte zu gewähren, mit denen das horizontale Pod-Autoscaling 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]"
   

   Der folgende Zugriff wird dem IAM-Dienstkonto 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, Workload Identity als IAM-Dienstkonto fungieren zu lassen.

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 das horizontale Pod-Autoscaling so konfigurieren, dass grundlegende integrierte Kubernetes-CPU- und -Arbeitsspeichermesswerte verwendet werden, oder Sie können benutzerdefinierte Messwerte von Cloud Monitoring verwenden, z. B. HTTP-Anfragen pro Sekunde oder die Anzahl der SELECT-Anweisungen. Benutzerdefinierte Messwerte funktionieren ohne Anwendungsänderungen und geben Ihrem Cluster mehr Einblick in die Gesamtleistung und die Anforderungen der Anwendung. In dieser Anleitung erfahren Sie, wie Sie die integrierten und benutzerdefinierten Messwerte verwenden.

1. Damit das horizontale Pod-Autoscaling benutzerdefinierte Messwerte aus Monitoring lesen kann, müssen Sie in Ihrem Cluster den Adapter Benutzerdefinierte Messwerte – Stackdriver-Adapter 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 Workload Identity. 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 von Workload Identity und dem IAM-Dienstkonto, das zum Lesen der Monitoring-Messwerte berechtigt ist:

   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 enthält ein eigenes System für Dienstkonten für den Zugriff in einem Cluster. Damit sich Ihre Anwendungen bei Diensten und Ressourcen außerhalb Ihrer GKE-Cluster (Google Kubernetes Engine) der Enterprise-Version wie Monitoring authentifizieren können, verwenden Sie Workload Identity. Bei diesem Ansatz wird das Kubernetes-Dienstkonto für die Verwendung des IAM-Dienstkontos für GKE konfiguriert.

   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: Glückwunsch! Sie haben jetzt einen Stackdriver-Adapter in Ihrem GKE Enterprise-Cluster, der für das Lesen benutzerdefinierter Messwerte aus Monitoring konfiguriert ist.

Horizontales Pod-Autoscaling konfigurieren

GKE Autopilot kann auf verschiedene Arten skaliert werden. In dieser Anleitung erfahren Sie, wie Ihr Cluster mit den folgenden Methoden skaliert werden kann:

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

Diese beiden Methoden können zusammenarbeiten, sodass sich, wenn sich die Anzahl der Pods für Ihre Anwendungen ändert, auch die Knotenressourcen ändern, die diese Pods unterstützen.

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 von integrierten Messwerten und das frontend-Deployment mithilfe benutzerdefinierter Messwerte.

Arbeiten Sie bei Ihren eigenen Anwendungen mit Ihren Anwendungs- und Plattformentwicklern zusammen, um ihre Anforderungen zu verstehen und die Regeln für das horizontale Pod-Autoscaling zu konfigurieren.

userservice-Deployment skalieren

Wenn die Anzahl der Nutzer der Beispielanwendung "Cymbal Bank" zunimmt, verbraucht der userservice-Service mehr CPU-Ressourcen. Mit einem HorizontalPodAutoscaler-Objekt können Sie steuern, wie Ihre Anwendung auf die 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. Überprüfen Sie das HorizontalPodAutoscaler-Beispielmanifest für das userservice-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: 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 das frontend-Deployment können Sie stattdessen auf Basis der Anzahl der eingehenden HTTP-Anfragen skalieren. Bei diesem Ansatz wird der Stackdriver-Adapter verwendet, um benutzerdefinierte Messwerte aus Monitoring für das HTTP(S)-Load-Balancer-Ingress-Objekt zu lesen.

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 des Ingress-Load-Balancers frontend:

   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: Glückwunsch! Sie haben jetzt Regeln für horizontales Pod-Autoscaling für Bereitstellungen in Ihrem GKE Enterprise-Cluster mit 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. Sie können dann das Generieren von Traffic beenden und beobachten, wie die Replikat- und die Knotenanzahl als Reaktion herunterskaliert werden.

1. Bevor Sie beginnen, prüfen Sie den Status des horizontalen Pod-Autoscaling und die Anzahl der verwendeten Replikate.

   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. Mit dieser Schnittstelle simulieren Sie die Last in der 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 Fehlerrate 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 der Pods frontend und userservice:

   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 die Anzahl der Replikate erhöht wurde, während der Lastgenerator ausgeführt wird:

   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 der 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 von GKE Autopilot unterstützt. Für diese Knotenskalierung 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 realen Umgebung wird die Anzahl der Knoten und Pods in der 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 bei Ihren Anwendungsoperatoren und Site Reliability Engineering (SRE) oder Anwendungsentwicklern nach, 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 Anleitungen für Cymbal Bank sind so konzipiert, dass sie nacheinander ausgeführt 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 einlegen möchten, bevor Sie mit der nächsten Anleitung fortfahren, und vermeiden möchten, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden, löschen Sie das von Ihnen 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. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

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

Nächste Schritte

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