Zonenausfall in regionalen GKE-Clustern simulieren

Standard

Eine gängige behördliche Anforderung ist, dass ein Unternehmen seine Fähigkeit zur Notfallwiederherstellung (Disaster Recovery, DR) nachweisen kann. Bei Anwendungen, die in der Cloud ausgeführt werden, umfasst diese Anforderung die Zuverlässigkeit und Verfügbarkeit von Diensten, wenn in einer Zone gehostete Server für einen bestimmten Zeitraum nicht verfügbar sind. Dieses Dokument richtet sich an Administratoren und Architekten, Operatoren sowie Administratoren für Sicherung und Notfallwiederherstellung, die erfahren möchten, wie sie ein Zonen-Failover simulieren können, wenn sie einen regionalen GKE-Standardcluster (Google Kubernetes Engine) verwenden.

Regionale GKE-Cluster werden in einer vom Nutzer ausgewählten Region erstellt und die Steuerungsebene wird auf VMs ausgeführt, die sich in mehreren Zonen innerhalb der ausgewählten Region befinden. GKE Autopilot-Cluster sind immer regional und GKE Standard-Cluster 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 derGoogle Cloud -Konsole können Sie keine bestimmte Zone deaktivieren, wenn Sie einen regionalen Cluster verwenden. Weitere Informationen finden Sie unter GKE-Clusterarchitektur.

In dieser Anleitung werden drei verschiedene Methoden zum Simulieren von Zonenausfällen beschrieben. Sie können einen Zonenausfall simulieren und die korrekte Anwendungsantwort prüfen mit der Methode, die für Ihre eigenen Compliancezwecke erforderlich ist.

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

Ziele

• Erstellen Sie einen regionalen GKE Standard-Cluster mit der Standardkonfiguration.
• Stellen Sie eine Beispielanwendung für Mikrodienste im regionalen Cluster bereit.
• Sie können einen Zonenausfall mit einer der folgenden drei Methoden simulieren:
  • Reduzieren Sie die Zonen des Knotenpools in einem regionalen Cluster.
  • Einzelzonen-Knotenpool verwenden
  • Knoten der Zielausfallzone sperren und per Drain beenden.
• Prüfen Sie die Verfügbarkeit der Microservices.

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloudverwendet:

• Compute Engine
• GKE Standard-Clustermodus

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

Hinweis

Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch 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.

Installieren Sie die Google Cloud CLI.

Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

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

gcloud init

Erstellen Sie ein Google Cloud Projekt oder wählen Sie eines aus.

Rollen, die zum Auswählen oder Erstellen eines Projekts erforderlich sind

• Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können jedes Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
• Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator), die die Berechtigung resourcemanager.projects.create enthält. Weitere Informationen zum Zuweisen von Rollen

Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

• So erstellen Sie ein Google Cloud -Projekt:

  gcloud projects create PROJECT_ID

  Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud -Projekt, das Sie erstellen.

• Wählen Sie das von Ihnen erstellte Google Cloud Projekt aus:

  gcloud config set project PROJECT_ID

  Ersetzen Sie PROJECT_ID durch den Namen Ihres Projekts in Google Cloud .

Prüfen Sie, ob für Ihr Google Cloud Projekt die Abrechnung aktiviert ist.

Aktivieren Sie die Kubernetes Engine API und die Compute Engine APIs:

Rollen, die zum Aktivieren von APIs erforderlich sind

Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen

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

Installieren Sie die Google Cloud CLI.

Wenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.

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

gcloud init

Erstellen Sie ein Google Cloud Projekt oder wählen Sie eines aus.

Rollen, die zum Auswählen oder Erstellen eines Projekts erforderlich sind

• Projekt auswählen: Für die Auswahl eines Projekts ist keine bestimmte IAM-Rolle erforderlich. Sie können jedes Projekt auswählen, für das Ihnen eine Rolle zugewiesen wurde.
• Projekt erstellen: Zum Erstellen eines Projekts benötigen Sie die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator), die die Berechtigung resourcemanager.projects.create enthält. Weitere Informationen zum Zuweisen von Rollen

Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

• So erstellen Sie ein Google Cloud -Projekt:

  gcloud projects create PROJECT_ID

  Ersetzen Sie PROJECT_ID durch einen Namen für das Google Cloud -Projekt, das Sie erstellen.

• Wählen Sie das von Ihnen erstellte Google Cloud Projekt aus:

  gcloud config set project PROJECT_ID

  Ersetzen Sie PROJECT_ID durch den Namen Ihres Projekts in Google Cloud .

Prüfen Sie, ob für Ihr Google Cloud Projekt die Abrechnung aktiviert ist.

Aktivieren Sie die Kubernetes Engine API und die Compute Engine APIs:

Rollen, die zum Aktivieren von APIs erforderlich sind

Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Weitere Informationen zum Zuweisen von Rollen

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.

Erstellen Sie den Cluster mit der Google Cloud CLI:

1. Erstellen Sie mithilfe der Standardkonfiguration einen neuen GKE-Standardcluster:

   gcloud container clusters create CLUSTER_NAME \
     --location CONTROL_PLANE_LOCATION \
     --num-nodes 2
   

   Ersetzen Sie die folgenden Parameter:

   • CLUSTER_NAME ist der Name des Clusters
   • CONTROL_PLANE_LOCATION: die Compute Engine-Region der Steuerungsebene Ihres Clusters, z. B. us-central1.

   GKE dauert einige Minuten, bis der Cluster erstellt ist und geprüft wurde, ob alles richtig 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 \
       --location CONTROL_PLANE_LOCATION
   

Mikrodienstanwendung bereitstellen

Um die Auswirkungen des in diesem Dokument beschriebenen simulierten Failovers zu sehen, stellen Sie eine auf Mikrodiensten basierende Beispielanwendung in Ihrem Cluster bereit. In diesem Dokument verwenden Sie die Cymbal Bank-Beispielanwendung:

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“ im 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 alle Pods den Status Running haben, rufen Sie die externe IP-Adresse des Frontend-Dienstes ab:

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

6. Öffnen Sie im Fenster eines Webbrowsers die IP-Adresse, die in der Ausgabe des kubectl get service-Befehls angezeigt wird, um auf Ihre Cymbal Bank-Instanz zuzugreifen.

   Die Standardanmeldedaten werden automatisch eingefügt, sodass Sie sich in der App anmelden und einige der Beispieltransaktionen und ‑guthaben ansehen können. Sie müssen nichts weiter tun, als zu prüfen, ob Cymbal-Bank ordnungsgemäß funktioniert. Es kann ein bis zwei Minuten dauern, bis alle Dienste korrekt gestartet sind und Sie sich anmelden können. Warten Sie, bis alle Pods den Status Running haben und Sie sich erfolgreich auf der Cymbal Bank-Website anmelden können, bevor Sie mit dem nächsten Abschnitt fortfahren und einen Zonenausfall simulieren.

Zonenfehler simulieren

In diesem Abschnitt simulieren Sie einen Fehler in einer der Zonen. Es gibt drei verschiedene Möglichkeiten, dieses Failover zu simulieren. Sie müssen nur eine Methode auswählen. Sie können einen Zonenausfall simulieren und die korrekte Anwendungsantwort prüfen mit der Methode, die für Ihre eigenen Compliancezwecke 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 (einen Zonenausfall simulieren), oder verwenden Sie einen regionalen nichtflüchtigen Speicher. Für zusätzlichen Schutz können Sie auch Backup for GKE verwenden. Die Datenkonsistenz, Zuverlässigkeit und Strategie zur Risikominderung von StatefulSets werden in diesem Dokument nicht behandelt. Wenn Sie diese Speicherfaktoren nicht berücksichtigen, besteht das Risiko eines potenziellen Datenverlusts. In der Dokumentation für Ihre spezifische Datenbank oder zustandsorientierte Anwendung wie PostgreSQL, SQL Server, MongoDB, Redis oder Cassandra finden Sie Informationen zu den empfohlenen Strategien für Hochverfügbarkeit und Notfallwiederherstellung.

Knotenpoolzonen reduzieren

Standardmäßig enthält ein Knotenpool eines regionalen Clusters Knoten, die sich über alle Zonen der 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 auf Knoten in einer 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. Dieser Ansatz prüft, ob Ihre Anwendung auf den Verlust einer Zone reagieren kann, indem sie Pods und Traffic korrekt auf andere Zonen umverteilt.

So aktualisieren Sie den Knotenpool, damit er nur in bestimmten Zonen ausgeführt wird, und simulieren einen Ausfall:

1. Verfügbarkeit von regionalen Clustern und Diensten prüfen:

   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. Um einen Fehler zu simulieren, deaktivieren Sie eine der Zonen, z. B. asia-southeast1-c, in der der Frontend-Dienst bereitgestellt wird.

2. Zonenausfall simulieren Aktualisieren Sie den vorhandenen Knotenpool (default-pool), um nur zwei der drei Zonen anzugeben:

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

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

3. Verfügbarkeit von Microservices nach dem Aktualisieren des Knotenpools prüfen:

   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 verfügbar. Ein Nutzer kann weiterhin Einzahlungen und Zahlungen vornehmen, auch wenn 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 prüft, ob Ihre Anwendung auf den Verlust eines Knotenpools reagieren kann, indem sie Pods und Traffic korrekt auf einen Knotenpool in einer anderen Zone umverteilt. Um einen Zonenausfall in einem regionalen Cluster zu simulieren, erweitern Sie den zuvor erstellten einfachen Cluster und führen die Cymbal Bank-Anwendung in mehreren 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 einen Fehler in einem Knotenpool mit einer einzelnen Zone zu simulieren, umfasst die folgenden Komponenten:

• Standardknotenpool – wird in der Regel beim Erstellen eines regionalen GKE Standard-Clusters erstellt und ist ein multizonaler Knotenpool (default-pool).

  Diesen Cluster mit dem einzelnen default-pool haben Sie zuvor in diesem Dokument erstellt.

• Zusätzliche Knotenpools (zonal-node-pool-1 und zonal-node-pool-2), auf denen auch Dienste für die Beispielanwendung „Cymbal Bank“ ausgeführt werden.

Die gepunkteten Linien im Diagramm zeigen, dass Traffic erst dann an zonal-node-pool-2 weitergeleitet wird, wenn 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 den Ausfall zu simulieren:

1. Verfügbarkeit des regionalen Clusters prüfen:

   gcloud container node-pools list \
       --cluster=CLUSTER_NAME \
       --location CONTROL_PLANE_LOCATION
   
   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 im selben Cluster bereitgestellt und im vorhandenen default-pool ausgeführt.

2. Erstellen Sie zwei neue Einzelzonen-Knotenpools:

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

   Ersetzen Sie ZONE_A und ZONE_B durch die beiden Zonen, in denen die neuen Knotenpools mit einer einzelnen Zone ausgeführt werden sollen.

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

   gcloud container node-pools delete default-pool \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   
   gcloud container node-pools delete zonal-node-pool-1 \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

   Während des Löschvorgangs für node-pool werden Arbeitslasten beendet und in einen anderen verfügbaren Knotenpool verschoben. Während dieses Vorgangs sind die Dienste und Bereitstellungen nicht verfügbar. Das bedeutet, dass Ausfallzeiten für DR-Berichte oder die Dokumentation angegeben werden müssen.

   Prüfen Sie die fortlaufende Verfügbarkeit der Microservices:

   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 Dienste 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 beenden alle Knoten in einer einzelnen Zone per Drain, um den Verlust der Pods zu simulieren, die auf diesen Knoten in der Zone ausgeführt werden:

In diesem Diagramm sperren und beenden Sie die Knoten in der ersten Zone per Drain. Die Knoten in den anderen beiden Zonen werden weiterhin ausgeführt. Dieser Ansatz prüft, ob Ihre Anwendung auf den Verlust aller Knoten in einer Zone reagieren kann, indem sie Pods und Traffic korrekt auf Knoten umverteilt, 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. Verfügbarkeit des regionalen Clusters und der Dienste prüfen Sehen Sie sich die Knotennamen der Zielausfallzone an. Sie sollten 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. Ordnen Sie die im vorherigen Schritt aufgeführten Pods der Zone des Knotens zu:

   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 machen Sie ein Tracing aller Knoten in der Zone asia-southeast1-b, die in dieser Beispielausgabe regional-cluster-1-default-pool-node1 und regional-cluster-1-default-pool-node2 sind.

3. Zielknoten in einer der Zonen sperren und per Drain beenden. In diesem Beispiel sind das 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 planbar" markiert und Knotenfehler simuliert. Kubernetes plant Pods auf andere Knoten in funktionierenden Zonen um.

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

   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 Cymbal Bank-Beispiel-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 das Draining von Knoten blockieren. Bewerten Sie PDB-Richtlinien vor der Sperr- und Leer-Aktion. Weitere Informationen zu PDBs und ihrem Zusammenhang mit der Verwaltung von Unterbrechungen finden Sie unter Zuverlässigkeit und Verfügbarkeit für Ihren GKE-Cluster sicherstellen.

   Hinweis: Nachdem Sie den Ausfall simuliert haben, können Sie mit kubectl uncordon zulassen, dass Pods wieder 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, wenn 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, zum Beispiel eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, anstatt 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 (MIG) simulieren
• Informationen zur Notfallwiederherstellung in Google Cloud
• Richten Sie PostgreSQL mit Hochverfügbarkeit in mehreren Zonen ein.
• Wichtige Hinweise zum Budget für Pod-Störungen.
• Zonale und regionale nichtflüchtige Speicher
• Hochverfügbarkeitsdatenbanken in GKE ausführen
• Weitere Informationen zu Best Practices für die Notfallwiederherstellung Google Cloud
• Backup for GKE.