Chaos Meshが提供するFault Injection
2023年4月現在、様々な種類の障害タイプが提供されています。
| fault types |
description |
| PodChaos |
Podの障害をシミュレート(failure, kill, container kill) |
| NetworkChaos |
Pod間のNetworkの障害をシミュレート(partition, loss, delay, duplicate, corrupt, bandwidth) |
| DNSChaos |
DNS障害をシミュレート(error, random) |
| HTTPChaos |
HTTP通信の障害をシミュレート(abort, delay, replace, patch) |
| StressChaos |
CPU, RAMの競合をシミュレート |
| IOChaos |
I/O障害をシミュレート(latency, fault, modify) |
| TimeChaos |
システム時間を変更し、summer timeやその他時間に関連するイベントへの適応をシミュレート |
| KernelChaos |
カーネル障害をシミュレート(メモリ割り当ての例外、etc.) |
| JVMChaos |
JVMの障害をシミュレート(exception, gc, latency, stress, etc.) |
| AWSChaos |
AWSの障害をシミュレート(EC2 stop/restart, detach volume) |
| GCPChao |
GCPの障害をシミュレート(GCE stop/restart, disk loss) |
| AzureChaos |
Azureの障害をシミュレート(VM stop/restart, disk detach) |
Manifestの例
いくつか実際の実験内容をManifestベースで確認してみましょう。
1つの実験を1回だけ実行する
まずは、最もシンプルに1つの実験を1回だけ実行するManifestです。
01 | apiVersion: chaos-mesh.org/v1alpha1 |
07 | action: pod-kill # ... 2 |
- 前述したFault Typesを指定。
PodChaos以外にもNetworkChaosやIOChaosなどが指定できる
- Fault Typesに応じた動作を指定。
PodChaosの場合、pod-kill以外にもpod-failure、container-killが指定可能。詳細はFault Types毎のドキュメントを参照
- 実験の対象範囲を指定
- 実行モードを指定。
one以外にも複数の実行モードが存在する。
one: 対象範囲内のPodの中からランダムに1つ選択し実行するall: 対象範囲内の全てのPodに対して実行するfixed: 対象範囲内における固定数のPodを対象に実行するfixed-percent: 対象範囲内のPodから最大限の割合分のPodを対象に実行する
つまり上記のManifestは「ochacafeネームスペースに存在し、app: wordpressとラベルの付いたPodの中からランダムに1つを選択し、そのPodをkillする」という実験内容が書かれたManifestとなります。
1つの実験をスケジュール的に実行する
Chaos Meshでは1つの実験をスケジュール的に実行する手段も提供されています。これは、自動化の文脈で有効的に使えるのはもちろんのこと、スケジュール的に増減するトラフィックに合わせて実験を行いたいときなどに重宝します。例えば、毎日15:00にECサイト上でセールを行うためトラフィックの増加が見込まれるが、その時間帯に合わせて実験シナリオを注入したい、などです。
スケジュール実行を実現するManifestを見てみましょう。
01 | apiVersion: chaos-mesh.org/v1alpha1 |
05 | name: pod-kill-scheduled |
07 | type: PodChaos # ... 2 |
17 | schedule: 30 18 * * * # ... 4 |
18 | concurrencyPolicy: Forbid # ... 5 |
19 | historyLimit: 1 # ... 6 |
- スケジュール実行することを指定
- スケジュール実行するFault Typesを指定。1つの実験を1回だけ実行するで述べたように
PodChaos以外にもNetworkChaosやIOChaosなどが指定できる
- スケジュール実行する実験の詳細を記述。
PodChaosの場合PodChaos.spec.*に記載していた内容をそのまま記述する
- スケジューリングの詳細を指定。例のようにcron式での指定と事前定義済みの値(
@yearly, @monthly, @weekly, @daily, @hourly)を用いた指定方法が存在する
- 複数の同時実験を作成することを許可するか指定できる。
Forbid: 複数の実験を同時に作成することを許可しないAllow: 複数の実験を同時に作成することを許可する
- スケジュール実行された実験の履歴の最大保持件数を指定
つまり、上記のManifestは「ochacafeネームスペースに存在し、app: wordpressとラベルの付いたPodの中からランダムに1つを選択し、そのPodをkillする、という実験を毎日18:30に実行する。かつ同時実験の作成は許可せずに履歴は1件保持する。」という実験内容が書かれたManifestとなります。
1つ以上の実験をワークフローとして実行する
Chaos Meshでは、複数の実験をワークフローとして実行するための手段も提供されています。PodをkillしながらNetworkに遅延を注入する、といった複雑な実験シナリオの実現や、イベントを注入しながら同時に測定を行う、といったことがユースケースとして考えられます。2023年4月現在、ワークフローを実現するための機能として下表の機能が提供されています。
| features |
description |
| 直列(Serial)実行 |
複数の実験、タスクを順番に実行する |
| 並列(Parallel)実行 |
複数の実験、タスクを並列に実行する(複雑な条件のシミュレートに有効) |
| Custom Task |
任意のコンテナイメージを用いて独自定義の処理を実行する。実行結果による条件分岐も可能 |
| Suspend |
待ち時間を発生させる |
| Status Check |
ステータスの確認を行うタスク(HTTPのリクエストを発行し、ステータスコードを確認する) |
これらを組み合わせると、例えば、以下のようなワークフローが実現できます。
最初のカスタムタスクで定常状態の測定を行い、その後NetworkChaosで遅延を入れながら再度測定を行い、完了したら Slackに通知を行うワークフローです。このようにワークフローを活用することでカオス実験の大部分を自動化できます。
このようなワークフローを実現するManifestの例を見てみましょう。
01 | apiVersion: chaos-mesh.org/v1alpha1 |
07 | entry: chaos-workflow # ... 2 |
09 | - name: chaos-workflow |
10 | templateType: Serial # ... 3 |
16 | templateType: PodChaos |
27 | - name: network-latency |
28 | templateType: NetworkChaos |
- ワークフローとして実行することを指定
- ワークフローのエントリーポイントをテンプレートの中から指定
- どのテンプレートを使用するかを選択(
Serial, Parallel, Task, StatusCheck) - 順番に実行されるタスクを定義
つまり、上記のManifestは「ochacafeネームスペースに存在し、app: wordpressとラベルの付いたPodの中からランダムに1つを選択し、そのPodをkillしてから、ochacafeネームスペースに存在し、app: wordpress, tier: mysqlとラベルの付いたPodのインバウンド・トラフィックに対して2sの遅延を注入する。」という実験内容が書かれたManifestとなります。
