Zonenfehler in regionalen GKE-Clustern simulieren

Standard

---

Eine gängige regulatorische Anforderung besteht darin, dass ein Unternehmen seine Fähigkeit zur Notfallwiederherstellung (Disaster Recovery, DR) unter Beweis stellen kann. Für Anwendungen, die in der Cloud ausgeführt werden, umfasst diese Anforderung die Zuverlässigkeit und Verfügbarkeit von Diensten, wenn Server, die in einer Zone gehostet werden, für einen bestimmten Zeitraum nicht verfügbar sind. Dieses Dokument richtet sich an Administratoren und Architekten, Operatoren sowie Administratoren von Sicherungen und Notfallwiederherstellungen, die wissen möchten, wie sie bei Verwendung eines regionalen GKE Standard-Clusters (Google Kubernetes Engine) ein Zonen-Failover simulieren möchten. “

Regionale GKE-Cluster werden in einer vom Nutzer ausgewählten Region erstellt und führen die Steuerungsebene auf VMs aus, die sich in mehreren Zonen innerhalb der ausgewählten Region befinden. Autopilot-Cluster von GKE sind immer regional und GKE-Standardcluster können regional oder zonal sein. In dieser Anleitung wird ein regionaler GKE Standard-Cluster verwendet. Clusterknoten kommunizieren über einen Load-Balancer mit der Steuerungsebene. Das bedeutet, dass der Knotenstandort und der VM-Standort der Steuerungsebene nicht immer übereinstimmen. In der Google Cloud Console können Sie eine bestimmte Zone nicht deaktivieren, wenn Sie einen regionalen Cluster verwenden. Weitere Informationen finden Sie unter GKE-Clusterarchitektur.

Diese Anleitung enthält drei verschiedene Methoden zur Simulation eines Zonenausfalls. Sie können einen Zonenfehler simulieren und die korrekte Anwendungsantwort prüfen, je nachdem, welche Methode für Ihre eigenen Compliance-Zwecke erforderlich ist.

Die Methoden in diesem Dokument gelten auch für zonale Cluster, einschließlich Einzelzonenclustern und multizonalen Clustern. Diese Methoden wirken sich nur auf die Knoten in Zielzonen aus und die GKE-Steuerungsebene ist nicht betroffen.

Lernziele

• Erstellen Sie einen regionalen GKE-Standardcluster mit der Standardkonfiguration.
• Mikrodienstanwendung als Beispielanwendung im regionalen Cluster bereitstellen.
• Simulieren Sie einen Zonenausfall mit einer der folgenden drei Methoden:
  • Reduzieren Sie die Zonen des Knotenpools in einem regionalen Cluster.
  • Verwenden Sie einen Knotenpool mit einer einzelnen Zone.
  • Sperren und leeren Sie die Knoten der Zielausfallzone.
• Prüfen Sie die Verfügbarkeit der Mikrodienste.

Kosten

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

• Compute Engine
• Cluster im GKE-Standardmodus

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.

Hinweise

1. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
2. Installieren Sie die Google Cloud CLI.

3. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

   gcloud init

4. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

5. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

6. Aktivieren Sie die Kubernetes Engine API, Compute Engine APIs:

   gcloud services enable container.googleapis.com compute.googleapis.com

7. Installieren Sie die Google Cloud CLI.

8. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

   gcloud init

9. Create or select a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

10. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

11. Aktivieren Sie die Kubernetes Engine API, Compute Engine APIs:

    gcloud services enable container.googleapis.com compute.googleapis.com

Regionalen Standardcluster erstellen

Bevor Sie einen Zonenausfall simulieren, erstellen Sie einen regionalen Cluster mit einem Mehrzonenknotenpool. Die Steuerungsebene und die Knoten des Clusters werden in mehreren Zonen der angegebenen Region repliziert.

Verwenden Sie die Google Cloud CLI, um den Cluster zu erstellen:

1. Erstellen Sie mit der Standardkonfiguration einen neuen GKE Standard-Cluster:

   gcloud container clusters create CLUSTER_NAME \
     --region REGION \
     --num-nodes 2
   

   Ersetzen Sie dabei die folgenden Parameter:

   • CLUSTER_NAME ist der Name des Clusters
   • REGION: Die us-central1Region für Ihren Cluster, z. B. .

   GKE dauert einige Minuten, um den Cluster zu erstellen und zu prüfen, ob alles korrekt funktioniert. In jeder Zone der von Ihnen angegebenen Region werden zwei Knoten erstellt.

2. Prüfen Sie die Zonen der einzelnen Knoten, die im vorherigen Schritt erstellt wurden:

   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Die Ausgabe sieht so aus:

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node1   asia-southeast1-c   10.128.0.37
   regional-cluster-1-default-pool-node2   asia-southeast1-c   10.128.0.36
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.128.0.38
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.128.0.33
   regional-cluster-1-default-pool-node5   asia-southeast1-a   10.128.0.35
   regional-cluster-1-default-pool-node6   asia-southeast1-a   10.128.0.34
   

3. Als Nächstes stellen Sie die Verbindung zum Cluster her:

   gcloud container clusters get-credentials CLUSTER_NAME \
       --region REGION
   

Mikrodienstanwendung bereitstellen

Stellen Sie eine auf Mikrodiensten basierende Beispielanwendung in Ihrem Cluster bereit, um die Auswirkungen des simulierten Failovers in diesem Dokument zu sehen. In diesem Dokument verwenden Sie die Beispielanwendung "Cymbal Bank":

1. Klonen Sie in Ihrer Shell das folgende GitHub-Repository und wechseln Sie in das Verzeichnis:

   git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
   cd bank-of-anthos/
   

2. Stellen Sie die Beispielanwendung "Cymbal Bank" in dem GKE-Cluster bereit, den Sie im vorherigen Abschnitt erstellt haben:

   kubectl apply -f ./extras/jwt/jwt-secret.yaml
   kubectl apply -f ./kubernetes-manifests
   

3. Warten Sie, bis die Pods bereit sind:

   kubectl get pods
   

4. Nach einigen Minuten werden die Pods im Status Running angezeigt.

   NAME                                  READY   STATUS    RESTARTS   AGE
   accounts-db-0                         1/1     Running   0          16s
   balancereader-7dc7d9ff57-sstm5        0/1     Running   0          15s
   contacts-7ddc76d94-rr28x              0/1     Running   0          14s
   frontend-747b84bff4-2mtlv             0/1     Running   0          13s
   ledger-db-0                           1/1     Running   0          13s
   ledgerwriter-f6cc7889d-9qjfg          0/1     Running   0          13s
   loadgenerator-57d4cb57cc-zqvqb        1/1     Running   0          13s
   transactionhistory-5dd7c7fd77-lwkv8   0/1     Running   0          12s
   userservice-cd5ddb4bb-wwhml           0/1     Running   0          12s
   

5. Wenn die Pods alle den Status Running haben, rufen Sie die externe IP-Adresse des Frontend-Dienstes ab:

   kubectl get service frontend | awk '{print $4}'
   

6. Öffnen Sie in einem Webbrowser die IP-Adresse, die in der Ausgabe des Befehls kubectl get service angezeigt wird, um auf Ihre Instanz von Cymbal Bank zuzugreifen.

   Die Standardanmeldedaten werden automatisch ausgefüllt, sodass Sie sich bei der Anwendung anmelden und sich einige der Beispieltransaktionen und -stände ansehen können. Sie müssen lediglich den erfolgreichen Betrieb der Cymbal Bank bestätigen. Es kann ein bis zwei Minuten dauern, bis alle Dienste ordnungsgemäß gestartet wurden und Sie sich anmelden können. Warten Sie, bis alle Pods den Status Running haben und Sie sich erfolgreich auf der Website von Cymbal Bank anmelden können, bevor Sie mit dem nächsten Abschnitt fortfahren, und simulieren Sie einen Zonenausfall.

Zonenfehler simulieren

In diesem Abschnitt simulieren Sie einen Ausfall mit einer der Zonen. Es gibt drei verschiedene Möglichkeiten, diesen Failover zu simulieren. Sie müssen nur eine Methode auswählen. Simulieren Sie einen Zonenfehler und prüfen Sie die korrekte Anwendungsantwort mit der Methode, die für Ihre eigenen Compliance-Zwecke erforderlich ist.

Hinweis: Wenn Ihre Anwendungen zustandsorientierte Arbeitslasten wie Datenbanken enthalten, achten Sie darauf, dass die Daten in einem getrennten nichtflüchtigen Speicher-Volume gespeichert sind und dass Lesereplikate über mehrere Zonen hinweg bereitgestellt werden. Prüfen Sie diesen Datenspeicher, bevor Sie einen Knotenpool löschen, um einen Zonenausfall zu simulieren, oder erwägen Sie die Verwendung von regionalen Persistent Disks. Für zusätzlichen Schutz können Sie auch Backup for GKE verwenden. Die Strategie für Datenkonsistenz, Zuverlässigkeit und Risikominderung von StatefulSets wird in diesem Dokument nicht behandelt. Wenn Sie diese Speicherfaktoren nicht berücksichtigen, besteht das Risiko eines potenziellen Datenverlusts. Informationen zu den empfohlenen Strategien für Hochverfügbarkeit und Notfallwiederherstellung finden Sie in der Dokumentation Ihrer jeweiligen Datenbank oder zustandsorientierten Anwendung wie PostgreSQL, SQL Server, MongoDB, Redis oder Cassandra.

Knotenpoolzonen reduzieren

Standardmäßig verfügt ein Knotenpool eines regionalen Clusters über Knoten, die sich über alle Zonen seiner Region erstrecken. Im folgenden Diagramm verteilt Cloud Load Balancing den Traffic auf einen Knotenpool, der sich über drei Zonen erstreckt. Jede Zone hat zwei Knoten und Ihre Pods können in Knoten in jeder dieser Zonen ausgeführt werden.

In diesem Abschnitt simulieren Sie einen Zonenausfall, indem Sie den Knotenpool so aktualisieren, dass er nur in zwei von drei Zonen ausgeführt wird. So wird sichergestellt, dass Ihre Anwendung auf den Verlust einer Zone reagieren kann, indem Pods und Traffic korrekt auf andere Zonen verteilt werden.

Führen Sie die folgenden Schritte aus, um den Knotenpool so zu aktualisieren, dass er nur in bestimmten Zonen ausgeführt wird, und um einen Ausfall zu simulieren:

1. Prüfen Sie die Verfügbarkeit des regionalen Clusters und der Services:

   kubectl get po -o wide \
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Das Ergebnis sieht etwa so aus wie in der folgenden Beispielausgabe:

   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   regional-cluster-1-default-pool-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   regional-cluster-1-default-pool-node2
   frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   regional-cluster-1-default-pool-node6
   ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   regional-cluster-1-default-pool-node1
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   regional-cluster-1-default-pool-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   regional-cluster-1-default-pool-node6
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   regional-cluster-1-default-pool-node1
   
   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.6
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.7
   regional-cluster-1-default-pool-node2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.148.0.4
   

   In diesem Beispiel werden alle Cymbal Bank-Arbeitslasten in allen Zonen bereitgestellt. Wenn Sie einen Ausfall simulieren möchten, deaktivieren Sie eine der Zonen, z. B. asia-southeast1-c, in der der Frontend-Dienst bereitgestellt wird.

2. Ausfall einer Zone simulieren. Aktualisieren Sie den vorhandenen Knotenpool (default-pool), um nur zwei Zonen aus den drei Zonen anzugeben:

     gcloud container node-pools update default-pool \
       --cluster=CLUSTER_NAME \
       --node-locations=ZONE_A, ZONE_B \
       --region=REGION
   

   Ersetzen Sie ZONE_A, ZONE_B durch die beiden Zonen, in denen der Knotenpool weiterhin ausgeführt werden soll.

3. Prüfen Sie die Verfügbarkeit der Mikrodienste nach dem Aktualisieren des Knotenpools:

   kubectl get po -o wide
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Die Ausgabe sollte wie unten gezeigt aussehen:

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4   asia-southeast1-b   10.148.0.4
   
   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          28m     10.28.1.5   regional-cluster-1-default-pool-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          28m     10.28.5.6   regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          28m     10.28.4.6   regional-cluster-1-default-pool-node2
   frontend-747b84bff4-mdnkd             1/1     Running   0          9m21s   10.28.1.7   regional-cluster-1-default-pool-node3
   ledger-db-0                           1/1     Running   0          28m     10.28.5.7   regional-cluster-1-default-pool-node1
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   regional-cluster-1-default-pool-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          28m     10.28.4.7   regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-w2vqs   1/1     Running   0          9m20s   10.28.4.8   regional-cluster-1-default-pool-node2
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          28m     10.28.5.8   regional-cluster-1-default-pool-node1
   

   In dieser Beispielausgabe wird asia-southeast1-c nicht mehr verwendet. Der Frontend-Dienst, auf den Sie über einen Browser mit der URL http://EXTERNAL_IP zugreifen, ist weiterhin zugänglich. Ein Nutzer kann weiterhin Überweisungen und Zahlungsaktionen ausführen, obwohl eine der Zonen nicht mehr verfügbar ist.

Einzelzonen-Knotenpool verwenden

In diesem Abschnitt simulieren Sie einen Zonenausfall, indem Sie zwei der Knotenpools löschen. Dieser Ansatz überprüft, ob Ihre Anwendung auf den Verlust eines Knotenpools reagieren kann, indem sie Pods und Traffic korrekt auf einen Knotenpool in einer anderen Zone verteilt. Wenn Sie einen Zonenausfall in einem regionalen Cluster simulieren möchten, erweitern Sie den zuvor erstellten einfachen Cluster und führen die Cymbal Bank-Anwendung über mehrere Knotenpools aus. Diese Methode zur Simulation der Zonenunterbrechung spiegelt einen tatsächlichen Zonenausfall besser wider als das erste Beispiel der Aktualisierung aktiver Zonen in einem Knotenpool, da es häufiger in einem Cluster vorkommt, dass mehrere Knotenpools vorhanden sind:

Der Cluster, den Sie in diesem Abschnitt erstellen, um den Ausfall eines Knotenpools in einer einzelnen Zone zu simulieren, umfasst die folgenden Komponenten:

• Der Standardknotenpool, der normalerweise beim Erstellen eines regionalen GKE-Standardclusters erstellt wird, ist ein multizonaler Knotenpool (default-pool).

  Dieser Cluster mit der einzelnen default-pool wurde zuvor in diesem Dokument erstellt.

• Zusätzliche Knotenpools (zonal-node-pool-1 und zonal-node-pool-2), die auch Dienste für die Beispielanwendung "Cymbal Bank" ausführen.

Die gepunkteten Linien im Diagramm zeigen, wie der Traffic zonal-node-pool-2 erst verarbeitet, nachdem Sie einen Ausfall in default-pool und zonal-node-pool-1 simuliert haben.

Führen Sie die folgenden Schritte aus, um zusätzliche Knotenpools zu erstellen und einen Ausfall zu simulieren:

1. Prüfen Sie die Verfügbarkeit des regionalen Clusters:

   gcloud container node-pools list \
       --cluster=CLUSTER_NAME \
       --region REGION
   
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Das Ergebnis sieht etwa so aus wie in der folgenden Beispielausgabe:

   NAME: default-pool
   MACHINE_TYPE: e2-medium
   DISK_SIZE_GB: 100
   NODE_VERSION: 1.27.8-gke.1067004
   
   NAME                                         ZONE.               INT_IP
   regional-cluster-1-default-pool-node5-pzmc   asia-southeast1-c   10.148.0.6
   regional-cluster-1-default-pool-node6-qf1l   asia-southeast1-c   10.148.0.7
   regional-cluster-1-default-pool-node2-dlk2   asia-southeast1-a   10.148.0.8
   regional-cluster-1-default-pool-node1-pkfd   asia-southeast1-a   10.148.0.9
   regional-cluster-1-default-pool-node3-6b6n   asia-southeast1-b   10.148.0.5
   regional-cluster-1-default-pool-node4-h0lc   asia-southeast1-b   10.148.0.4
   

   In dieser Beispielausgabe werden alle Cymbal Bank-Pods in allen Zonen unter demselben Cluster bereitgestellt und im vorhandenen default-pool ausgeführt.

2. Erstellen Sie zwei neue Knotenpools mit einer einzelnen Zone:

   gcloud beta container node-pools create zonal-node-pool-1 \
     --cluster CLUSTER_NAME \
     --region REGION \
     --num-nodes 4 \
     --node-locations ZONE_A
   
   gcloud beta container node-pools create zonal-node-pool-2 \
       --cluster CLUSTER_NAME \
       --region REGION \
       --num-nodes 4 \
       --node-locations ZONE_B
   

   Ersetzen Sie ZONE_A und ZONE_B durch die beiden Zonen, in denen die neuen Einzelzonen-Knotenpools ausgeführt werden sollen.

3. Löschen Sie den regionalen Knotenpool default-pool und einen der neuen Knotenpools mit einer einzelnen Zone, um einen Zonenausfall zu simulieren:

   gcloud container node-pools delete default-pool \
       --cluster=CLUSTER_NAME \
       --region=REGION
   
   gcloud container node-pools delete zonal-node-pool-1 \
       --cluster=CLUSTER_NAME \
       --region=REGION
   

   Während des node-pool-Löschvorgangs werden Arbeitslasten heruntergefahren und in einen anderen verfügbaren Knotenpool verschoben. In diesem Fall sind die Dienste und Deployments nicht verfügbar. Dieses Verhalten bedeutet, dass Ausfallzeitfenster für die DR-Berichterstellung oder -Dokumentation angegeben werden müssen.

   Überprüfen Sie die kontinuierliche Verfügbarkeit der Mikrodienste:

   kubectl get po -o wide \
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Die Ausgabe sollte wie unten gezeigt aussehen.

   NAME                                  ZONE                INT_IP
   regional-cluster-1-node-pool3-node1   asia-southeast1-b   10.148.0.8
   regional-cluster-1-node-pool3-node2   asia-southeast1-b   10.148.0.9
   regional-cluster-1-node-pool3-node3   asia-southeast1-b   10.148.0.5
   regional-cluster-1-node-pool3-node4   asia-southeast1-b   10.148.0.4
   
   NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
   accounts-db-0                         1/1     Running   0          28m     10.28.1.5   regional-cluster-1-zonal-node-pool-2-node3
   balancereader-7dc7d9ff57-shwg5        1/1     Running   0          28m     10.28.5.6   regional-cluster-1-zonal-node-pool-2-node1
   contacts-7ddc76d94-qv4x5              1/1     Running   0          28m     10.28.4.6   regional-cluster-1-zonal-node-pool-2-node2
   frontend-747b84bff4-mdnkd             1/1     Running   0          9m21s   10.28.1.7   regional-cluster-1-zonal-node-pool-2-node3
   ledger-db-0                           1/1     Running   0          28m     10.28.5.7   regional-cluster-1-zonal-node-pool-2-node4
   ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   regional-cluster-1-zonal-node-pool-2-node3
   loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          28m     10.28.4.7   regional-cluster-1-zonal-node-pool-2-node2
   transactionhistory-5dd7c7fd77-w2vqs   1/1     Running   0          9m20s   10.28.4.8   regional-cluster-1-zonal-node-pool-2-node2
   userservice-cd5ddb4bb-zfr2g           1/1     Running   0          28m     10.28.5.8   regional-cluster-1-zonal-node-pool-2-node1
   

   In dieser Beispielausgabe werden alle Services in zonal-node-pool-2 ausgeführt, da default-pool und zonal-node-pool-1 nicht mehr vorhanden sind.

Knoten in einer Zone sperren und per Drain beenden

In diesem Abschnitt sperren Sie bestimmte Knoten in Ihrem Cluster und beenden sie per Drain. Sie sperren und leeren alle Knoten in einer einzelnen Zone, wodurch der Verlust der Pods simuliert wird, die auf diesen Knoten in der Zone ausgeführt werden:

In diesem Diagramm sperren und leeren Sie die Knoten in der ersten Zone. Die Knoten in den anderen beiden Zonen werden weiterhin ausgeführt. Dieser Ansatz überprüft, ob Ihre Anwendung auf den Verlust aller Knoten in einer Zone reagieren kann, indem Pods und Traffic korrekt auf Knoten verteilt werden, die in anderen Zonen ausgeführt werden.

Führen Sie die folgenden Schritte aus, um die Knoten in einer der Zonen zu sperren und per Drain zu beenden, um einen Ausfall zu simulieren:

1. Prüfen Sie die Verfügbarkeit des regionalen Clusters und der Services. Sehen Sie sich die Knotennamen der Zielfehlerzone an. Sie möchten eine Zone angeben, in der die Frontend-Pods ausgeführt werden:

   kubectl get pods -o wide
   

   Die Ausgabe sollte wie unten gezeigt aussehen:

   NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE
   accounts-db-0                         1/1     Running   0          4m7s    10.96.4.4    regional-cluster-1-default-pool-node2
   balancereader-7dc7d9ff57-lv4z7        1/1     Running   0          4m7s    10.96.1.5    regional-cluster-1-default-pool-node1
   contacts-7ddc76d94-wxvg5              1/1     Running   0          4m7s    10.96.6.11   regional-cluster-1-default-pool-node3
   frontend-747b84bff4-gvktl             1/1     Running   0          4m7s    10.96.1.4    regional-cluster-1-default-pool-node1
   ledger-db-0                           1/1     Running   0          4m7s    10.96.4.5    regional-cluster-1-default-pool-node2
   ledger-db-1                           1/1     Running   0          3m50s   10.96.0.13   regional-cluster-1-default-pool-node5
   ledgerwriter-f6cc7889d-4hqbm          1/1     Running   0          4m6s    10.96.0.12   regional-cluster-1-default-pool-node5
   loadgenerator-57d4cb57cc-fmq52        1/1     Running   0          4m6s    10.96.4.6    regional-cluster-1-default-pool-node2
   transactionhistory-5dd7c7fd77-72zpx   1/1     Running   0          4m6s    10.96.6.12   regional-cluster-1-default-pool-node3
   userservice-cd5ddb4bb-b7862           1/1     Running   0          4m6s    10.96.1.6    regional-cluster-1-default-pool-node1
   

2. Verknüpfen Sie die in der vorherigen Ausgabe aufgeführten Pods mit der Zone des Knotens:

   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Die Ausgabe sollte wie unten gezeigt aussehen:

   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node1   asia-southeast1-b   10.148.0.41
   regional-cluster-1-default-pool-node2   asia-southeast1-b   10.148.0.42
   regional-cluster-1-default-pool-node3   asia-southeast1-a   10.148.0.37
   regional-cluster-1-default-pool-node4   asia-southeast1-a   10.148.0.38
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.40
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.39
   

   In der vorherigen Beispielausgabe befinden sich die Frontend-Pods in regional-cluster-1-default-pool-node1 in der Zone asia-southeast1-b.

   Im nächsten Schritt verfolgen Sie alle Knoten in der Zone asia-southeast1-b, in dieser Beispielausgabe regional-cluster-1-default-pool-node1 und regional-cluster-1-default-pool-node2.

3. Zielknoten in einer der Zonen sperren und per Drain beenden. In diesem Beispiel sind dies die beiden Knoten in asia-southeast1-b:

   kubectl drain regional-cluster-1-default-pool-node1 \
       --delete-emptydir-data --ignore-daemonsets
   
   kubectl drain regional-cluster-1-default-pool-node2 \
       --delete-emptydir-data --ignore-daemonsets
   

   Mit diesem Befehl werden die Knoten als nicht mehr planbar markiert und Knotenfehler simuliert. Kubernetes weist Pods anderen Knoten in funktionierenden Zonen zu.

4. Sehen Sie sich an, wo die neuen Frontend-Pods und andere beispielhafte Cymbal Bank-Pods, die zuvor auf dem Knoten in der Fehlerzone ausgeführt wurden, jetzt verschoben werden:

   kubectl get po -o wide
   kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
   

   Die Ausgabe sollte wie unten gezeigt aussehen:

   NAME                                  READY   STATUS    RESTARTS   AGE     IP           NODE
   accounts-db-0                         1/1     Running   0          4m7s    10.96.4.4    regional-cluster-1-default-pool-node4
   balancereader-7dc7d9ff57-lv4z7        1/1     Running   0          4m7s    10.96.1.5    regional-cluster-1-default-pool-node6
   contacts-7ddc76d94-wxvg5              1/1     Running   0          4m7s    10.96.6.11   regional-cluster-1-default-pool-node3
   frontend-747b84bff4-gvktl             1/1     Running   0          4m7s    10.96.1.4    regional-cluster-1-default-pool-node3
   ledger-db-0                           1/1     Running   0          4m7s    10.96.4.5    regional-cluster-1-default-pool-node6
   ledger-db-1                           1/1     Running   0          3m50s   10.96.0.13   regional-cluster-1-default-pool-node5
   ledgerwriter-f6cc7889d-4hqbm          1/1     Running   0          4m6s    10.96.0.12   regional-cluster-1-default-pool-node5
   loadgenerator-57d4cb57cc-fmq52        1/1     Running   0          4m6s    10.96.4.6    regional-cluster-1-default-pool-node4
   transactionhistory-5dd7c7fd77-72zpx   1/1     Running   0          4m6s    10.96.6.12   regional-cluster-1-default-pool-node3
   userservice-cd5ddb4bb-b7862           1/1     Running   0          4m6s    10.96.1.6    regional-cluster-1-default-pool-node3
   
   NAME                                    ZONE                INT_IP
   regional-cluster-1-default-pool-node3   asia-southeast1-a   10.148.0.37
   regional-cluster-1-default-pool-node4   asia-southeast1-a   10.148.0.38
   regional-cluster-1-default-pool-node5   asia-southeast1-c   10.148.0.40
   regional-cluster-1-default-pool-node6   asia-southeast1-c   10.148.0.39
   

   In dieser Beispielausgabe gibt es keine Beispiel-Cymbal Bank-Pods, die auf gesperrten Knoten ausgeführt werden. Alle Pods werden jetzt nur noch in den anderen beiden Zonen ausgeführt.

   Budgets für Pod-Störungen (Pod Disruption Budgets, PDBs) auf den Knoten können den Ausgleich von Knoten blockieren. Bewerten Sie PDB-Richtlinien vor dem Sperren und Leeren. Weitere Informationen zu PDB und seiner Beziehung zur Verwaltung von Unterbrechungen finden Sie hier, wie Sie Zuverlässigkeit und Verfügbarkeit für Ihren GKE-Cluster gewährleisten.

   Hinweis: Nachdem Sie den Fehler simuliert haben, können Sie mit kubectl uncordon wieder zulassen, dass Pods auf den Knoten geplant werden.

Bereinigen

So vermeiden Sie, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden:

Projekt löschen

Am einfachsten vermeiden Sie weitere Kosten, indem Sie das für die Anleitung erstellte Projekt löschen.

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

• Ausfall einer Zone für eine regionale verwaltete Instanzgruppe (Managed Instance Group, MIG) simulieren
• Informationen zur Notfallwiederherstellung in Google Cloud
• Hochverfügbarkeits-PostgreSQL für mehrere Zonen einrichten
• Überlegungen zum Budget für Pod-Störungen.
• Zonale und regionale nichtflüchtige Speicher im Vergleich
• Mehr zum Ausführen von Hochverfügbarkeitsdatenbanken in GKE
• Best Practices für die Notfallwiederherstellung in Google Cloud
• Sicherung für GKE.