一般的な規制要件として、企業は障害復旧（DR）能力を証明する必要があります。クラウドで実行されるアプリケーションの場合、この要件には、1 つのゾーンでホストされているサーバーが一定期間利用できなくなった場合のサービスの信頼性と可用性が含まれます。このドキュメントは、Google Kubernetes Engine（GKE）Standard リージョン クラスタを使用するときにゾーン フェイルオーバーをシミュレートする方法を学習したい管理者、アーキテクト、オペレーター、バックアップと障害復旧（DR）の管理者を対象としています。
GKE リージョン クラスタは、ユーザーが選択したリージョンに作成されます。選択したリージョン内の複数のゾーンに配置された VM で、コントロール プレーンが実行されます。GKE Autopilot クラスタは常にリージョン クラスタであり、GKE Standard クラスタはリージョン クラスタまたはゾーンクラスタになります。このチュートリアルでは、GKE Standard リージョン クラスタを使用します。クラスタノードはロードバランサを介してコントロール プレーンと通信します。つまり、ノードのロケーションとコントロール プレーン VM のロケーションは必ずしも一致するとは限りません。リージョン クラスタを使用する場合、Google Cloud コンソールで特定のゾーンを無効にすることはできません。詳細については、GKE クラスタ アーキテクチャをご覧ください。
このチュートリアルでは、ゾーン障害をシミュレートする 3 つの方法について説明します。ゾーン障害をシミュレートし、コンプライアンス遵守に必要な方法でアプリケーションの正しいレスポンスを確認できます。
このドキュメントで説明する方法は、シングルゾーンとマルチゾーンを含むゾーンクラスタにも適用されます。これらの方法は、ターゲット ゾーンのノードにのみ影響し、GKE コントロール プレーンには影響しません。
目標
- デフォルト構成を使用してリージョン GKE Standard クラスタを作成します。
- マイクロサービス アプリケーションのサンプルをリージョン クラスタにデプロイします。
- 次のいずれかの方法でゾーンの停止をシミュレートします。
- リージョン クラスタ内のノードプールのゾーンを減らす。
- シングルゾーンのノードプールを使用する。
- ターゲット障害ゾーンのノードを閉鎖してドレインします。
- マイクロサービスの可用性を確認します。
費用
このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。
- Compute Engine
- GKE Standard モードクラスタ
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを作成できます。
始める前に
- 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.
- Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
-
Google Cloud プロジェクトを作成または選択します。
-
Google Cloud プロジェクトを作成します。
gcloud projects create PROJECT_ID
PROJECT_IDは、作成する Google Cloud プロジェクトの名前に置き換えます。 -
作成した Google Cloud プロジェクトを選択します。
gcloud config set project PROJECT_ID
PROJECT_IDは、実際の Google Cloud プロジェクト名に置き換えます。
-
-
Kubernetes Engine API, Compute Engine API を有効にします。
gcloud services enable container.googleapis.com
compute.googleapis.com - Google Cloud CLI をインストールします。
-
gcloud CLI を初期化するには:
gcloud init
-
Google Cloud プロジェクトを作成または選択します。
-
Google Cloud プロジェクトを作成します。
gcloud projects create PROJECT_ID
PROJECT_IDは、作成する Google Cloud プロジェクトの名前に置き換えます。 -
作成した Google Cloud プロジェクトを選択します。
gcloud config set project PROJECT_ID
PROJECT_IDは、実際の Google Cloud プロジェクト名に置き換えます。
-
-
Kubernetes Engine API, Compute Engine API を有効にします。
gcloud services enable container.googleapis.com
compute.googleapis.com
リージョン Standard クラスタを作成する
ゾーン障害をシミュレートする前に、マルチゾーン ノードプールを持つリージョン クラスタを作成します。クラスタのコントロール プレーンとノードは、指定されたリージョン内の複数のゾーンにわたって複製されます。
Google Cloud CLI を使用してクラスタを作成します。
デフォルト構成を使用して新しい GKE Standard クラスタを作成します。
gcloud container clusters create CLUSTER_NAME \ --region REGION \ --num-nodes 2次のパラメータを置き換えます。
CLUSTER_NAME: クラスタの名前。REGION: クラスタのリージョン（us-central1など）。
GKE がクラスタを作成して、すべてが正しく動作することを確認するまで数分ほどかかります。指定したリージョンの各ゾーンに 2 つのノードが作成されます。
前の手順で作成した各ノードのゾーンを確認します。
kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'出力は、次の例のようになります。
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クラスタに接続します。
gcloud container clusters get-credentials CLUSTER_NAME \ --region REGION
マイクロサービス アプリケーションのサンプルをデプロイする
このドキュメントでシミュレートしたフェイルオーバーの影響を確認するには、マイクロサービス ベースのサンプル アプリケーションをクラスタにデプロイします。このドキュメントでは、Cymbal Bank サンプル アプリケーションを使用します。
シェルで、次の GitHub リポジトリのクローンを作成し、ディレクトリに移動します。
git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git cd bank-of-anthos/前のセクションで作成した GKE クラスタに Cymbal Bank サンプル アプリケーションをデプロイします。
kubectl apply -f ./extras/jwt/jwt-secret.yaml kubectl apply -f ./kubernetes-manifestsPod の準備が整うまで待ちます。
kubectl get pods数分後、Pod が
Running状態になります。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 12sPod がすべて
Running状態になったら、フロントエンド Service の外部 IP アドレスを取得します。kubectl get service frontend | awk '{print $4}'ウェブブラウザ ウィンドウで、
kubectl get serviceコマンドの出力に表示された IP アドレスを開き、Cymbal Bank のインスタンスへのアクセスを開始します。デフォルトの認証情報が自動的に入力されます。アプリにログインして、サンプルの取引と残高を確認できます。Cymbal Bank が正常に実行されていることを確認する以外に、特別な操作は必要ありません。すべてのサービスが正しく起動してログインできるようになるまでに 1～2 分かかることがあります。すべての Pod が
Running状態になり、Cymbal Bank サイトに正常にログインできるようになるまで待ってから、次のセクションに進み、ゾーン障害をシミュレートします。
ゾーン障害をシミュレートする
このセクションでは、いずれかのゾーンで障害をシミュレートします。このフェイルオーバーをシミュレートするには、次の 3 つの方法があります。選択するのは 1 つだけです。ゾーン障害をシミュレートし、コンプライアンス遵守に必要な方法で正しいアプリケーション レスポンスを確認します。
ノードプール ゾーンを減らす
デフォルトでは、リージョン クラスタのノードプールには、リージョンのすべてのゾーンにまたがるノードが存在します。次の図では、Cloud Load Balancing が 3 つのゾーンにまたがるノードプールにトラフィックを分散しています。各ゾーンには 2 つのノードがあり、Pod はこれらのゾーンのいずれかのノードで実行されます。
このセクションでは、3 つのゾーンのうち 2 つで実行されるようにノードプールを更新し、ゾーン障害をシミュレートします。このアプローチでは、Pod とトラフィックを他のゾーンに正しく再分配することで、アプリケーションがゾーンの喪失に対応できることを確認します。
特定のゾーンでのみ実行されるようにノードプールを更新し、障害をシミュレートするには、次の操作を行います。
リージョン クラスタとサービスの可用性を確認します。
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'結果は次の出力例のようになります。
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この例では、すべての Cymbal Bank ワークロードがすべてのゾーンにデプロイされています。障害をシミュレートするには、フロントエンド サービスがデプロイされているゾーン（
asia-southeast1-cなど）を無効にします。ゾーンの停止をシミュレートします。既存のノードプール（
default-pool）を更新して、3 つのゾーンのうち 2 つのゾーンのみを指定します。gcloud container node-pools update default-pool \ --cluster=CLUSTER_NAME \ --node-locations=ZONE_A, ZONE_B \ --region=REGIONZONE_A, ZONE_Bは、ノードプールを引き続き実行する 2 つのゾーンに置き換えます。ノードプールを更新した後、マイクロサービスが利用可能であることを確認します。
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'出力は次の例のようになります。
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この出力例では、
asia-southeast1-cは使用中ではなくなりました。URLhttp://EXTERNAL_IPを使用してブラウザからアクセスするフロントエンド サービスは引き続き利用できます。いずれかのゾーンが利用できなくなっても、ユーザーは入金と支払いアクションを行うことができます。
シングルゾーン ノードプールを使用する
このセクションでは、2 つのノードプールを削除して、ゾーン障害をシミュレートします。このアプローチでは、Pod とトラフィックを別のゾーンのノードプールに正しく再分配することで、アプリケーションがノードプールの損失に対応できることを確認します。リージョン クラスタでゾーンの停止をシミュレートするには、以前に作成した基本クラスタを拡張し、複数のノードプール間で Cymbal Bank アプリケーションを実行します。このゾーン中断のシミュレート方法は、ノードプールのアクティブ ゾーンを更新する最初の例よりも実際のゾーン障害をより正確に反映しています。これは、クラスタ内に複数のノードプールが存在することが一般的であるためです。
シングルゾーン ノードプールの障害をシミュレートするために、このセクションで作成するクラスタには次のコンポーネントが含まれています。
デフォルトのノードプール。通常は、リージョン GKE Standard クラスタを作成するときに作成されます。これは、マルチゾーン ノードプール（
default-pool）です。このドキュメントの冒頭で作成したクラスタには、1 つの
default-poolがあります。Cymbal Bank サンプル アプリケーションのサービスも実行する追加のノードプール（
zonal-node-pool-1とzonal-node-pool-2）
図の点線は、default-pool と zonal-node-pool-1 で障害をシミュレートした後、トラフィックが zonal-node-pool-2 のみを処理する様子を示しています。
追加のノードプールを作成して障害をシミュレートする手順は次のとおりです。
リージョン クラスタの可用性を確認します。
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'結果は次の出力例のようになります。
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この出力例では、すべての Cymbal Bank Pod が同じクラスタのすべてのゾーンにデプロイされ、既存の
default-poolで実行されています。新しいシングルゾーン ノードプールを 2 つ作成します。
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_BZONE_AとZONE_Bは、新しいシングルゾーン ノードプールを実行する 2 つのゾーンに置き換えます。ゾーン障害をシミュレートするには、
default-poolリージョン ノードプールと新しいシングルゾーン ノードプールのいずれかを削除します。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=REGIONnode-poolの削除プロセス中、ワークロードはシャットダウンされ、別の使用可能なノードプールに再スケジュールされます。このプロセスが発生すると、Service と Deployment は使用できません。この動作により、DR レポートやドキュメントでダウンタイム ウィンドウを指定する必要があります。マイクロサービスが引き続き利用可能であることを確認します。
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'出力は次の例のようになります。
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このサンプル出力では、
default-poolとzonal-node-pool-1が存在しなくなったため、すべての Service がzonal-node-pool-2で実行されます。
ゾーン内のノードを閉鎖してドレインする
このセクションでは、クラスタ内の特定のノードを隔離してドレインします。単一ゾーン内のすべてのノードを隔離してドレインします。これにより、ゾーン全体でこれらのノード上で実行されている Pod の損失をシミュレートします。
この図では、最初のゾーンのノードを閉鎖してドレインします。他の 2 つのゾーンのノードは引き続き実行されます。このアプローチでは、他のゾーンで実行されているノード間で Pod とトラフィックを正しく再分配することで、ゾーン内のすべてのノードの損失にアプリケーションが対応できることを確認します。
障害をシミュレートしてゾーンのいずれかのノードを隔離してドレインするには、次の操作を行います。
リージョン クラスタと Service の可用性を確認します。ターゲット障害ゾーンのノード名を確認します。フロントエンド Pod が実行されるゾーンを指定します。
kubectl get pods -o wide出力は次の例のようになります。
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前の出力に表示された Pod をノードのゾーンに関連付けます。
kubectl get node -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'出力は次の例のようになります。
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上記の出力例では、フロントエンド Pod はゾーン
asia-southeast1-bのregional-cluster-1-default-pool-node1にあります。次のステップでは、ゾーン
asia-southeast1-b内のすべてのノードをトレースします。この出力例では、regional-cluster-1-default-pool-node1とregional-cluster-1-default-pool-node2です。ゾーンのいずれかでターゲット ノードを閉鎖してドレインします。この例では、
asia-southeast1-bの次の 2 つのノードです。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このコマンドは、ノードをスケジュール不可としてマークし、ノードの障害をシミュレートします。Kubernetes は、機能するゾーンの他のノードに Pod を再スケジュールします。
障害ゾーンのノードで以前に実行されていた新しいフロントエンド Pod と他の Cymbal Bank Pod のサンプルが、どこで再スケジュールされているかを確認します。
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'出力は次の例のようになります。
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この出力例では、隔離されたノードで実行される Cymbal Bank Pod は示されていません。すべての Pod は、他の 2 つのゾーンでのみ実行されます。
ノードの Pod 停止予算（PDB）によって、ノードのドレインがブロックされることがあります。隔離とドレインのアクションの前に PDB ポリシーを評価します。PDB とその中断管理との関係の詳細については、GKE クラスタの信頼性と稼働時間を確保する方法をご覧ください。
クリーンアップ
このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにする手順は次のとおりです。
プロジェクトを削除する
課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。
- In the Google Cloud console, go to the Manage resources page.
- 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.
次のステップ
- リージョン マネージド インスタンス グループ（MIG）のゾーン停止をシミュレートする方法を学習する。
- Google Cloud での障害復旧について学習する
- 複数のゾーンにまたがる高可用性 PostgreSQL を設定する。
- Pod Disruption Budget に関する考慮事項。
- ゾーンとリージョンの永続ディスクの比較を確認する。
- GKE で高可用性データベースを実行する方法を確認する。
- Google Cloud での障害復旧のベスト プラクティスで詳細を確認する。
- Backup for GKE の詳細を確認する。