GKE リージョン クラスタでゾーン障害をシミュレートする

Standard

---

一般的な規制要件として、企業は障害復旧（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 モードクラスタ

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。

始める前に

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

リージョン Standard クラスタを作成する

ゾーン障害をシミュレートする前に、マルチゾーン ノードプールを持つリージョン クラスタを作成します。クラスタのコントロール プレーンとノードは、指定されたリージョン内の複数のゾーンにわたって複製されます。

Google Cloud CLI を使用してクラスタを作成します。

1. デフォルト構成を使用して新しい GKE Standard クラスタを作成します。

   gcloud container clusters create CLUSTER_NAME \
     --region REGION \
     --num-nodes 2
   

   次のパラメータを置き換えます。

   • CLUSTER_NAME: クラスタの名前。
   • REGION: クラスタのリージョン（us-central1 など）。

   GKE がクラスタを作成して、すべてが正しく動作することを確認するまで数分ほどかかります。指定したリージョンの各ゾーンに 2 つのノードが作成されます。

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
   

3. クラスタに接続します。

   gcloud container clusters get-credentials CLUSTER_NAME \
       --region REGION
   

マイクロサービス アプリケーションのサンプルをデプロイする

このドキュメントでシミュレートしたフェイルオーバーの影響を確認するには、マイクロサービス ベースのサンプル アプリケーションをクラスタにデプロイします。このドキュメントでは、Cymbal Bank サンプル アプリケーションを使用します。

1. シェルで、次の GitHub リポジトリのクローンを作成し、ディレクトリに移動します。

   git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
   cd bank-of-anthos/
   

2. 前のセクションで作成した GKE クラスタに Cymbal Bank サンプル アプリケーションをデプロイします。

   kubectl apply -f ./extras/jwt/jwt-secret.yaml
   kubectl apply -f ./kubernetes-manifests
   

3. Pod の準備が整うまで待ちます。

   kubectl get pods
   

4. 数分後、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          12s
   

5. Pod がすべて Running 状態になったら、フロントエンド Service の外部 IP アドレスを取得します。

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

6. ウェブブラウザ ウィンドウで、kubectl get service コマンドの出力に表示された IP アドレスを開き、Cymbal Bank のインスタンスへのアクセスを開始します。

   デフォルトの認証情報が自動的に入力されます。アプリにログインして、サンプルの取引と残高を確認できます。Cymbal Bank が正常に実行されていることを確認する以外に、特別な操作は必要ありません。すべてのサービスが正しく起動してログインできるようになるまでに 1～2 分かかることがあります。すべての Pod が Running 状態になり、Cymbal Bank サイトに正常にログインできるようになるまで待ってから、次のセクションに進み、ゾーン障害をシミュレートします。

ゾーン障害をシミュレートする

このセクションでは、いずれかのゾーンで障害をシミュレートします。このフェイルオーバーをシミュレートするには、次の 3 つの方法があります。選択するのは 1 つだけです。ゾーン障害をシミュレートし、コンプライアンス遵守に必要な方法で正しいアプリケーション レスポンスを確認します。

注: アプリケーションにステートフル ワークロード（データベースなど）が含まれている場合は、切断された Persistent Disk ボリュームにデータが保存され、リードレプリカが複数のゾーンにデプロイされていることを確認してください。ノードプールを削除する前にこのデータ ストレージを確認するか（ゾーン障害をシミュレートするか）、リージョン Persistent Disk の使用を検討してください。追加の保護として、Backup for GKE を使用することもできます。StatefulSet のデータの整合性、信頼性、軽減戦略は、このドキュメントの範囲外です。これらのストレージ要因を考慮しないと、データが失われる可能性があります。PostgreSQL、SQL Server、MongoDB、Redis、Cassandra などの特定のデータベースまたはステートフル アプリケーションのドキュメントを参照して、高可用性と障害復旧の推奨戦略をご確認ください。

ノードプール ゾーンを減らす

デフォルトでは、リージョン クラスタのノードプールには、リージョンのすべてのゾーンにまたがるノードが存在します。次の図では、Cloud Load Balancing が 3 つのゾーンにまたがるノードプールにトラフィックを分散しています。各ゾーンには 2 つのノードがあり、Pod はこれらのゾーンのいずれかのノードで実行されます。

このセクションでは、3 つのゾーンのうち 2 つで実行されるようにノードプールを更新し、ゾーン障害をシミュレートします。このアプローチでは、Pod とトラフィックを他のゾーンに正しく再分配することで、アプリケーションがゾーンの喪失に対応できることを確認します。

特定のゾーンでのみ実行されるようにノードプールを更新し、障害をシミュレートするには、次の操作を行います。

1. リージョン クラスタとサービスの可用性を確認します。

   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 など）を無効にします。

2. ゾーンの停止をシミュレートします。既存のノードプール（default-pool）を更新して、3 つのゾーンのうち 2 つのゾーンのみを指定します。

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

   ZONE_A, ZONE_B は、ノードプールを引き続き実行する 2 つのゾーンに置き換えます。

3. ノードプールを更新した後、マイクロサービスが利用可能であることを確認します。

   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 は使用中ではなくなりました。URL http://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 のみを処理する様子を示しています。

追加のノードプールを作成して障害をシミュレートする手順は次のとおりです。

1. リージョン クラスタの可用性を確認します。

   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. 新しいシングルゾーン ノードプールを 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_B
   

   ZONE_A と ZONE_B は、新しいシングルゾーン ノードプールを実行する 2 つのゾーンに置き換えます。

3. ゾーン障害をシミュレートするには、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=REGION
   

   node-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 とトラフィックを正しく再分配することで、ゾーン内のすべてのノードの損失にアプリケーションが対応できることを確認します。

障害をシミュレートしてゾーンのいずれかのノードを隔離してドレインするには、次の操作を行います。

1. リージョン クラスタと 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
   

2. 前の出力に表示された 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 です。

3. ゾーンのいずれかでターゲット ノードを閉鎖してドレインします。この例では、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 を再スケジュールします。

4. 障害ゾーンのノードで以前に実行されていた新しいフロントエンド 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 クラスタの信頼性と稼働時間を確保する方法をご覧ください。

   注: 障害をシミュレートした後、kubectl uncordon を使用して、Pod を再度ノードでスケジュール設定できます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにする手順は次のとおりです。

プロジェクトを削除する

課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

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.

次のステップ

• リージョン マネージド インスタンス グループ（MIG）のゾーン停止をシミュレートする方法を学習する。
• Google Cloud での障害復旧について学習する
• 複数のゾーンにまたがる高可用性 PostgreSQL を設定する。
• Pod Disruption Budget に関する考慮事項。
• ゾーンとリージョンの永続ディスクの比較を確認する。
• GKE で高可用性データベースを実行する方法を確認する。
• Google Cloud での障害復旧のベスト プラクティスで詳細を確認する。
• Backup for GKE の詳細を確認する。