Zonenausfall in regionalen GKE-Clustern simulieren

Standard

---

Eine gängige behördliche Anforderung besteht darin, dass ein Unternehmen seine Notfallwiederherstellungsfähigkeit nachweisen 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 mehr verfügbar sind. Dieses Dokument richtet sich an Administratoren und Architekten, Betreiber und Administratoren für Sicherung und Notfallwiederherstellung, die lernen möchten, wie ein Zonenfailover bei Verwendung eines regionalen Standardclusters der Google Kubernetes Engine (GKE) simuliert wird.

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 Standort der VM 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 bietet drei verschiedene Methoden zum Simulieren eines Zonenausfalls. 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 Einzelzonencluster und multizonaler Cluster. 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.
• Beispielanwendung für Mikrodienste im regionalen Cluster bereitstellen
• 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 Cloud verwendet:

• Compute Engine
• GKE-Cluster im Standardmodus

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

Hinweise

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

3. To initialize the gcloud CLI, run the following command:

   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. Make sure that billing is enabled for your Google Cloud project.

6. Enable the Kubernetes Engine API, Compute Engine APIs:

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

7. Install the Google Cloud CLI.

8. To initialize the gcloud CLI, run the following command:

   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. Make sure that billing is enabled for your Google Cloud project.

11. Enable the 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.

Erstellen Sie den Cluster mit der Google Cloud CLI:

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

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

   Es dauert einige Minuten, bis GKE den Cluster erstellt und überprüft hat, ob alles ordnungsgemäß funktioniert. In jeder Zone der von Ihnen angegebenen Region werden zwei Knoten erstellt.

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

   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

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

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

6. Öffnen Sie in einem Webbrowserfenster 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 einige der Beispieltransaktionen und -guthaben ansehen können. Sie müssen nichts weiter tun, als zu prüfen, ob die Cymbal-Bank ordnungsgemäß funktioniert. Es kann ein bis zwei Minuten dauern, bis alle Dienste richtig 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 Ausfall mit einer der Zonen. Sie können dieses Failover auf drei verschiedene Arten simulieren. Sie müssen nur eine Methode auswählen. Simulieren Sie einen Zonenausfall 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 (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 Strategie zur 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. Lesen Sie in der Dokumentation Ihrer Datenbank oder zustandsorientierten Anwendung, z. B. PostgreSQL, SQL Server, MongoDB, Redis oder Cassandra, nach, welche Strategien für Hochverfügbarkeit und Notfallwiederherstellung empfohlen werden.

Knotenpoolzonen reduzieren

Standardmäßig umfasst 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 drei Zonen umfasst. Jede Zone hat zwei Knoten und Ihre Pods können in Knoten in einer beliebigen 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 des regionalen Clusters und der Dienste 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. Zum Simulieren eines Ausfalls 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), sodass nur zwei Zonen der drei Zonen angegeben werden:

     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, nachdem Sie den Knotenpool aktualisiert haben:

   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 erreichbar. 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. Mit diesem Ansatz wird überprüft, ob Ihre Anwendung auf den Verlust eines Knotenpools reagieren kann, indem Pods und Traffic korrekt auf einen Knotenpool in einer anderen Zone verteilt werden. Zum Simulieren eines Zonenausfalls in einem regionalen Cluster 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 zum Simulieren eines Ausfalls eines Knotenpools mit einer Zone erstellen, umfasst die folgenden Komponenten:

• Standardknotenpool: Wird in der Regel beim Erstellen eines regionalen GKE Standardclusters erstellt. Es handelt sich um einen Mehrzonenknotenpool (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 \
       --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 Knotenpools mit einer 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 \
       --region=REGION
   
   gcloud container node-pools delete zonal-node-pool-1 \
       --cluster=CLUSTER_NAME \
       --region=REGION
   

   Während des Löschvorgangs für node-pool werden Arbeitslasten beendet und in einen anderen verfügbaren Knotenpool verschoben. In diesem Fall sind die Dienste und Deployments nicht verfügbar. Aus diesem Grund müssen für die Berichterstellung oder Dokumentation der Notfallwiederherstellung Ausfallzeiten angegeben werden.

   Prü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 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 weiter ausgeführt. Mit diesem Ansatz wird ü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 Dienste. 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. 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 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 verschiebt Pods auf andere Knoten in funktionierenden Zonen.

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 PDB und seiner Beziehung zur Verwaltung von Störungen finden Sie unter Gewährleistung der Zuverlässigkeit und Verfügbarkeit Ihres GKE-Clusters.

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

• Informationen zum Simulieren eines Zonenausfalls für eine regionale verwaltete Instanzgruppe (MIG)
• Informationen zur Notfallwiederherstellung in Google Cloud
• PostgreSQL mit Hochverfügbarkeit in mehreren Zonen einrichten
• Überlegungen zum Budget für Pod-Störungen.
• Zonale und regionale nichtflüchtige Speicher
• Hochverfügbarkeitsdatenbanken in GKE ausführen
• Mehr über Best Practices für die Notfallwiederherstellung in Google Cloud erfahren
• Backup for GKE.