Skip to content

ポリシーシミュレーター

デプロイ前にローテーションスケジュールを確認。 RotationPolicy の設定とノード数を入力すると、各ノードがいつローテーションされるか、そして expireAfter のバックストップ前に間に合うかが即座に分かる。

いつ使うか

  • メンテナンスウィンドウを決める前 — そのウィンドウ幅でフリートをさばけるかテスト
  • minRotationChancescooldownAfterexpireAfter を変えるとき — 効果を即座に確認
  • ThroughputBurstShortfallThroughputBelowArrival の警告が出る理由を理解したいとき
  • 同期バッチ(全ノードが同じ age)とスケジュールの相互作用を可視化したいとき

結果の読み方

  • 緑のノードexpireAfter 期限前にローテーションが完了。graceful パスが機能している。
  • オレンジのノード — surge-less の forceful fallback で回された(有効時)。ウィンドウ内かつ PDB 尊重だが、make-before-break ではない。
  • 赤のノード — コントローラーが回しきれず expireAfter 期限に到達。Karpenter のネイティブな forceful expiration にフォールバック。

健全な設定では全て緑になる。オレンジはスループットが逼迫しているが制御下。赤はスケジュールの拡張が必要。

対象範囲

シミュレーターはローテーションの開始・完了(forceful fallback 含む)をモデル化する。障害(surge タイムアウト、retryBackofffailurePause)はモデル化しない。結果はベストケースの予測であり、本番環境の保証ではない。

仕組み(技術詳細)

このページはコントローラー自身の Go コード — ageThreshold 導出、候補選択の述語、開始ゲート — を WebAssembly にコンパイルして実行する。シミュレーターとコントローラーは同一実装を共有し、乖離できない(CI がこれを保証する)。

ポリシー

YAML が正本です(シミュレーターはクラスタと同じ厳密さでこれをデコードします)。フォームはこの YAML をその場で書き換えます。

メンテナンスウィンドウ — ローテーションを「開始してよい」時間帯
曜日
ウィンドウが繰り返される曜日
導出 — ノードをどれだけ早く選ぶか
surge — 1 回のローテーションの動き方

ノード群

シミュレートするノード。ジェネレーターでバッチ生成し、個別行を編集することもできる。

名前作成時刻expireAftertGP

シミュレート上の実所要時間(仮想世界で実際に起きること)

これはポリシーの estimate ではありません。estimate は予測、こちらは実際に起きること。両者をずらした状態こそが見どころです(estimate が楽観的すぎて C が過大なポリシー、など)。

シミュレート期間

最長のノード寿命(expireAfter)の倍数です。「世代数」ではありません: createdAt のばらつき、ノードごとの上書き、ウィンドウ待ち、cooldown のいずれもその等価性を壊します。

寿命カバレッジ

2026-02-17T00:00:00.000Z

正確なシミュレート期間(ISO 8601)

診断

診断はありません。