Litmus
Kubernetes 向けのクラウドネイティブなカオスエンジニアリング。中央コントロールプレーンと、再利用可能な実験を共有する ChaosHub を備える。
- カテゴリ: Chaos Engineering
- CNCF 成熟度: Incubating
- 言語: Go (コントロールプレーン)、TypeScript/React (web UI)
- ライセンス: Apache License 2.0
- リポジトリ: litmuschaos/litmus
- ドキュメント基準コミット:
97cfc6f1(tag 3.30.0、2026-06-17)
何をするものか
Litmus は Kubernetes ワークロードに対してカオス実験を実行するフレームワークである。障害 (fault) を Kubernetes カスタムリソースとして宣言し、対象を指定すると、Litmus が障害を注入しつつ、システムが期待される定常状態を保てるかを検証する。
プロジェクトは 2 つの面に分かれる。ChaosCenter がコントロールプレーンで、実験を作成・スケジュール・可視化する Go マイクロサービス群と React UI からなる。実行プレーンは各対象クラスタ内で動き、実際に障害を注入するオペレータ群である。本リポジトリは主にコントロールプレーンを含む。障害のコードは sister repo の litmuschaos/litmus-go に、実験バンドルは litmuschaos/chaos-charts にある。
設計はマルチクラスタ前提である。1 つの ChaosCenter インスタンスが多数の対象クラスタを同時に管理し、各クラスタのエージェントが逆向きにコントロールプレーンへダイヤルバックする。障害は ChaosHub を通じて共有・バージョン管理され、チームは実験定義を書き直さず再利用できる。
いつ使うか
- Kubernetes でワークロードを動かしていて、カオス実験をカスタムリソースとして表現し GitOps フローに乗せたい。
- 複数クラスタにまたがる実験を 1 つのコントロールプレーンから駆動したい。NAT やファイアウォール内のクラスタも含む。
- 使い捨てスクリプトではなく、再利用・共有できる障害定義と定常状態チェック (probe) が欲しい。
- 実験結果から resiliency スコアと Prometheus メトリクスを得たい。
向かないのは、対象が Kubernetes 上にない場合 (マネージドなクラウドリソース障害サービスの方が適することがある) や、自前で運用するコントロールプレーンを持たないホスト型 SaaS が欲しい場合である。
このディープダイブの構成
- 歴史: 起源・マイルストーン・存在理由。
- アーキテクチャ: コンポーネントとリクエストの流れ。
- 採用事例・エコシステム: 誰が動かし、周囲に何があるか。
- 内部実装: ソースから読んだ重要なコードパス。
- はじめに: インストールと最初の動く構成。
出典
- litmuschaos/litmus リポジトリ (pinned
97cfc6f1、tag 3.30.0)、参照 2026-06-24。 - Litmus CNCF プロジェクトページ、参照 2026-06-24。
- LitmusChaos becomes a CNCF incubating project、参照 2026-06-24。
- LitmusChaos Q4 2025 update、参照 2026-06-24。
- LitmusChaos 3.0: robust, lean, developer-centric、参照 2026-06-24。
- ChaosNative launches to accelerate Litmus adoption、参照 2026-06-24。
- LitmusChaos proposal for Sandbox (cncf/toc #390)、参照 2026-06-24。
- Litmus Docs: Installation、参照 2026-06-24。
- Litmus Docs: Architecture summary、参照 2026-06-24。
- ADOPTERS.md、参照 2026-06-24。
- litmuschaos/litmus-go、参照 2026-06-24。
- litmuschaos/chaos-charts、参照 2026-06-24。
- GitHub release 3.30.0、参照 2026-06-24。
- CNCF Landscape (Litmus)、参照 2026-06-24。