はじめに ― なぜシミュレータが必要なのか？

Kubernetes の kube‑scheduler は Pod をどのノードへ配置するかを決めるコントロールプレーンの要（かなめ）です。ところがスケジューラ内部は複数のプラグインが連携するブラックボックスになりがちで、

といった悩みが絶えません。そこで登場したのが kube‑scheduler‑simulator です。GSoC 2021 で生まれ、現在は SIG Scheduling が中心となって開発が続いています。

kube‑scheduler‑simulator とは？

これらの機能により「ミスを本番で知る」悪夢を防ぎつつ、スケジューラ開発者だけでなく一般ユーザーも気軽に検証できます。

Simulator サーバー
- HTTP API と Web UI を提供
Debuggable Scheduler
- 通常の kube‑scheduler を拡張し、各プラグイン結果を記録
KWOK（Kubernetes WithOut Kubelet）
- etcd／kube‑apiserver／controller‑manager を軽量起動し、フェイクリソースを即時反映
ユーザー操作
1. kubectl / Web UI で Pod を作成
2. スケジューラが Filter → Score → Bind を実行
3. 各段階の結果が Pod アノテーションに追加
4. Web UI が結果を表・グラフで可視化

この一連の流れは公式 how‑it‑works ドキュメントでも詳しく説明されています。

git clone https://github.com/kubernetes-sigs/kube-scheduler-simulator.git
cd kube-scheduler-simulator
make docker_up        # 依存イメージを取得して全コンポーネントを起動

ブラウザで http://localhost:3000 を開けば準備完了！ YAML エディタで Node / Pod / Deployment などを作成し、右ペインでスケジューリング結果を確認できます。

Node を 3 台作成（ラベル zone=A/B/C）
ReplicaSet で 6 Pod を作成。topologySpreadConstraints で maxSkew: 1 を指定
Web UI の Result タブを見ると、PodTopologySpread プラグインが passed と判定し、各ゾーンに 2‑2‑2 で分散されたことがスコア表に表示されます。
スコア列をクリックすると、各プラグインが付与した点数が色分けで見えるので、Spread の重み付けや他プラグインとのバランスをすぐに把握できます。

β機能の Import Cluster Resources を使うと、本番クラスターの API サーバーから

のどちらかを選択できます。シミュレータ側ではスケジューラだけを置き換え、既存 workload へ影響を与えずに将来の設定変更やバージョンアップを検証できます。

役割	具体的な使い道
クラスター利用者	Affinity / Spread / Taints が期待通りか確認
クラスター管理者	新しい `kube-scheduler` Config や FeatureGate の影響評価
プラグイン開発者	カスタムプラグイン／Extender のデバッグと CI 統合
SRE / 教育担当	スケジューラ内部アルゴリズムの教材、障害再現

Controller が最小限
- ReplicaSet など一部コントローラは存在しないため、Pod 以外の高位リソースは自動展開されません。必要に応じて手動で Pod を生成してください。
通信先がローカルのみ
- デフォルト compose は localhost 前提。リモートで動かす場合は .env や compose.yml のポートを調整します。
アノテーション仕様が変わる場合あり
- 2024 年 11 月の v0.4.0 で名前空間が scheduler-simulator/* → kube-scheduler-simulator.sigs.k8s.io/* に変更されました。解析ツールを書く際は注意しましょう。

kube‑scheduler‑simulator は

という三拍子そろったツールです。make docker_up で数分あれば試せますので、ぜひ一度 “目に見えるスケジューリング” を体験してみてください。