---
title: "Pumbaとは？Dockerコンテナにカオステストを行う使い方とコマンド【1.6対応】"
url: "https://www.issoh.co.jp/tech/details/9700/"
published: 2025-11-07
updated: 2026-11-08
categories: ["テスト"]
publisher: "株式会社一創"
---

# Pumbaとは？Dockerコンテナにカオステストを行う使い方とコマンド【1.6対応】

Pumba（パンバ）は、Dockerなどのコンテナを対象に、プロセス停止・ネットワーク遅延・パケットロス・CPU負荷といった障害をコマンド1行で注入するオープンソースのカオステストツールです。開発はAlexei Ledenev氏で、GitHubの`alexei-led/pumba`で公開されています。2026年11月8日時点の最新版は1.6.0（2026年11月5日公開）で、各版の変更点は[PumbaのGitHubリリース一覧](https://github.com/alexei-led/pumba/releases)で確認できます。

なお、検索語の「pumba」はInstagramで知られるカラカル（猫科の動物）の名前や、映画『ライオン・キング』のイボイノシシも指します。ライオン・キングのキャラクターの綴りは「Pumbaa」でaが2つです。この記事は、コンテナ向けツールのPumbaを扱います。

## まとめ：Pumbaでできることと使う前に知っておく制約

- 注入できる障害は、コンテナの停止系（kill・stop・pause・rm・restart・exec）、ネットワーク系（netem・iptables）、リソース負荷（stress）の3系統です。対応ランタイムはDocker・containerd・Podmanで、Windows向けバイナリは今後も作らないと公式に明記されています。
- 障害を入れたPumbaが異常終了すると、障害はコンテナに残ります。検証環境ではkill -9の後も200ミリ秒の遅延が続きました。`pumba status --check`で検知し、iptablesは`pumba revert`で戻せますが、netemのqdiscは手動で消します。
- 対象名が1件も一致しなくても終了コードは0です。CIでは`--output ndjson`の`run.end`を見て`no_targets`を失敗扱いにします。
- netemは送信（egress）側だけに効きます。受信側のパケットロスは`iptables loss`で作ります。netemとiptablesは`--duration`が必須です。
- containerdでは`--label`が動きません。1.6.0の公式デプロイガイドの例は`--label`を使っていますが実行すると失敗するので、`re2:`で`namespace/pod/container`形式の名前を指定します。

以下、導入から各コマンドの挙動、障害を残さない手順、他ツールとの使い分けの順に説明します。

## Pumbaの仕組みと対応ランタイム・動作環境

Pumbaはコンテナランタイムのソケット（Dockerなら`/var/run/docker.sock`）に接続し、対象コンテナを名前やラベルで選んで操作します。停止系のコマンドはランタイムのAPIを呼ぶだけです。ネットワーク系は、`tc`や`iptables`を含むヘルパーコンテナを対象コンテナと同じネットワーク名前空間で起動し、そこでルールを入れます。[1.6.0のREADME](https://github.com/alexei-led/pumba/blob/1.6.0/README.md)には、NetflixのChaos Monkeyに着想を得てカオスエンジニアリングをコンテナの単位に持ち込んだツールだと書かれています。

### 注入できる障害とコマンドの対応

| 系統     | コマンド              | 起きること                          |
| ------ | ----------------- | ------------------------------ |
| コンテナ停止 | `kill`            | 既定でSIGKILLを送る                  |
| コンテナ停止 | `stop`            | 既定でSIGTERM、5秒以内に停止しなければSIGKILL |
| コンテナ停止 | `pause`           | 指定時間だけ全プロセスを一時停止               |
| コンテナ停止 | `rm`              | 既定で強制削除（Dockerでは匿名ボリュームも削除）    |
| コンテナ停止 | `restart`         | コンテナを再起動                       |
| コマンド実行 | `exec`            | 既定で`kill 1`を実行                 |
| ネットワーク | `netem`           | 送信の遅延・損失・重複・破損・帯域制限            |
| ネットワーク | `iptables loss`   | 受信パケットの破棄                      |
| リソース負荷 | `stress`          | stress-ngでCPU・メモリ・I/O負荷        |
| 確認・復旧  | `status`・`revert` | 残った障害の検知と、run単位の復旧             |

既定値は1.6.0の`--help`で確認したものです。`exec`の既定値が`kill 1`である点は、後の章で扱う事故につながります。

### Docker・containerd・Podmanの対応状況とWindows非対応

| ランタイム      | 既定ソケット                            | netem・iptables・stressの条件 | 対応版   |
| ---------- | --------------------------------- | ------------------------ | ----- |
| Docker     | `/var/run/docker.sock`            | rootかソケットへのアクセス権         | 初期から  |
| containerd | `/run/containerd/containerd.sock` | root必須                   | 1.0.0 |
| Podman     | `/run/podman/podman.sock`         | rootful必須                | 1.1.0 |

配布バイナリはLinuxとmacOSのamd64・arm64の4種類です。READMEはmacOS版を「開発者の利便性のため」と位置づけ、[Colima](/tech/details/17842/)やPodman machineなどのLinux VMを操作する用途に限っています。Windows版は、Linuxのnetnsやcgroupへの書き込みに相当する仕組みが無いことを理由に「サポートせず、予定もない」と明記されています。WSL2上のDocker Desktopでも同じ扱いです。

## 1.3.0から1.6.0までの変更点と更新時の確認事項

| 版     | 公開日        | 主な変更                                        |
| ----- | ---------- | ------------------------------------------- |
| 1.3.0 | 2026-10-29 | 負の`--duration`を拒否、ビルドはGo 1.27へ              |
| 1.3.1 | 2026-10-29 | iptablesの部分失敗時に追加済みルールを巻き戻す                 |
| 1.4.0 | 2026-10-29 | `--max-targets`、stressの`--cpu`等のフラグ         |
| 1.5.0 | 2026-11-03 | ndjson出力、`status`、`schema`、`--max-duration` |
| 1.5.1 | 2026-11-04 | CIと配布の検証のみ（挙動の変更なし）                         |
| 1.6.0 | 2026-11-05 | `--match-all`、`revert`                      |

8日間でマイナー版が4回上がっています。CIでは`latest`を使わず、`ghcr.io/alexei-led/pumba:1.6.0`のように版を固定してください。出力形式の変更で、結果の判定スクリプトが壊れることがあるためです。

1.2系から上げるときに影響が出るのは次の3点です。[1.5.0のリリースノート](https://github.com/alexei-led/pumba/releases/tag/1.5.0)によると、iptablesのルールには識別用のcommentが付くようになり、カーネル側でcommentマッチ（legacyなら`xt_comment`）が使えないと、注入は失敗します。全てのdry-runは`--duration`を待たなくなり、ネットワーク系の計画は標準出力に出ます。ログを解析していたスクリプトは直してください。1.3.0以降は、スクリプトに負の`--duration`が残っていると起動時にエラーになります。

## Pumbaのインストール方法（バイナリ・Homebrew・コンテナイメージ）

導入方法は3つです。どれも1.6.0を入手できます。

```
# Linux：単体バイナリ（tar.gzではなく実行ファイルそのものが配布される）
curl -sL https://github.com/alexei-led/pumba/releases/latest/download/pumba_linux_amd64 -o pumba
chmod +x pumba
./pumba --version
# 以降の例を pumba コマンドで実行するため、PATH上へ配置
sudo install -m 0755 pumba /usr/local/bin/pumba

# macOS：Homebrew（homebrew-coreのformula）
brew install pumba

# コンテナとして実行（READMEの推奨）
docker pull ghcr.io/alexei-led/pumba:1.6.0
docker run -it --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/alexei-led/pumba:1.6.0 --version
```

イメージの正規の配布先はGitHub Container Registryです。READMEではDocker Hub側を非推奨（Deprecated）としています。古い解説記事に出てくるヘルパーイメージ`gaiadocker/iproute2`は書き写さないでください。1.6.0のヘルパーの既定値は`ghcr.io/alexei-led/pumba-alpine-nettools:latest`です。

コンテナで動かす場合、PumbaはDockerソケット経由でホストのコンテナを操作できるため、実質的にホストのroot権限を持ちます。共有の検証環境では、実行できる人を限定してください。

## Pumbaの基本構文と対象コンテナの指定方法

構文は`pumba [グローバルオプション] コマンド [コマンドオプション] 対象コンテナ`です。`--interval`・`--random`・`--label`・`--dry-run`はグローバルオプションなので、コマンド名より前に置きます。netemやiptablesの`--duration`は、`delay`などのサブコマンドより前に置きます。

### 名前・re2正規表現・ラベルでの絞り込み

```
# 名前で指定（複数並べられる）
pumba kill myapp mydb

# RE2正規表現は "re2:" を先頭に付ける
pumba kill "re2:^test"

# ^test に一致するコンテナから1つだけ無作為に選び、30秒ごとに停止
pumba --interval=30s --random kill "re2:^test"

# ラベルで絞る（複数指定はAND条件・Docker向け）
pumba --label app=db kill "re2:.*"
```

`--label`はDocker APIの`filters`パラメータとして渡されます。Docker Composeで起動したコンテナは、Compose v2の既定では`プロジェクト名-サービス名-連番`という名前になります。名前が変わりやすい環境では、`com.docker.compose.service=db`のようなラベル指定のほうが安定します。

対象から外したいコンテナには`com.gaiaadm.pumba.skip=true`ラベルを付けます。検証環境では、このラベルのコンテナを名前で直接指定しても`no containers found`となり、選ばれませんでした。

### dry-runで計画を確かめる手順

`--dry-run`を付けると、実際の障害は起こさず計画だけを出力します。1.5.0からは、netemとiptablesで適用と解除の実コマンドまで表示されます。次の出力は1.6.0の実行結果です。コンテナ名は読みやすく置き換え、シェルの引用符と事前確認の行は省いています。

```
$ pumba --dry-run netem --duration 30s delay --time 200 mydb
would run on /mydb via sidecar ghcr.io/alexei-led/pumba-alpine-nettools:latest:
  apply:  tc qdisc add dev eth0 root handle 504d: netem delay 200ms 10ms 20.00
  revert: tc qdisc del dev eth0 root handle 504d:
```

`--jitter`を指定していないのに、`10ms`の揺らぎと相関`20.00`が入っています。`netem delay`の既定値だからです。`--duration 30s`を渡しても実行は0.69秒で終わりました。CIの前段では確認処理の時間はかかりますが、指定した30秒の終了待ちは発生しません。

## 障害を残さない実行手順（max-targets・run-id・status・revert）

netem・iptables・pause・stressと、`--restart`付きのstopは終了時に解除処理を行います。kill・rm・`--restart`なしのstopは、正常終了しても元の状態には戻しません。問題は解除の前にPumbaが落ちた場合です。ここからの実測はColima上のDocker Engine 29.5.2（linux/amd64、cgroupfs）とPumba 1.6.0のイメージで、2026年11月8日に行いました。遅延はコンテナ間のpingで測っています。

### 対象数の上限とrun-idを付けた実行

```
pumba --max-targets 1 --max-duration 15m --run-id drill-01 \
  netem --duration 5m delay --time 3000 --jitter 0 mydb
```

`--max-targets`は既定で無効なので明示します。2件選ばれる条件で`--max-targets 1`を渡すと、`refusing to run: 2 containers selected, --max-targets is 1`で何も注入せずに終了コード1になりました。`--skip-error`を付けても同じです。正規表現の書き間違いで全コンテナを止める事故は、これで防げます。

`--max-duration`は実行時間の予算です。3秒を指定して30秒のnetemを流すと、約5.4秒で終了コード1になり、その後の`status --check`は`clean`でした。解除が終わるまで待つため、指定どおりの秒数では止まりません。

### 0件一致をCIで失敗にするndjson判定

対象名が1件も一致しないとき、Pumbaは警告を出すだけで終了コード0を返します。これは1.6.0でも変わりません。障害が入らなかったのに「耐えた」と記録される誤判定になるので、結果イベントで判定します。

```
set -euo pipefail
pumba --output ndjson --run-id ci-42 --max-targets 1 \
  netem --duration 30s delay --time 200 --jitter 0 mydb | tee pumba.ndjson
jq -e 'select(.type=="run.end") | .status=="ok"' pumba.ndjson
```

存在しない名前で実行すると、`run.end`の`status`は`no_targets`になりました。上の`jq -e`は`false`を受けて終了コード1で落ちます。`status`の値と終了コードの対応は[agents.md](https://github.com/alexei-led/pumba/blob/1.6.0/docs/agents.md)にあります。

### kill -9で残った障害の確認と復旧の実測

障害の注入中にPumbaのコンテナを`docker kill`で落とし、残り方を比べました。

| 障害                  | kill直後の状態     | `status --check` | `revert --run-id` |
| ------------------- | ------------- | ---------------- | ----------------- |
| netem delay 200ms   | 平均200.5ms のまま | dirty（exit 1）    | 除去されず exit 1      |
| iptables loss 確率1.0 | 損失100% のまま    | dirty（exit 1）    | 除去され exit 0       |
| stress –cpu 1       | サイドカーが稼働のまま   | dirty（exit 1）    | 除去され exit 0       |

差が出る理由は、iptablesのルールには`--comment "pumba:drill-01"`のように、サイドカーにはラベルでrun-idが刻まれる一方、qdiscにはコメント欄がないためです。`revert`はrunに帰属できないものを消さず、`qdiscs are not attributable to a run; not removed`と報告しました。netemの残留は手で消します。

```
# 先に中身を確かめ、ハンドル 504d: であることを確認する
docker run --rm --net container:mydb --cap-add NET_ADMIN --entrypoint tc \
  ghcr.io/alexei-led/pumba-alpine-nettools:latest qdisc show dev eth0

docker run --rm --net container:mydb --cap-add NET_ADMIN --entrypoint tc \
  ghcr.io/alexei-led/pumba-alpine-nettools:latest qdisc del dev eth0 root handle 504d:

pumba status --check mydb   # clean なら終了コード0
```

ヘルパーイメージの既定エントリーポイントは`tail`なので、`--entrypoint tc`を省くと終わらないコマンドになります。削除後のpingは平均0.11ミリ秒に戻り、`status --check`は`clean`でした。

`status`も`revert`も、対象を省くと稼働中の全コンテナを検査します。他のシステムが同居するホストでは、必ずコンテナ名を渡してください。`revert`は元の実行が止まっていることが前提で、走行中のrunには使いません。

## コンテナ障害の注入（kill・stop・pause・rm・restart・exec）

```
# SIGKILLで強制終了（--signal SIGTERM などに変更可）
pumba kill --signal SIGKILL myapp

# 5秒間だけ一時停止し、自動で再開
pumba pause --duration 5s myapp

# 停止して20秒後に起動し直す
pumba stop --restart --duration 20s myapp

# 削除（Dockerでは既定で稼働中も強制削除し、匿名ボリュームも消える）
# ボリュームを残すなら --volumes=false を明示
pumba rm --volumes=false myapp
```

`kill`・`stop`・`pause`はランタイムのAPIを呼ぶだけで、ヘルパーコンテナを使いません。`--limit`で一度に操作する台数を絞れます（0は一致した全台）。

### stopのdurationとrestartの併用条件

`stop`の`--duration`は、`--restart`を付けたときだけ使われます。dry-runで`stop --duration 2s myapp`を実行すると停止のログだけが出ました。`--restart`を付けると、`starting container`のログが続きます。「一定時間止めて戻す」つもりで`--restart`を落とすと、コンテナは止まったままになります。

### execのcommand・args指定と既定のkill 1

`exec`は、実行する内容を`--command`と`--args`で指定します。`docker exec`と同じ感覚で`pumba exec myapp -- touch /tmp/testfile`と書くと、`--`以降は無視されます。1.6.0のdry-runでも`command="kill 1"`となり、コンテナのPID 1を終了させる既定値が選ばれました。

```
# 正しい書き方
pumba exec --command "touch" --args "/tmp/testfile" myapp
```

ファイルを作るつもりでコンテナを落とす事故になるので、execを使うときは必ずdry-runでcommandの値を確認してください。

## ネットワーク障害の注入（netemとiptables）

netemはLinuxカーネルのトラフィック制御（`tc qdisc netem`）を使います。効くのはコンテナの送信側（egress）だけです。受信側を落としたい場合は`iptables`コマンドを使います。

### netemの遅延・損失・帯域制限と既定値

```
# 3秒の遅延を5分間
pumba netem --duration 5m delay --time 3000 mydb

# 送信パケットの5%を破棄
pumba netem --duration 5m loss --percent 5 mydb

# 送信帯域を1Mbitに制限
pumba netem --duration 10m rate --rate 1mbit mydb

# 10%を破損・10%を重複
pumba netem --duration 5m corrupt --percent 10 mydb
pumba netem --duration 5m duplicate --percent 10 mydb
```

200ミリ秒の遅延を実コンテナに入れ、20回のpingを4回繰り返した結果です。注入前の平均RTTは0.1〜0.3ミリ秒でした。`--jitter 0`では200.2〜201.0ミリ秒に収まり、既定のjitterでは190.5〜210.4ミリ秒に揺れました。タイムアウトの境界値を試すときは`--jitter 0`を明示してください。

`--duration`を省略すると`unset or invalid duration value`で終了します。`--interval 3s`に`--duration 5s`を渡すと`duration must be shorter than interval`で起動しません。損失をまとまって発生させたい場合は、4状態マルコフモデルの`loss-state`か、Gilbert-Elliottモデルの`loss-gemodel`を使います。

### netem combineによる単一qdiscへの複合効果の設定

1.2.0で`netem combine`が追加され、遅延と損失のような複数の効果を1つのqdiscにまとめて設定できるようになりました。

```
# 100msの遅延と20%の損失を同時に
pumba netem --duration 5m combine \
  --delay --delay-time 100 \
  --loss --loss-percent 20 \
  -- mydb
```

効果を1つしか指定しないと`at least two netem effects are required`で拒否されます。Pumbaが作るqdiscには予約ハンドル`504d:`が付き、Pumba以外が作ったqdiscは書き換えずに拒否します。

### targetとmatch-allで特定の通信だけ劣化させる方法

`--target`を付けると、指定した通信先への通信だけを劣化させられます。IPv4アドレス、CIDR、稼働中のコンテナ名またはIDを指定でき、コンテナ名は実行のたびにIPアドレスへ解決されます。

```
# service-a から service-b への通信だけに1秒の遅延
pumba netem --duration 10m --target service-b delay --time 1000 service-a

# 10.0.0.1 宛て、かつ送信元ポート5432 の通信だけ（1.6.0）
pumba netem --match-all --duration 5m --target 10.0.0.1 --egress-port 5432 \
  delay --time 200 mydb
```

`--target`と`--egress-port`を併用するとき、`--match-all`の有無で意味が変わります。dry-runの計画では、無しだと`tc filter`が2行に分かれてどちらか一方に一致すれば遅延します。有りだと1行の`match ip dst … match ip sport …`にまとまり、両方に一致した通信だけが対象です。「DBへの通信だけ遅い」を再現したつもりで全ポートを巻き込まないように、複数の条件を組むなら`--match-all`を付けます。IPv6は`--target`の対象外で、渡すと`is not supported`で終了します。

### iptables lossによる受信パケットの破棄

```
# 受信パケットの10%を2分間破棄
pumba iptables --duration 2m loss --probability 0.1 myapp

# 192.168.1.100から8080番ポートへのTCPを5パケットに1つ破棄
pumba iptables --match-all --duration 5m --protocol tcp --source 192.168.1.100 --dst-port 8080 \
  loss --mode nth --every 5 myapp
```

`--probability`は0.0〜1.0の割合で、netemの`--percent`とは単位が違います。`--dst-port`を指定するときは`--protocol tcp`か`udp`が必須で、省くと`using destination port is only supported for tcp and udp protocol`で止まります。`--match-all`を付けない場合、dry-runの計画では`-s`と`--dport`のルールが2本に分かれ、どちらかに一致したパケットが破棄対象になります。

### ヘルパーイメージとminikubeでの制約

対象コンテナに`tc`や`iptables`が入っていなくても、Pumbaがヘルパーコンテナを起動して処理します。独自イメージを`--tc-image`で指定する場合は、[ネットワーク障害のガイド](https://github.com/alexei-led/pumba/blob/1.6.0/docs/network-chaos.md)にある必須コマンド（`sh`・`grep`・`tc`に加え、Docker・Podmanでは`which`・`tail`、containerdでは`sleep`、`--match-all`では`awk`）を含めます。`status`と`revert`には`iptables-nft`か`iptables-legacy`の実体も要ります。公式のヘルパーイメージには入っています。minikubeはVMに`sch_netem`カーネルモジュールが無くnetemが動かないと、デプロイガイドが注意しています。

## CPU・メモリ負荷の注入（stressとinject-cgroup）

```
# CPU 2ワーカーを負荷80%で1分（1.4.0以降のフラグ）
pumba stress --duration 1m --cpu 2 --cpu-load 80 myapp

# CPU 2ワーカーと256MBのメモリ確保を30秒
pumba stress --duration 30s --cpu 2 --memory 1 --memory-bytes 256M myapp

# 対象と同じcgroupに入れて負荷をかける
pumba stress --inject-cgroup --duration 60s --cpu 2 myapp
```

1.4.0で`--cpu`・`--memory`・`--io`のフラグが入り、stress-ngの`--timeout`は`--duration`から自動で作られます。従来の`--stressors`も使えますが併用はできません。stressは`ghcr.io/alexei-led/stress-ng:latest`をサイドカーとして起動します。

### systemdドライバの既定モードとリソース制限の非共有

既定モードは、Dockerの`--cgroup-parent`でサイドカーの配置先を決めます。cgroupドライバが`cgroupfs`なら対象の子cgroupに入り、対象のCPU・メモリ制限を共有します。cgroupfsの環境で`--cpu 1 --cpu-load 50`を流すと、`docker stats`にはサイドカーで51.34%、対象コンテナ側にも48.82%が計上されました。`systemd`ドライバでは子cgroupを作れないため、サイドカーは`system.slice`の兄弟cgroupに置かれ、対象コンテナの制限は共有されません。

ホストのドライバは`docker info`の「Cgroup Driver」欄で確認できます。systemdのホストで既定モードのまま「メモリ上限に達したときの挙動」を試しても、対象コンテナは上限に届きません。対象と同じcgroupで負荷をかけるには`--inject-cgroup`を使います。stress-ngイメージのタグ0.20.01（2026年2月27日公開）以降が必要で、OOMの範囲も対象と共有するため、対象コンテナ自体がOOMで終了する可能性があります。

## KubernetesでPumbaを使うときのDaemonSet構成

公式リポジトリの`deploy/pumba_kube.yml`は、各ノードの`/var/run/docker.sock`をマウントするDaemonSetで、イメージも旧名の`gaiaadm/pumba`のままです。Kubernetesは1.24でdockershimを削除したため、containerdで動く[現行のKubernetes](/tech/details/17151/)ではそのまま使えません。[公式のデプロイガイド](https://github.com/alexei-led/pumba/blob/1.6.0/docs/deployment.md)にcontainerd向けの例がありますが、そこにある`--label`の指定を次のように直す必要があります。

```
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: pumba-containerd
  namespace: pumba # 事前に kubectl create namespace pumba で作成
spec:
  selector:
    matchLabels:
      app: pumba
  template:
    metadata:
      labels:
        app: pumba
    spec:
      hostPID: true
      containers:
        - name: pumba
          image: ghcr.io/alexei-led/pumba:1.6.0
          args:
            - --runtime
            - containerd
            - --containerd-namespace
            - k8s.io
            - --max-targets
            - "1"
            - --interval
            - 30s
            - netem
            - --duration
            - 20s
            - --tc-image
            - ghcr.io/alexei-led/pumba-alpine-nettools:latest
            - delay
            - --time
            - "3000"
            - "re2:^default/target-pod/"
          securityContext:
            privileged: true
          volumeMounts:
            - name: containerd-socket
              mountPath: /run/containerd/containerd.sock
      volumes:
        - name: containerd-socket
          hostPath:
            path: /run/containerd/containerd.sock
```

### containerdで失敗するlabel指定とre2での代替

1.6.0の`pkg/runtime/containerd/client.go`は、ラベルの指定があると`label filtering is not yet implemented`を返します。containerdのソケットに`--label`付きで接続すると、このメッセージで終了コード1になりました。READMEのフラグ表には未対応と書かれており、デプロイガイドの例は実装と合っていません。

containerdでは、KubernetesのコンテナにPumbaが`namespace/pod/container`形式の名前を付けます。`re2:^default/target-pod/`のように名前空間とPod名で絞ってください。Podラベルでの保護も当てになりません。[ユーザーガイド](https://github.com/alexei-led/pumba/blob/1.6.0/docs/guide.md)は、Pumbaが読むのはランタイムのコンテナのラベルでありPodのメタデータではないと明記しています。除外リストではなく、対象を許可リストの形で指定します。

この構成はノード上の全コンテナを操作できる特権DaemonSetです。対象を`nodeSelector`で検証用ノードに限定し、本番クラスタの常設には使わないでください。

## Pumbaを選ぶ場面と他のカオスツールを選ぶ場面

| ツール         | 主な対象                | 提供形態                     | 最新版（2026年11月8日時点）   |
| ----------- | ------------------- | ------------------------ | ------------------- |
| Pumba       | 単一ホストのコンテナ          | OSS・CLI                  | 1.6.0（2026-11-05）   |
| Chaos Mesh  | Kubernetes          | OSS・CRD（CNCF Incubating） | v2.8.8（2026-11-06）  |
| LitmusChaos | Kubernetes          | OSS・CRD（CNCF Incubating） | 3.33.0（2026-10-15）  |
| Toxiproxy   | TCP通信               | OSS・プロキシ                 | v2.13.0（2026-10-14） |
| Gremlin     | ホスト・コンテナ・Kubernetes | 商用SaaS                   | サービス型               |
| AWS FIS     | AWSのリソース            | マネージド                    | サービス型               |

最新版はGitHub Releases APIの値です。成熟度は[Chaos Mesh](https://www.cncf.io/projects/chaosmesh/)と[LitmusChaos](https://www.cncf.io/projects/litmus/)のCNCFプロジェクトページで確認しました。[Gremlinの料金ページ](https://www.gremlin.com/pricing)に定価は無く、個別見積もりです。30日間のトライアルはクレジットカードなしで始められます。

Pumbaが向いているのは、Docker ComposeやCIの結合テストで「DBが3秒遅れたら」「キャッシュが落ちたら」を再現する場面です。クラスタにコンポーネントを入れる必要がなく、バイナリ1つかイメージ1つで始められます。[Dockerのコンテナ起動コマンド](/tech/details/3935/)で環境を立ち上げ、そのままPumbaで障害を入れる流れが最も手軽です。

Kubernetesのクラスタ全体で実験を管理するなら、Pumbaは選ばないほうがよいです。PumbaにはPod単位の実験定義と、CRDとして残る実験履歴がありません。特権DaemonSetを置く運用も重くなります。この場合はCRDで実験を宣言できるChaos MeshかLitmusChaosを使います。AWSのマネージドサービスを止める実験は、コンテナの外側で起きるためPumbaでは作れません。[AWS Fault Injection Service（FIS）](/tech/details/15636/)の領域です。障害を前提にした基盤の設計ごと見直すなら、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)も相談先になります。

Toxiproxyはアプリとの間にTCPプロキシを挟む方式で、コンテナの権限を必要としません。アプリの接続先をプロキシに向けられるなら、NET\_ADMINや特権を避けたいCI環境ではToxiproxyのほうが扱いやすい場合があります。実験設計や停止条件の決め方は[カオステストの実験設計とツール選定](/tech/details/16269/)でまとめています。

## よくある質問

### Pumbaという名前にはどういう意味がありますか？

ツール名の由来は、READMEや公式ドキュメントには書かれていません。検索で「pumba」と調べると、Instagramで人気のカラカルや、『ライオン・キング』のイボイノシシ（綴りはPumbaa）の情報も表示されます。この記事で扱うPumbaは、GitHubの`alexei-led/pumba`で公開されているコンテナ向けのカオステストツールです。

### PumbaはDockerコンテナとして実行できますか？

できます。READMEが推奨する方法で、`docker run -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/alexei-led/pumba:1.6.0`の後ろにPumbaのコマンドを続けます。イメージは`scratch`ベースで、Pumbaのバイナリに加えてCA証明書とタイムゾーンデータを含みます。ソケットを渡すのでホストのroot相当の権限を持つ点と、CIでは版のタグを固定する点に注意してください。

### PumbaのGitHubリポジトリとライセンスは？

リポジトリは`github.com/alexei-led/pumba`、ライセンスはApache License 2.0で、Go言語で書かれています。2026年11月8日時点でスター数は約3,200、最新版は1.6.0です。1.3.0以降は短い間隔でリリースが続いているため、導入時にリリース一覧で最新の版を確かめてください。

### WindowsでPumbaは使えますか？

使えません。Windows向けバイナリは配布されておらず、READMEにはWindows対応のプルリクエストも受け付けないと書かれています。netnsやcgroupなどLinuxの機能に依存するためで、WSL2上のDocker Desktopでも同じ扱いです。Windows端末から使う場合は、Linux VMの中でPumbaを実行してください。

### PumbaとChaos Monkeyの違いは何ですか？

Chaos Monkeyは、Spinnakerで管理しているクラウドのインスタンスを無作為に終了させるツールです。PumbaはChaos Monkeyに着想を得ていますが、対象はコンテナで、終了だけでなくネットワーク遅延やCPU負荷も注入できます。Spinnakerも必要なく、バイナリ1つかコンテナイメージ1つで動きます。

## 関連記事

- [カオステストとは？障害注入の実験設計とツール選定・本番実施の判断を実装者向けに解説](/tech/details/16269/)
- [AWS Fault Injection Service（FIS）とは？カオスエンジニアリングの仕組み・実験テンプレート・料金と採用判断を実装者目線で解説](/tech/details/15636/)
- [サーキットブレーカーとは？マイクロサービスの障害連鎖を止める仕組みと実装・導入判断を解説](/tech/details/13216/)
- [バルクヘッドパターンとは？障害隔離の仕組みと実装方法・採用判断を実装者目線で解説](/tech/details/16187/)
- [Dockerコンテナ起動コマンドの使い分け｜run・start・execと起動しない時の対処](/tech/details/3935/)

---

出典: [Pumbaとは？Dockerコンテナにカオステストを行う使い方とコマンド【1.6対応】](<https://www.issoh.co.jp/tech/details/9700/>)（株式会社一創）