GKE nodepool sizing

ルール ID: gcp.gke.nodepool.sizing ・ カテゴリ: sizing ・ 必要な読み取り: インベントリ + 利用メトリクス 計画中

ノードプールの machineType が実際の負荷に対して大きすぎると、使っていない CPU 分の料金を払い続けることになります。このルールは、実測利用率に対して過大なノードプールを見つけます。

このページは判定規範に従う予定仕様です。閾値・観測窓の根拠(出典)は実装時に付記します。

何を無駄とみなすか

プール全体の CPU 利用率が実測で低いまま、大きな machineType のノードを維持しているノードプール。ひとつ下のマシンサイズで同じワークロードを賄える場合、その差額が無駄になります。

判定条件

• ノードプール全体の集約 CPU 利用率が低い場合に、machineType の縮小を提案します(個々のノードではなくプール全体で判定)
• Autopilot クラスタは対象外です(ノードプールのサイズをユーザが管理しないため)
• 縮小先は、全ノードの実測負荷を収容できる安価な machineType が実在する場合にのみ提案します

必須 facts

• ノードプールの machineType・ノード数
• プール全体の CPU 利用率(観測窓の実測)
• クラスタのモード(Standard / Autopilot)
• 取得できない facts がある場合は「観測不能」と表示し、候補にしません(候補を捏造しない)。

誤検知・危険になり得る条件

• ピーク時間帯やスパイクに備えて意図的に余裕を持たせているプール
• メモリ・GPU・ローカルストレージなど、CPU 以外の資源がボトルネックのプール(CPU だけを見ると過大に見える)
• Pod の resource requests が現行のノードサイズを前提にしている場合(縮小後に Pod がスケジュール不能になり得る)

実行前の確認

• プール上の Pod の resource requests / limits の合計が縮小後のノードに収まるかを確認する
• cluster autoscaler・ノード数の上限設定との整合を確認する
• IaC(Terraform 等)での machineType の定義箇所と関係チームの合意を確認する

非破壊テストとロールバック

Safety Tier: medium(プールの追加・入れ替えによる可逆な構成変更)

1. 縮小後の machineType で新しいノードプールを追加する(既存プールはそのまま)
2. 一部のワークロードを新プールへ移して観察し、スケジュールやレイテンシに問題がないことを確認する
3. 問題がなければ旧プールを drain して削除する

ロールバック: 元の machineType でノードプールを再作成し、ワークロードを戻します。

効果検証

削減の確定は、変更前ベースラインと変更後請求の比較で行います(Verify)。