一般的な規制要件として、企業は障害復旧（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 モードクラスタ
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。
始める前に
- アカウントにログインします Google Cloud を初めて使用する場合は、 Google Cloud アカウントを作成して、 実際のシナリオで Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
-
Google Cloud CLI をインストールします。
-
外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。
-
gcloud CLI を初期化するには、次のコマンドを実行します:
gcloud init -
プロジェクトを Google Cloud 作成または選択します。
プロジェクトを選択または作成するために必要なロール
- プロジェクトを選択する: プロジェクトの選択には特定の IAM ロールは必要ありません。ロールが付与されているプロジェクトを選択できます。
-
プロジェクトを作成する: プロジェクトを作成するには、プロジェクト作成者ロール
（
roles/resourcemanager.projectCreator）が必要です。これにはresourcemanager.projects.create権限が含まれています。詳しくは、ロールを付与する方法をご覧ください。
-
プロジェクトを作成します。 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 を有効にします。
API を有効にするために必要なロール
API を有効にするには、 権限を含む Service Usage 管理者 IAM ロール（
roles/serviceusage.serviceUsageAdmin）が必要です。serviceusage.services.enable詳しくは、ロールを付与する方法をご覧ください。gcloud services enable container.googleapis.com
compute.googleapis.com -
Google Cloud CLI をインストールします。
-
外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。
-
gcloud CLI を初期化するには、次のコマンドを実行します:
gcloud init -
プロジェクトを Google Cloud 作成または選択します。
プロジェクトを選択または作成するために必要なロール
- プロジェクトを選択する: プロジェクトの選択には特定の IAM ロールは必要ありません。ロールが付与されているプロジェクトを選択できます。
-
プロジェクトを作成する: プロジェクトを作成するには、プロジェクト作成者ロール
（
roles/resourcemanager.projectCreator）が必要です。これにはresourcemanager.projects.create権限が含まれています。詳しくは、ロールを付与する方法をご覧ください。
-
プロジェクトを作成します。 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 を有効にします。
API を有効にするために必要なロール
API を有効にするには、 権限を含む Service Usage 管理者 IAM ロール（
roles/serviceusage.serviceUsageAdmin）が必要です。serviceusage.services.enable詳しくは、ロールを付与する方法をご覧ください。gcloud services enable container.googleapis.com
compute.googleapis.com
リージョン Standard クラスタを作成する
ゾーン障害をシミュレートする前に、マルチゾーン ノードプールを持つリージョン クラスタを作成します。クラスタのコントロール プレーンとノードは、指定されたリージョン内の複数のゾーンにわたって複製されます。
Google Cloud CLI を使用してクラスタを作成します。
デフォルト構成を使用して新しい GKE Standard クラスタを作成します。
gcloud container clusters create CLUSTER_NAME \ --location CONTROL_PLANE_LOCATION \ --num-nodes 2次のパラメータを置き換えます。
CLUSTER_NAME: クラスタの名前。CONTROL_PLANE_LOCATION: クラスタのコントロール プレーンの Compute Engine のリージョン（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 \ --location CONTROL_PLANE_LOCATION
マイクロサービス アプリケーションのサンプルをデプロイする
このドキュメントでシミュレートしたフェイルオーバーの影響を確認するには、マイクロサービス ベースのサンプル アプリケーションをクラスタにデプロイします。このドキュメントでは、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 \ --location=CONTROL_PLANE_LOCATIONZONE_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 \ --location CONTROL_PLANE_LOCATION 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 \ --location CONTROL_PLANE_LOCATION \ --num-nodes 4 \ --node-locations ZONE_A gcloud beta container node-pools create zonal-node-pool-2 \ --cluster CLUSTER_NAME \ --location CONTROL_PLANE_LOCATION \ --num-nodes 4 \ --node-locations ZONE_BZONE_AとZONE_Bは、新しいシングルゾーン ノードプールを実行する 2 つのゾーンに置き換えます。ゾーン障害をシミュレートするには、
default-poolリージョン ノードプールと新しいシングルゾーン ノードプールのいずれかを削除します。gcloud container node-pools delete default-pool \ --cluster=CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION gcloud container node-pools delete zonal-node-pool-1 \ --cluster=CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATIONnode-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 アカウントに課金されないようにするには:
プロジェクトを削除する
課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。
- コンソールで [**リソースの管理**] ページに移動します。 Google Cloud
- プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
- ダイアログでプロジェクト ID を入力し、 [Shut down] をクリックしてプロジェクトを削除します。
次のステップ
- リージョン マネージド インスタンス グループ（MIG）のゾーン停止をシミュレートする方法を学習する。
- Google Cloudでの障害復旧について学習する。
- 複数のゾーンにまたがる高可用性 PostgreSQL を設定する。
- Pod Disruption Budget に関する考慮事項。
- ゾーンとリージョンの永続ディスクの比較を確認する。
- GKE で高可用性データベースを実行する方法を確認する。
- Google Cloudでの障害復旧のベスト プラクティスの詳細を確認する。
- Backup for GKE の詳細を確認する。