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.

Lernziele

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

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.

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Create or select a Google Cloud 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.

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

Enable the Kubernetes Engine API, Compute Engine APIs:

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

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Create or select a Google Cloud 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.

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

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:

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.

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

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“:

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/

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
```
Warten Sie, bis die Pods bereit sind:
```
kubectl get pods
```

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

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}'
```
Ö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.

Ein Load-Balancer leitet den Traffic an einen regionalen Cluster weiter, der in drei Zonen ausgeführt wird. Jede Zone hat zwei Knoten.

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:

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.

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.

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:

Ein Load-Balancer leitet Traffic an einen regionalen Cluster weiter, der über drei Knotenpools ausgeführt wird. Der Standardknotenpool wird in allen Zonen ausgeführt und die anderen beiden Knotenpools werden jeweils in einer einzigen Zone ausgeführt.

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:

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.

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.

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:

Ein Load-Balancer leitet den Traffic an einen regionalen Cluster weiter, der in drei Zonen ausgeführt wird. Jede Zone enthält zwei Knoten und die Pods der Beispielanwendung „Cymbal Bank“ werden in allen Zonen und Knoten ausgeführt.

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:

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

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.

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.

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.

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.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
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.