Eine gängige regulatorische Anforderung besteht darin, dass ein Unternehmen seine Fähigkeit zur Notfallwiederherstellung (Disaster Recovery, DR) unter Beweis stellen kann. Für Anwendungen, die in der Cloud ausgeführt werden, umfasst diese Anforderung die Zuverlässigkeit und Verfügbarkeit von Diensten, wenn Server, die in einer Zone gehostet werden, für einen bestimmten Zeitraum nicht verfügbar sind. Dieses Dokument richtet sich an Administratoren und Architekten, Operatoren sowie Administratoren von Sicherungen und Notfallwiederherstellungen, die wissen möchten, wie sie bei Verwendung eines regionalen GKE Standard-Clusters (Google Kubernetes Engine) ein Zonen-Failover simulieren möchten. “
Regionale GKE-Cluster werden in einer vom Nutzer ausgewählten Region erstellt und führen die Steuerungsebene auf VMs aus, die sich in mehreren Zonen innerhalb der ausgewählten Region befinden. Autopilot-Cluster von GKE sind immer regional und GKE-Standardcluster können regional oder zonal sein. In dieser Anleitung wird ein regionaler GKE Standard-Cluster verwendet. Clusterknoten kommunizieren über einen Load-Balancer mit der Steuerungsebene. Das bedeutet, dass der Knotenstandort und der VM-Standort der Steuerungsebene nicht immer übereinstimmen. In der Google Cloud Console können Sie eine bestimmte Zone nicht deaktivieren, wenn Sie einen regionalen Cluster verwenden. Weitere Informationen finden Sie unter GKE-Clusterarchitektur.
Diese Anleitung enthält drei verschiedene Methoden zur Simulation eines Zonenausfalls. Sie können einen Zonenfehler simulieren und die korrekte Anwendungsantwort prüfen, je nachdem, welche Methode für Ihre eigenen Compliance-Zwecke erforderlich ist.
Die Methoden in diesem Dokument gelten auch für zonale Cluster, einschließlich Einzelzonenclustern und multizonalen Clustern. Diese Methoden wirken sich nur auf die Knoten in Zielzonen aus und die GKE-Steuerungsebene ist nicht betroffen.
Lernziele
- Erstellen Sie einen regionalen GKE-Standardcluster mit der Standardkonfiguration.
- Mikrodienstanwendung als Beispielanwendung im regionalen Cluster bereitstellen.
- Simulieren Sie einen Zonenausfall mit einer der folgenden drei Methoden:
- Reduzieren Sie die Zonen des Knotenpools in einem regionalen Cluster.
- Verwenden Sie einen Knotenpool mit einer einzelnen Zone.
- Sperren und leeren Sie die Knoten der Zielausfallzone.
- Prüfen Sie die Verfügbarkeit der Mikrodienste.
Kosten
In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:
- Compute Engine
- Cluster im GKE-Standardmodus
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung erstellen.
Hinweise
- 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.
-
Aktivieren Sie die Kubernetes Engine API, Compute Engine APIs:
gcloud services enable container.googleapis.com
compute.googleapis.com
Regionalen Standardcluster erstellen
Bevor Sie einen Zonenausfall simulieren, erstellen Sie einen regionalen Cluster mit einem Mehrzonenknotenpool. Die Steuerungsebene und die Knoten des Clusters werden in mehreren Zonen der angegebenen Region repliziert.
Verwenden Sie die Google Cloud CLI, um den Cluster zu erstellen:
Erstellen Sie mit der Standardkonfiguration einen neuen GKE Standard-Cluster:
gcloud container clusters create CLUSTER_NAME \ --region REGION \ --num-nodes 2
Ersetzen Sie dabei die folgenden Parameter:
CLUSTER_NAME
ist der Name des ClustersREGION
: Dieus-central1
Region für Ihren Cluster, z. B. .
GKE dauert einige Minuten, um den Cluster zu erstellen und zu prüfen, ob alles korrekt funktioniert. In jeder Zone der von Ihnen angegebenen Region werden zwei Knoten erstellt.
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
Als Nächstes stellen Sie die Verbindung zum Cluster her:
gcloud container clusters get-credentials CLUSTER_NAME \ --region REGION
Mikrodienstanwendung bereitstellen
Stellen Sie eine auf Mikrodiensten basierende Beispielanwendung in Ihrem Cluster bereit, um die Auswirkungen des simulierten Failovers in diesem Dokument zu sehen. In diesem Dokument verwenden Sie die Beispielanwendung "Cymbal Bank":
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 die Pods alle den Status
Running
haben, rufen Sie die externe IP-Adresse des Frontend-Dienstes ab:kubectl get service frontend | awk '{print $4}'
Öffnen Sie in einem Webbrowser die IP-Adresse, die in der Ausgabe des Befehls
kubectl get service
angezeigt wird, um auf Ihre Instanz von Cymbal Bank zuzugreifen.Die Standardanmeldedaten werden automatisch ausgefüllt, sodass Sie sich bei der Anwendung anmelden und sich einige der Beispieltransaktionen und -stände ansehen können. Sie müssen lediglich den erfolgreichen Betrieb der Cymbal Bank bestätigen. Es kann ein bis zwei Minuten dauern, bis alle Dienste ordnungsgemäß gestartet wurden und Sie sich anmelden können. Warten Sie, bis alle Pods den Status
Running
haben und Sie sich erfolgreich auf der Website von Cymbal Bank anmelden können, bevor Sie mit dem nächsten Abschnitt fortfahren, und simulieren Sie einen Zonenausfall.
Zonenfehler simulieren
In diesem Abschnitt simulieren Sie einen Ausfall mit einer der Zonen. Es gibt drei verschiedene Möglichkeiten, diesen Failover zu simulieren. Sie müssen nur eine Methode auswählen. Simulieren Sie einen Zonenfehler und prüfen Sie die korrekte Anwendungsantwort mit der Methode, die für Ihre eigenen Compliance-Zwecke erforderlich ist.
Knotenpoolzonen reduzieren
Standardmäßig verfügt ein Knotenpool eines regionalen Clusters über Knoten, die sich über alle Zonen seiner Region erstrecken. Im folgenden Diagramm verteilt Cloud Load Balancing den Traffic auf einen Knotenpool, der sich über drei Zonen erstreckt. Jede Zone hat zwei Knoten und Ihre Pods können in Knoten in jeder dieser Zonen ausgeführt werden.
In diesem Abschnitt simulieren Sie einen Zonenausfall, indem Sie den Knotenpool so aktualisieren, dass er nur in zwei von drei Zonen ausgeführt wird. So wird sichergestellt, dass Ihre Anwendung auf den Verlust einer Zone reagieren kann, indem Pods und Traffic korrekt auf andere Zonen verteilt werden.
Führen Sie die folgenden Schritte aus, um den Knotenpool so zu aktualisieren, dass er nur in bestimmten Zonen ausgeführt wird, und um einen Ausfall zu simulieren:
Prüfen Sie die Verfügbarkeit des regionalen Clusters und der Services:
kubectl get po -o wide \ kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
Das Ergebnis sieht etwa so aus wie in der folgenden Beispielausgabe:
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 6m30s 10.28.1.5 regional-cluster-1-default-pool-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 6m30s 10.28.5.6 regional-cluster-1-default-pool-node1 contacts-7ddc76d94-qv4x5 1/1 Running 0 6m29s 10.28.4.6 regional-cluster-1-default-pool-node2 frontend-747b84bff4-xvjxq 1/1 Running 0 6m29s 10.28.3.6 regional-cluster-1-default-pool-node6 ledger-db-0 1/1 Running 0 6m29s 10.28.5.7 regional-cluster-1-default-pool-node1 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 6m29s 10.28.1.6 regional-cluster-1-default-pool-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 6m29s 10.28.4.7 regional-cluster-1-default-pool-node2 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 6m29s 10.28.3.7 regional-cluster-1-default-pool-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 6m28s 10.28.5.8 regional-cluster-1-default-pool-node1 NAME ZONE INT_IP regional-cluster-1-default-pool-node5 asia-southeast1-c 10.148.0.6 regional-cluster-1-default-pool-node6 asia-southeast1-c 10.148.0.7 regional-cluster-1-default-pool-node2 asia-southeast1-a 10.148.0.8 regional-cluster-1-default-pool-node1 asia-southeast1-a 10.148.0.9 regional-cluster-1-default-pool-node3 asia-southeast1-b 10.148.0.5 regional-cluster-1-default-pool-node4 asia-southeast1-b 10.148.0.4
In diesem Beispiel werden alle Cymbal Bank-Arbeitslasten in allen Zonen bereitgestellt. Wenn Sie einen Ausfall simulieren möchten, deaktivieren Sie eine der Zonen, z. B.
asia-southeast1-c
, in der der Frontend-Dienst bereitgestellt wird.Ausfall einer Zone simulieren. Aktualisieren Sie den vorhandenen Knotenpool (
default-pool
), um nur zwei Zonen aus den drei Zonen anzugeben:gcloud container node-pools update default-pool \ --cluster=CLUSTER_NAME \ --node-locations=ZONE_A, ZONE_B \ --region=REGION
Ersetzen Sie
ZONE_A, ZONE_B
durch die beiden Zonen, in denen der Knotenpool weiterhin ausgeführt werden soll.Prüfen Sie die Verfügbarkeit der Mikrodienste nach dem Aktualisieren des Knotenpools:
kubectl get po -o wide kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
Die Ausgabe sollte wie unten gezeigt aussehen:
NAME ZONE INT_IP regional-cluster-1-default-pool-node2 asia-southeast1-a 10.148.0.8 regional-cluster-1-default-pool-node1 asia-southeast1-a 10.148.0.9 regional-cluster-1-default-pool-node3 asia-southeast1-b 10.148.0.5 regional-cluster-1-default-pool-node4 asia-southeast1-b 10.148.0.4 NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 28m 10.28.1.5 regional-cluster-1-default-pool-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 28m 10.28.5.6 regional-cluster-1-default-pool-node1 contacts-7ddc76d94-qv4x5 1/1 Running 0 28m 10.28.4.6 regional-cluster-1-default-pool-node2 frontend-747b84bff4-mdnkd 1/1 Running 0 9m21s 10.28.1.7 regional-cluster-1-default-pool-node3 ledger-db-0 1/1 Running 0 28m 10.28.5.7 regional-cluster-1-default-pool-node1 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 28m 10.28.1.6 regional-cluster-1-default-pool-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 28m 10.28.4.7 regional-cluster-1-default-pool-node2 transactionhistory-5dd7c7fd77-w2vqs 1/1 Running 0 9m20s 10.28.4.8 regional-cluster-1-default-pool-node2 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 28m 10.28.5.8 regional-cluster-1-default-pool-node1
In dieser Beispielausgabe wird
asia-southeast1-c
nicht mehr verwendet. Der Frontend-Dienst, auf den Sie über einen Browser mit der URLhttp://EXTERNAL_IP
zugreifen, ist weiterhin zugänglich. Ein Nutzer kann weiterhin Überweisungen und Zahlungsaktionen ausführen, obwohl eine der Zonen nicht mehr verfügbar ist.
Einzelzonen-Knotenpool verwenden
In diesem Abschnitt simulieren Sie einen Zonenausfall, indem Sie zwei der Knotenpools löschen. Dieser Ansatz überprüft, ob Ihre Anwendung auf den Verlust eines Knotenpools reagieren kann, indem sie Pods und Traffic korrekt auf einen Knotenpool in einer anderen Zone verteilt. Wenn Sie einen Zonenausfall in einem regionalen Cluster simulieren möchten, erweitern Sie den zuvor erstellten einfachen Cluster und führen die Cymbal Bank-Anwendung über mehrere Knotenpools aus. Diese Methode zur Simulation der Zonenunterbrechung spiegelt einen tatsächlichen Zonenausfall besser wider als das erste Beispiel der Aktualisierung aktiver Zonen in einem Knotenpool, da es häufiger in einem Cluster vorkommt, dass mehrere Knotenpools vorhanden sind:
Der Cluster, den Sie in diesem Abschnitt erstellen, um den Ausfall eines Knotenpools in einer einzelnen Zone zu simulieren, umfasst die folgenden Komponenten:
Der Standardknotenpool, der normalerweise beim Erstellen eines regionalen GKE-Standardclusters erstellt wird, ist ein multizonaler Knotenpool (
default-pool
).Dieser Cluster mit der einzelnen
default-pool
wurde zuvor in diesem Dokument erstellt.Zusätzliche Knotenpools (
zonal-node-pool-1
undzonal-node-pool-2
), die auch Dienste für die Beispielanwendung "Cymbal Bank" ausführen.
Die gepunkteten Linien im Diagramm zeigen, wie der Traffic zonal-node-pool-2
erst verarbeitet, nachdem Sie einen Ausfall in default-pool
und zonal-node-pool-1
simuliert haben.
Führen Sie die folgenden Schritte aus, um zusätzliche Knotenpools zu erstellen und einen Ausfall zu simulieren:
Prüfen Sie die Verfügbarkeit des regionalen Clusters:
gcloud container node-pools list \ --cluster=CLUSTER_NAME \ --region REGION kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
Das Ergebnis sieht etwa so aus wie in der folgenden Beispielausgabe:
NAME: default-pool MACHINE_TYPE: e2-medium DISK_SIZE_GB: 100 NODE_VERSION: 1.27.8-gke.1067004 NAME ZONE. INT_IP regional-cluster-1-default-pool-node5-pzmc asia-southeast1-c 10.148.0.6 regional-cluster-1-default-pool-node6-qf1l asia-southeast1-c 10.148.0.7 regional-cluster-1-default-pool-node2-dlk2 asia-southeast1-a 10.148.0.8 regional-cluster-1-default-pool-node1-pkfd asia-southeast1-a 10.148.0.9 regional-cluster-1-default-pool-node3-6b6n asia-southeast1-b 10.148.0.5 regional-cluster-1-default-pool-node4-h0lc asia-southeast1-b 10.148.0.4
In dieser Beispielausgabe werden alle Cymbal Bank-Pods in allen Zonen unter demselben Cluster bereitgestellt und im vorhandenen
default-pool
ausgeführt.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
undZONE_B
durch die beiden Zonen, in denen die neuen Einzelzonen-Knotenpools ausgeführt werden sollen.Löschen Sie den regionalen Knotenpool
default-pool
und einen der neuen Knotenpools mit einer einzelnen Zone, um einen Zonenausfall zu simulieren:gcloud container node-pools delete default-pool \ --cluster=CLUSTER_NAME \ --region=REGION gcloud container node-pools delete zonal-node-pool-1 \ --cluster=CLUSTER_NAME \ --region=REGION
Während des
node-pool
-Löschvorgangs werden Arbeitslasten heruntergefahren und in einen anderen verfügbaren Knotenpool verschoben. In diesem Fall sind die Dienste und Deployments nicht verfügbar. Dieses Verhalten bedeutet, dass Ausfallzeitfenster für die DR-Berichterstellung oder -Dokumentation angegeben werden müssen.Überprüfen Sie die kontinuierliche Verfügbarkeit der Mikrodienste:
kubectl get po -o wide \ kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
Die Ausgabe sollte wie unten gezeigt aussehen.
NAME ZONE INT_IP regional-cluster-1-node-pool3-node1 asia-southeast1-b 10.148.0.8 regional-cluster-1-node-pool3-node2 asia-southeast1-b 10.148.0.9 regional-cluster-1-node-pool3-node3 asia-southeast1-b 10.148.0.5 regional-cluster-1-node-pool3-node4 asia-southeast1-b 10.148.0.4 NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 28m 10.28.1.5 regional-cluster-1-zonal-node-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 28m 10.28.5.6 regional-cluster-1-zonal-node-pool-2-node1 contacts-7ddc76d94-qv4x5 1/1 Running 0 28m 10.28.4.6 regional-cluster-1-zonal-node-pool-2-node2 frontend-747b84bff4-mdnkd 1/1 Running 0 9m21s 10.28.1.7 regional-cluster-1-zonal-node-pool-2-node3 ledger-db-0 1/1 Running 0 28m 10.28.5.7 regional-cluster-1-zonal-node-pool-2-node4 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 28m 10.28.1.6 regional-cluster-1-zonal-node-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 28m 10.28.4.7 regional-cluster-1-zonal-node-pool-2-node2 transactionhistory-5dd7c7fd77-w2vqs 1/1 Running 0 9m20s 10.28.4.8 regional-cluster-1-zonal-node-pool-2-node2 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 28m 10.28.5.8 regional-cluster-1-zonal-node-pool-2-node1
In dieser Beispielausgabe werden alle Services in
zonal-node-pool-2
ausgeführt, dadefault-pool
undzonal-node-pool-1
nicht mehr vorhanden sind.
Knoten in einer Zone sperren und per Drain beenden
In diesem Abschnitt sperren Sie bestimmte Knoten in Ihrem Cluster und beenden sie per Drain. Sie sperren und leeren alle Knoten in einer einzelnen Zone, wodurch der Verlust der Pods simuliert wird, die auf diesen Knoten in der Zone ausgeführt werden:
In diesem Diagramm sperren und leeren Sie die Knoten in der ersten Zone. Die Knoten in den anderen beiden Zonen werden weiterhin ausgeführt. Dieser Ansatz überprüft, ob Ihre Anwendung auf den Verlust aller Knoten in einer Zone reagieren kann, indem Pods und Traffic korrekt auf Knoten verteilt werden, die in anderen Zonen ausgeführt werden.
Führen Sie die folgenden Schritte aus, um die Knoten in einer der Zonen zu sperren und per Drain zu beenden, um einen Ausfall zu simulieren:
Prüfen Sie die Verfügbarkeit des regionalen Clusters und der Services. Sehen Sie sich die Knotennamen der Zielfehlerzone an. Sie möchten eine Zone angeben, in der die Frontend-Pods ausgeführt werden:
kubectl get pods -o wide
Die Ausgabe sollte wie unten gezeigt aussehen:
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 4m7s 10.96.4.4 regional-cluster-1-default-pool-node2 balancereader-7dc7d9ff57-lv4z7 1/1 Running 0 4m7s 10.96.1.5 regional-cluster-1-default-pool-node1 contacts-7ddc76d94-wxvg5 1/1 Running 0 4m7s 10.96.6.11 regional-cluster-1-default-pool-node3 frontend-747b84bff4-gvktl 1/1 Running 0 4m7s 10.96.1.4 regional-cluster-1-default-pool-node1 ledger-db-0 1/1 Running 0 4m7s 10.96.4.5 regional-cluster-1-default-pool-node2 ledger-db-1 1/1 Running 0 3m50s 10.96.0.13 regional-cluster-1-default-pool-node5 ledgerwriter-f6cc7889d-4hqbm 1/1 Running 0 4m6s 10.96.0.12 regional-cluster-1-default-pool-node5 loadgenerator-57d4cb57cc-fmq52 1/1 Running 0 4m6s 10.96.4.6 regional-cluster-1-default-pool-node2 transactionhistory-5dd7c7fd77-72zpx 1/1 Running 0 4m6s 10.96.6.12 regional-cluster-1-default-pool-node3 userservice-cd5ddb4bb-b7862 1/1 Running 0 4m6s 10.96.1.6 regional-cluster-1-default-pool-node1
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 Zoneasia-southeast1-b
.Im nächsten Schritt verfolgen Sie alle Knoten in der Zone
asia-southeast1-b
, in dieser Beispielausgaberegional-cluster-1-default-pool-node1
undregional-cluster-1-default-pool-node2
.Zielknoten in einer der Zonen sperren und per Drain beenden. In diesem Beispiel sind dies die beiden Knoten in
asia-southeast1-b
:kubectl drain regional-cluster-1-default-pool-node1 \ --delete-emptydir-data --ignore-daemonsets kubectl drain regional-cluster-1-default-pool-node2 \ --delete-emptydir-data --ignore-daemonsets
Mit diesem Befehl werden die Knoten als nicht mehr planbar markiert und Knotenfehler simuliert. Kubernetes weist Pods anderen Knoten in funktionierenden Zonen zu.
Sehen Sie sich an, wo die neuen Frontend-Pods und andere beispielhafte Cymbal Bank-Pods, die zuvor auf dem Knoten in der Fehlerzone ausgeführt wurden, jetzt verschoben werden:
kubectl get po -o wide kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
Die Ausgabe sollte wie unten gezeigt aussehen:
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 4m7s 10.96.4.4 regional-cluster-1-default-pool-node4 balancereader-7dc7d9ff57-lv4z7 1/1 Running 0 4m7s 10.96.1.5 regional-cluster-1-default-pool-node6 contacts-7ddc76d94-wxvg5 1/1 Running 0 4m7s 10.96.6.11 regional-cluster-1-default-pool-node3 frontend-747b84bff4-gvktl 1/1 Running 0 4m7s 10.96.1.4 regional-cluster-1-default-pool-node3 ledger-db-0 1/1 Running 0 4m7s 10.96.4.5 regional-cluster-1-default-pool-node6 ledger-db-1 1/1 Running 0 3m50s 10.96.0.13 regional-cluster-1-default-pool-node5 ledgerwriter-f6cc7889d-4hqbm 1/1 Running 0 4m6s 10.96.0.12 regional-cluster-1-default-pool-node5 loadgenerator-57d4cb57cc-fmq52 1/1 Running 0 4m6s 10.96.4.6 regional-cluster-1-default-pool-node4 transactionhistory-5dd7c7fd77-72zpx 1/1 Running 0 4m6s 10.96.6.12 regional-cluster-1-default-pool-node3 userservice-cd5ddb4bb-b7862 1/1 Running 0 4m6s 10.96.1.6 regional-cluster-1-default-pool-node3 NAME ZONE INT_IP regional-cluster-1-default-pool-node3 asia-southeast1-a 10.148.0.37 regional-cluster-1-default-pool-node4 asia-southeast1-a 10.148.0.38 regional-cluster-1-default-pool-node5 asia-southeast1-c 10.148.0.40 regional-cluster-1-default-pool-node6 asia-southeast1-c 10.148.0.39
In dieser Beispielausgabe gibt es keine Beispiel-Cymbal Bank-Pods, die auf gesperrten Knoten ausgeführt werden. Alle Pods werden jetzt nur noch in den anderen beiden Zonen ausgeführt.
Budgets für Pod-Störungen (Pod Disruption Budgets, PDBs) auf den Knoten können den Ausgleich von Knoten blockieren. Bewerten Sie PDB-Richtlinien vor dem Sperren und Leeren. Weitere Informationen zu PDB und seiner Beziehung zur Verwaltung von Unterbrechungen finden Sie hier, wie Sie Zuverlässigkeit und Verfügbarkeit für Ihren GKE-Cluster gewährleisten.
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.
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.
Nächste Schritte
- Ausfall einer Zone für eine regionale verwaltete Instanzgruppe (Managed Instance Group, MIG) simulieren
- Informationen zur Notfallwiederherstellung in Google Cloud
- Hochverfügbarkeits-PostgreSQL für mehrere Zonen einrichten
- Überlegungen zum Budget für Pod-Störungen.
- Zonale und regionale nichtflüchtige Speicher im Vergleich
- Mehr zum Ausführen von Hochverfügbarkeitsdatenbanken in GKE
- Best Practices für die Notfallwiederherstellung in Google Cloud
- Sicherung für GKE.