Chaos Meshが提供するFault Injection

Chaos Meshが提供するFault Injection

2023年4月現在、様々な種類の障害タイプが提供されています。

Manifestの例

いくつか実際の実験内容をManifestベースで確認してみましょう。

1つの実験を1回だけ実行する
まずは、最もシンプルに1つの実験を1回だけ実行するManifestです。

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos # ... 1
metadata:
  namespace: ochacafe
  name: pod-kill
spec:
  action: pod-kill # ... 2
  selector: # ... 3
    namespaces:
      - ochacafe
    labelSelectors:
      app: wordpress
  mode: one # ... 4
  gracePeriod: 0

1. 前述したFault Typesを指定。PodChaos以外にもNetworkChaosやIOChaosなどが指定できる
2. Fault Typesに応じた動作を指定。PodChaosの場合、pod-kill以外にもpod-failure、container-killが指定可能。詳細はFault Types毎のドキュメントを参照
3. 実験の対象範囲を指定
4. 実行モードを指定。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を見てみましょう。

apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule # ... 1
metadata:
  namespace: ochacafe
  name: pod-kill-scheduled
spec:
  type: PodChaos # ... 2
  podChaos: # ... 3
    selector:
      namespaces:
        - ochacafe
      labelSelectors:
        app: wordpress
    action: pod-kill   
    mode: one
    gracePeriod: 0
  schedule: 30 18 * * * # ... 4
  concurrencyPolicy: Forbid # ... 5
  historyLimit: 1 # ... 6

1. スケジュール実行することを指定
2. スケジュール実行するFault Typesを指定。1つの実験を1回だけ実行するで述べたようにPodChaos以外にもNetworkChaosやIOChaosなどが指定できる
3. スケジュール実行する実験の詳細を記述。PodChaosの場合PodChaos.spec.*に記載していた内容をそのまま記述する
4. スケジューリングの詳細を指定。例のようにcron式での指定と事前定義済みの値(@yearly, @monthly, @weekly, @daily, @hourly)を用いた指定方法が存在する
5. 複数の同時実験を作成することを許可するか指定できる。
   • Forbid: 複数の実験を同時に作成することを許可しない
   • Allow: 複数の実験を同時に作成することを許可する
6. スケジュール実行された実験の履歴の最大保持件数を指定

つまり、上記のManifestは「ochacafeネームスペースに存在し、app: wordpressとラベルの付いたPodの中からランダムに1つを選択し、そのPodをkillする、という実験を毎日18:30に実行する。かつ同時実験の作成は許可せずに履歴は1件保持する。」という実験内容が書かれたManifestとなります。

1つ以上の実験をワークフローとして実行する
Chaos Meshでは、複数の実験をワークフローとして実行するための手段も提供されています。PodをkillしながらNetworkに遅延を注入する、といった複雑な実験シナリオの実現や、イベントを注入しながら同時に測定を行う、といったことがユースケースとして考えられます。2023年4月現在、ワークフローを実現するための機能として下表の機能が提供されています。

これらを組み合わせると、例えば、以下のようなワークフローが実現できます。

最初のカスタムタスクで定常状態の測定を行い、その後NetworkChaosで遅延を入れながら再度測定を行い、完了したら Slackに通知を行うワークフローです。このようにワークフローを活用することでカオス実験の大部分を自動化できます。

このようなワークフローを実現するManifestの例を見てみましょう。

apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow # ... 1
metadata:
  namespace: ochacafe
  name: chaos-workflow
spec:
  entry: chaos-workflow # ... 2
  templates:
    - name: chaos-workflow
      templateType: Serial # ... 3
      deadline: 10m
      children: # ... 4
        - pod-kill
        - network-latency
    - name: pod-kill
      templateType: PodChaos
      deadline: 5m
      podChaos:
        selector:
          namespaces:
            - ochacafe
          labelSelectors:
            app: wordpress
        mode: one
        action: pod-kill
        gracePeriod: 0
    - name: network-latency
      templateType: NetworkChaos
      deadline: 5m
      networkChaos:
        selector:
          namespaces:
            - ochacafe
          labelSelectors:
            app: wordpress
            tier: mysql
        mode: all
        action: delay
        delay:
          latency: 2s
          correlation: '0'
          jitter: 0ms
        direction: to

1. ワークフローとして実行することを指定
2. ワークフローのエントリーポイントをテンプレートの中から指定
3. どのテンプレートを使用するかを選択(Serial, Parallel, Task, StatusCheck)
4. 順番に実行されるタスクを定義

つまり、上記のManifestは「ochacafeネームスペースに存在し、app: wordpressとラベルの付いたPodの中からランダムに1つを選択し、そのPodをkillしてから、ochacafeネームスペースに存在し、app: wordpress, tier: mysqlとラベルの付いたPodのインバウンド・トラフィックに対して2sの遅延を注入する。」という実験内容が書かれたManifestとなります。