Kubernetes向けカオスエンジニアリングプラットフォーム「Chaos Mesh 1.0」が公開：小規模な異常を実システムに与える

　Chaos Meshの特徴は使いやすく、Kubernetesに対応していることだ。Chaos Meshには特別な依存関係がなく、MinikubeやKind（Kubernetes-in–docker）を含むKubernetesクラスタへ容易に直接デプロイできる。

　テスト対象システムのデプロイロジックに変更を加える必要がなく、カオスエンジニアリングの実験（以下、カオス実験）において、フォールト注入動作のオーケストレーションを簡単に実現できる。実装の詳細を隠すことができるので、ユーザーはカオス実験のオーケストレーションに集中できる。

　Chaos MeshではYAMLで記述した「CustomResourceDefinitions」（CRD）を使って、カオスオブジェクトを定義する。

　KubernetesエコシステムではCRDは、カスタムリソースを実装するための成熟したソリューションであり、豊富な実装例やツールがある。CRDを使うことで、Chaos Meshを自然にKubernetesエコシステムに統合できる。

Chaos Meshの構成要素

　現段階では、Chaos Meshには2つのコンポーネントがある。

• Chaos Operator　カオスオーケストレーションのコアコンポーネント。完全にオープンソース化されている
• Chaos Dashboard　カオス実験の管理や設計、モニタリングを行うためのWeb UI（開発中）

　Chaos OperatorはアプリケーションとKubernetesインフラに管理可能な方法でカオスを注入する。そのためにカオス実験と自動オーケストレーションの簡単なカスタム定義を使用する。次に挙げるコンポーネントによって、この仕組みを実現している。

• コントローラーマネージャ　CRDオブジェクトのライフサイクルをスケジューリングしたり、管理したりする
• カオスデーモン　ネットワーク上での特権システム権限を持ち、特定のノードでデーモンセット（Cgroupなど）として動作する

Chaos Meshの構成要素（出典：The Linux Foundation）

CRDオブジェクトの内訳とカオス実験の内容

　Chaos Operatorの現在の実装は、フォールト注入のために6種類のCRDオブジェクトをサポートしている。その内訳は「PodChaos」「NetworkChaos」「IOChaos」「TimeChaos」「StressChaos」「KernelChaos」だ。これらは次の主要なアクション（実験）に対応している。

• pod-kill　選択したPodを止める
• pod-failure　選択したPodが指定した時間、使用できない状態を継続する
• container-kill　選択したPod内の特定のコンテナを止める
• netem chaos　遅延、重複などのネットワークカオスを起こす
• network-partition　ネットワークパーティションをシミュレートする
• IO chaos　ファイルシステムフォールト（I/O遅延、読み書きエラーなど）をシミュレートする
• time chaos　選択したPodにクロックスキューを注入する
• cpu-burn　選択したPodのCPUストレスをシミュレートする
• memory-burn　選択したPodのメモリストレスをシミュレートする
• kernel chaos　選択したPodにslabやbioなどのエラーを注入する