このチュートリアルは、Google Kubernetes Engine（GKE）で実行される最新のアプリケーション環境をデプロイ、実行、管理することを目的とする IT 管理者とオペレーターを対象としています。このチュートリアルでは、Cymbal Bank サンプル マイクロサービス アプリケーションを使用して、モニタリングとアラートの構成、ワークロードのスケーリング、障害のシミュレーションの方法を学習します。
- クラスタを作成してサンプル アプリケーションをデプロイする
- Google Cloud Managed Service for Prometheus でモニタリングする
- ワークロードのスケーリング
- 障害をシミュレートする（このチュートリアル）
- チェンジ マネジメントを一元化する
概要と目的
アプリケーションは、停止や障害を許容できる必要があります。この機能により、問題が発生してもユーザーは引き続きアプリにアクセスできます。Cymbal Bank サンプル アプリケーションは、障害を処理して実行を継続するように設計されています。トラブルシューティングや修正を行う必要はありません。この復元力を実現するために、GKE リージョン クラスタはコンピューティング ノードをゾーン全体に分散し、Kubernetes コントローラはクラスタ内のサービス問題に自動的に応答します。
このチュートリアルでは、 Google Cloud で障害をシミュレートし、GKE クラスタ内のアプリケーション サービスがどのように応答するかを確認します。次のタスクを行う方法を学習します。
- ノードとサービスの分布を確認します。
- ノードまたはゾーンの障害をシミュレートします。
- 残りのノードでもサービスが引き続き実行されていることを確認します。
ノードとサービスの分布を確認する
Google Cloudにおけるリージョンとは、リソースをホストできる特定の地理的位置のことです。リージョンには 3 つ以上のゾーンがあります。たとえば、us-central1 リージョンは、us-central1-a、us-central1-b、us-central1-c などの複数のゾーンを含む米国中西部のリージョンを示します。ゾーンは、帯域幅が広くレイテンシが低いネットワークで同じリージョンの他のゾーンと接続されています。
高可用性のフォールト トレラントなアプリケーションをデプロイするには、複数のゾーンと複数のリージョンにアプリケーションをデプロイすることをおすすめします。この方法により、ゾーンまたはリージョンまでの規模で、予期しないコンポーネント障害の影響を受けにくくなります。
最初のチュートリアルで GKE クラスタを作成したとき、いくつかのデフォルトの構成値が使用されました。デフォルトでは、Autopilot を使用する GKE クラスタは、指定したリージョンのゾーンにまたがるノードを作成して実行します。このアプローチでは、Cymbal Bank サンプル アプリケーションが複数のゾーンにすでにデプロイされているため、予期しない障害から保護されます。
GKE クラスタ全体のノードの分布を確認します。
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'結果は次の出力例のようになります。この例では、ノードがリージョン内の 3 つのゾーンに分散されています。
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node2 us-central1-a 10.148.0.8 scalable-apps-pool-2-node1 us-central1-a 10.148.0.9 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4GKE クラスタノード全体での Cymbal Bank サンプル アプリケーション サービスの分散を確認します。
kubectl get pods -o wide次の出力例は、サービスがクラスタ内のノードに分散されていることを示しています。前述のノード分散の確認手順から、この出力は、サービスがリージョン内のゾーン全体で実行されていることを示しています。
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 6m30s 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 6m30s 10.28.5.6 scalable-apps-pool-2-node1 contacts-7ddc76d94-qv4x5 1/1 Running 0 6m29s 10.28.4.6 scalable-apps-pool-2-node2 frontend-747b84bff4-xvjxq 1/1 Running 0 6m29s 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 6m29s 10.28.5.7 scalable-apps-pool-2-node1 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 6m29s 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 6m29s 10.28.4.7 scalable-apps-pool-2-node2 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 6m29s 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 6m28s 10.28.5.8 scalable-apps-pool-2-node1
停止のシミュレーションを行う
Google では、電力、冷却機能、ネットワーキングなどの物理インフラストラクチャの停止によって引き起こされる、連動障害のリスクを最小限に抑えるようにゾーンを設計しています。ただし、予期しない問題が発生する可能性があります。ノードまたはゾーンが使用できなくなった場合、サービスは他のノードまたは同じリージョンのゾーンで引き続き実行されます。
Kubernetes コントローラは、クラスタ内のノード、Service、Deployment のステータスをモニタリングします。予期しない停止が発生した場合、コントローラは影響を受けたリソースを再起動し、トラフィックを動作しているノードにルーティングします。
このチュートリアルでは、障害をシミュレートするために、ゾーンのいずれかでノードを閉鎖してドレインします。この方法では、ノードで障害が発生した場合や、ゾーン全体で問題が発生した場合に何が起こるかをシミュレートします。Kubernetes コントローラは、一部のサービスが使用できなくなり、他のゾーンのノードで再起動する必要があることを確認する必要があります。
ゾーンのいずれかでノードを閉鎖してドレインします。次の例では、
us-central1-aの 2 つのノードをターゲットとしています。kubectl drain scalable-apps-pool-2-node1 \ --delete-emptydir-data --ignore-daemonsets kubectl drain scalable-apps-pool-2-node2 \ --delete-emptydir-data --ignore-daemonsetsこのコマンドは、ノードがスケジュール不可としてマークするため、Pod がこれらのノードで実行されないようにします。Kubernetes は、機能するゾーンの他のノードに Pod を再スケジュールします。
シミュレートされた失敗のレスポンスを確認する
このシリーズの以前のチュートリアルでは、GKE クラスタのマネージド Prometheus インスタンスを構成して一部のサービスをモニタリングし、問題が発生した場合にアラートを生成する方法を学習しました。障害をシミュレートしたゾーンのノードで Pod が実行されていた場合、Prometheus によって生成されたアラートから Slack の通知メッセージを受け取ります。この動作は、デプロイの健全性をモニタリングして、問題が発生した場合にアラートを送信し、負荷の変化や障害を自動的に調整する最新のアプリケーション環境を構築する方法を示しています。
GKE クラスタは、シミュレートされた停止に自動的に応答します。影響を受けるノードのサービスは、残りのノードで再起動されます。
GKE クラスタ全体のノードの分布をもう一度確認します。
kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'結果は次の出力例のようになります。この例では、ノードがリージョン内の 2 つのゾーンに分散されています。
NAME ZONE INT_IP scalable-apps-pool-2-node5 us-central1-c 10.148.0.6 scalable-apps-pool-2-node6 us-central1-c 10.148.0.7 scalable-apps-pool-2-node3 us-central1-b 10.148.0.5 scalable-apps-pool-2-node4 us-central1-b 10.148.0.4Kubernetes コントローラは、2 つのノードが使用できなくなったことを認識し、使用可能なノードにサービスを再分配します。すべてのサービスは引き続き実行されます。
GKE クラスタノード全体での Cymbal Bank サンプル アプリケーション サービスの分散を確認します。
kubectl get pods -o wide次の出力例は、Service がクラスタ内の残りのノードに分散されていることを示しています。前のステップでノードの分散を確認した結果、この出力では、サービスがリージョン内の 2 つのゾーンでのみ実行されていることが示されています。
NAME READY STATUS RESTARTS AGE IP NODE accounts-db-0 1/1 Running 0 28m 10.28.1.5 scalable-apps-pool-2-node3 balancereader-7dc7d9ff57-shwg5 1/1 Running 0 9m21s 10.28.5.6 scalable-apps-pool-2-node5 contacts-7ddc76d94-qv4x5 1/1 Running 0 9m20s 10.28.4.6 scalable-apps-pool-2-node4 frontend-747b84bff4-xvjxq 1/1 Running 0 28m 10.28.3.6 scalable-apps-pool-2-node6 ledger-db-0 1/1 Running 0 9m24s 10.28.5.7 scalable-apps-pool-2-node3 ledgerwriter-f6cc7889d-mttmb 1/1 Running 0 28m 10.28.1.6 scalable-apps-pool-2-node3 loadgenerator-57d4cb57cc-7fvrc 1/1 Running 0 9m21s 10.28.4.7 scalable-apps-pool-2-node5 transactionhistory-5dd7c7fd77-cmc2w 1/1 Running 0 28m 10.28.3.7 scalable-apps-pool-2-node6 userservice-cd5ddb4bb-zfr2g 1/1 Running 0 9m20s 10.28.5.8 scalable-apps-pool-2-node1サービスの
AGEを確認します。上記の出力例では、Cymbal Bank サンプル アプリケーションで、一部のサービスが他のサービスよりも若い年齢になっています。これらの新しいサービスは、以前に障害をシミュレートしたノード上で実行されていました。Kubernetes コントローラが、使用可能なノードでこれらのサービスを再起動しました。
実際のシナリオでは、問題のトラブルシューティングを行うか、根本的なメンテナンスの問題が解決するのを待つ必要があります。アラートに基づいて Slack メッセージを送信するように Prometheus を構成した場合、これらの通知が表示されます。必要に応じて、前回のチュートリアルのリソースをスケーリングする手順から繰り返して、リージョンで使用可能なゾーンが 2 つしかない場合に、GKE クラスタが負荷の増加にどのように対応するかを確認することもできます。クラスタは、残りの 2 つのゾーンで利用可能な状態でスケールアップする必要があります。