はじめてのChaos Mesh: Kubernetes で Pod Failureを試してみる

はじめに

本番環境でシステムが停止する原因は、たいてい事前に想定していなかったものです。
今回は、本番相当の環境であえて障害を発生させてシステムの耐性を検証する「カオスエンジニアリング」と、それを Kubernetes 上で実行するツール Chaos Mesh について紹介します。

この記事では、Chaos Mesh のインストール手順と、実際に Pod を一定時間利用できない状態にする実験を行った感想をまとめます。

そもそもカオスエンジニアリングとは何か？

カオスエンジニアリングとは、システムに意図的に障害を発生させ、そのときの挙動や回復力を検証する手法です。単にシステムを壊すのではなく、どのような障害が起きても、期待する範囲でサービスを継続または復旧できるかどうかを確認します。つまり、対象システムに回復性（=レジリエンス）が備わっているかを検証します。

代表的なツールには、商用 SaaS の Gremlin、Kubernetes ネイティブな OSS である LitmusChaos や Chaos Mesh などがあります。また、クラウドサービスとしては、AWS Fault Injection Service や Azure Chaos Studio といった選択肢もあるようです。

今回使用する Chaos Mesh は、Kubernetes 上で動作する CNCF Incubating プロジェクトです。Pod の停止だけでなく、ネットワーク遅延、パケットロス、I/O 障害、DNS 障害、時刻のずれなど、さまざまな障害を定義できます。Dashboard が用意されており、GUIから実験を簡単に作成できる点も便利です。

今回は、Kubernetes上で動かせる OSS で、障害の種類が豊富にあり、Dashboardから手軽に試せることを理由に Chaos Mesh を選んでみました。

Chaos Mesh のインストール方法

Chaos Mesh は Helm を使ってインストールします。以前はインストールスクリプトを使う方法も提供されていましたが、現在は非推奨となっているため、今回は公式ドキュメントで案内されている Helm を使用します。

クラスタにはすでに kubectl で接続できている前提で進めます。

まず、kubectl と Helm が利用できることを確認します。

kubectl version --client
helm version 

Helm がインストールされていない場合、Windows 環境では WinGet を使ってインストールできます。

winget install --id Helm.Helm -e

インストール後は PowerShell を開き直し、再度バージョンを確認します。

helm version

namespace を作成し、Pod Security を privileged に設定する

Chaos Mesh の daemon は、ホストに対して高度な権限を必要とする操作を行います。そのため、インストール先の namespace の Pod Security を privileged にしておく必要がありました。

kubectl create namespace chaos-mesh

kubectl label namespace chaos-mesh 
  pod-security.kubernetes.io/enforce=privileged 
  pod-security.kubernetes.io/audit=privileged 
  pod-security.kubernetes.io/warn=privileged --overwrite

Helm でインストールする

公式ドキュメントに従ってインストールを進めます。

helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

helm upgrade --install chaos-mesh chaos-mesh/chaos-mesh 
  --namespace chaos-mesh 
  --set chaosDaemon.runtime=containerd 
  --set chaosDaemon.socketPath=/run/containerd/containerd.sock 
  --set dashboard.create=true

インストールが成功すると、次のような出力が表示されます。

Release "chaos-mesh" does not exist. Installing it now.
NAME: chaos-mesh
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete

Pod が起動するまで待つ

インストールが完了したら、以下のコマンドで Pod の状態を確認します。

kubectl get pods -n chaos-mesh
NAME                                        READY   STATUS              RESTARTS   AGE
chaos-controller-manager-...-75f7h          1/1     Running             0          11s
chaos-controller-manager-...-9mm5v          0/1     ContainerCreating   0          11s
chaos-daemon-59s9r                          0/1     ContainerCreating   0          11s
chaos-daemon-dqdn9                          0/1     ContainerCreating   0          11s
chaos-dashboard-...-bjb5d                   0/1     ContainerCreating   0          11s
chaos-dns-server-...-s2vjw                  1/1     Running             0          11s

最初は ContainerCreating が並びますが、イメージの取得が終われば、順番に Running になります。

ダッシュボードを開く

全てのPodがRunning になったら、ダッシュボードを開きます。
今回は外部には公開せず、port-forward を使ってアクセスしました。

kubectl -n chaos-mesh port-forward svc/chaos-dashboard 2333:2333

ブラウザで http://localhost:2333 を開くと、ログイン画面でトークンを求められます。RBAC がデフォルトで有効になっているため、ログインにはトークンが必要です。下の画像にある「click here to generate」のリンクから、トークンの生成を進められます。

Dashboard のログイン用トークンを生成する

Token Generator を開きます。今回はクラスタ全体の Chaos Mesh 実験を操作できるように、以下を選択しました。

• Cluster scoped：有効 ¹
• Role：Manager

表示された RBAC 設定をコピーし、rbac.yaml という名前で保存します。

続いて、保存したファイルをクラスタへ適用します。

kubectl apply -f rbac.yaml

実行すると、次のようなリソースが作成されます。

serviceaccount/account-cluster-manager-dcybf created
clusterrole.rbac.authorization.k8s.io/role-cluster-manager-dcybf created
clusterrolebinding.rbac.authorization.k8s.io/bind-cluster-manager-dcybf created

次に、作成された ServiceAccount のトークンを生成します。

kubectl -n default create token account-cluster-manager-dcybf

ServiceAccount 名の末尾の文字列（今回はdcybf）は、Token Generator が生成するたびに変わります。コマンドには、実際の画面または kubectl apply の実行結果に表示された ServiceAccount 名を入力します。
最後に、表示されたトークンを Chaos Dashboard のログイン画面に貼り付けます。

Pod を1個、一定時間利用できない状態にしてみる

以上で Chaos Mesh のインストールとトークンの生成が完了します。
せっかくなので、いちばん分かりやすい PodChaosのPod Failureを試します。対象の namespace から Pod を1個だけ選び、一定時間利用できない状態にする実験です。

GUIで操作する場合は、左側のメニューの Experiments から New Experiment を選択します。
Inject Info で Kubernetes、Pod Fault、Pod Failure を選択します。

今回は検証用の Pod を対象にし、指定した時間だけ Pod を利用できない状態にします。対象範囲は1つの Pod のみに限定し、ほかのワークロードに影響しないように設定しました。

障害の種類を選択したら、Experiment Info で実験名、対象 Pod、障害の持続時間などを設定します。

設定に問題がなければ、Submit を選択して実験を開始します。
実験が終了すると、タスクのステータスが Running から Completed に変わります。終了したタスクをクリックすると、障害の詳細を確認できます。

詳細画面では、障害の範囲、開始・終了時刻、障害のタイムラインなどを確認できます。

使ってみた感想

インストールと認証の設定が完了すれば、Chaos Mesh は比較的直感的に操作できると感じました。

特に便利だったのは、Dashboard から障害を注入し、実験の状態やタイムラインを確認できる点です。Pod Failure では、設定した持続時間が経過すると障害が解除されるため、実験の開始から終了までを画面上で確認できます。最初に Chaos Mesh を試す場合にも、操作の流れを理解しやすいと思います。

今回は紹介しませんでしたが、実験を YAML で定義できる点も使いやすいと感じました。PodChaos や NetworkChaos を Kubernetes のリソースとして管理できるため、ほかのマニフェストと同じように Git で管理できます。実験の設定がコードとして残るため、後から内容を確認したり、同じ条件で再実行したりする際にも役立ちます。

一方で、対象範囲を広く設定すると、意図しない Pod まで障害の対象になる可能性があります。Chaos Mesh は手軽に障害を注入できるからこそ、最初は検証用の環境を使い、対象 Pod と影響範囲を小さく設定することが重要だと感じました。

参考

• Chaos Mesh 公式ドキュメント
• Cloud Native Glossary: Chaos Engineering の定義

1. Cluster scoped の Manager には、クラスタ全体の Chaos Mesh 実験を作成、更新、削除する権限が付与されます。共有環境や本番環境では、必要に応じて対象 namespace を限定してください。 ↩