Kubernetes 1.35のIn-Place Pod Resizeが、ステートフル運用の“経済性”と“安全な俊敏性”を同時に押し上げる理由

今日の深掘りポイント

• In-Place Pod ResizeがKubernetes 1.35でGAになり、Podを落とさずCPU/メモリのリクエスト/リミットを動的に調整できるようになりました。ステートフル運用の「止めないスケーリング」の実装コストが現実的になります。
• VPA（Vertical Pod Autoscaler）と組み合わせると、再作成やEvictionに頼らない“静かな最適化”が可能になり、DBやストレージ系のキャッシュ・バッファ運用の柔軟性が一段上がります。
• リソースの過不足を短時間で是正できるため、クラスタ密度と電力効率（コスト/サステナビリティ）に寄与します。需給制約が続くエネルギー環境下で、インフラの戦略価値を底上げします。
• 一方で、マルチテナント環境ではQuota/LimitRangeの整合、QoSクラスの変化、HPAとの制御ループ干渉など、新たな運用ガードレール設計が必要になります。
• セキュリティ観点では「権限を持つ主体がPodを再起動なしで太らせられる」ことの管理・検知・是正が焦点になります。RBACとAdmission、監査を通した“誰が、いつ、どれだけ増やしたか”の可視化を前提化するべきです。

はじめに

「止めずに、いま必要な分だけ、賢く増減する」。コンピューティングの古くて新しい理想に、Kubernetesは長らく“再作成”というコストで応じてきました。1.35でのIn-Place Pod ResizeのGAは、その前提を静かに書き換えます。特に、データベースや分散ストレージのようなステートフル系にとって、メモリやCPUのリサイズがダウンタイムなしで適用できる意味は大きいです。SRE/プラットフォームの現場では、オーバープロビジョニングからの解放と、電力・クラウド費用の圧縮が同時に視野に入ります。読者の皆さんに向けては、単なる新機能の紹介ではなく、運用モデル・ガバナンス・セキュリティを横断して効く“設計変更点”として捉え直してほしいアップデートです。

深掘り詳細

事実整理：何が“インプレース”になったのか

• 機能の核は、Pod（正確には各コンテナ）のCPU/メモリのrequests/limitsを、PodをKill/再作成せずに更新できる点です。従来のVPAはEviction前提の再起動が付きまといましたが、1.35ではKubelet/cgroupレベルの再設定によって、同一Podのまま資源の増減が反映されます。
• ステートフルワークロードでは、再起動コスト（ウォームアップ、再接続、レプリカ再同期）がボトルネックでした。インプレース化により、ピーク時の一時的な増枠や、夜間の縮退といった“機動的な右サイズ”が現実的になります。
• VPAは本機能と親和性が高く、従来の再作成を伴う適用モードに加えて、インプレース適用の選択肢が広がります。実運用では、DBやメッセージング基盤など“落ちたら痛い”系で真価を発揮します。
• なお、ボリューム（PV）のサイズ拡張は別機能領域です。ストレージ容量のオンライン拡張はStorageClassやCSIの対応に依存するため、CPU/メモリのインプレースと混同しない設計が必要です。

参考（解説記事）:

• The New Stack: Kubernetes VPA In-Place Resize

インサイト：ステートフルに効く3つの“運用価値”

1. ダウンタイムの非対称性を打ち消す価値
   ステートフルでは1分の停止がSLOより重く響きます。インプレース化は“停止の固定費”を事実上ゼロに近づけ、メモリキャッシュの再ウォームやレプリカ再調停の尾を断ちます。結果として、SLO消費を抑えながらピーク対応ができます。

2. “安全な過小化”を許す価値
   従来は過小リソースが即SLO違反に繋がるリスクから、保守的な過大割当が常態化していました。インプレース化により、ベースラインは細く、必要時に太くという運用が可能になり、密度・電力効率の最大化に寄与します。これは費用だけでなく、電力ひっ迫時の負荷平準化（デマンドレスポンス的な使い方）にも繋がります。

3. “変えた瞬間”の安全を担保する価値
   再起動を挟まないため、接続やセッションの連続性が維持されます。DBのように接続プールやバッファが大きく状態を持つプロセスでは、変化点での障害リスクが減り、SREのナイトオペから緊張を一つ外せます。

プラットフォーム設計で押さえるべき論点（仮説を含みます）

• スケジューリングとノード圧迫
  インプレース増枠はスケジューラの再配置を伴わないため、ノード内の“リソース断片化”が進む可能性があります。ピーク時に「増やしたいが置き場所がない」ケースや、ノードのEviction Managerが閾値を超えて予期せぬPod退避を起こすリスクに注意が必要です。定期的なデフラグ（Deschedulerの活用や計画的ローリング）を設計に含めるのが現実的です。

• QoSクラスとSLOのゆらぎ（仮説）
  requests/limitsの関係が変わることでQoSクラス（Guaranteed/Burstable/BestEffort）が遷移しうるケースがあります。これが起きると、OOM優先度やスロットリング挙動が変わり、SLOの安定性に影響する可能性があります。設計上、QoSクラスを跨ぐ変更を抑制するポリシーを検討する価値があります。

• HPAとVPAの相互作用
  HPAは“要求あたり利用率”を信号として使うのが一般的です。requestsがインプレースで上下すると、同一負荷でも利用率が変わり、HPAの制御ループが想定外の方向に動くことがあります。実装パターンとしては「VPA=メモリ、HPA=CPU」に機能分離し、干渉を最小化するのが無難です（一般論）。

• マルチテナントのガードレール
  Quota/LimitRangeとAdmissionの組み合わせがこれまで以上に重要になります。インプレース拡張がAdmissionを通る設計であっても、「誰がPodのspec更新を許されるか」「VPAのみ許可か」などRBACの粒度設計が問われます。加えて、監査ログで“増枠の一挙動”が追えることを前提要件に置くべきです。

• 観測とフィードバック
  requests/limitsの時系列がSLO/コスト可視化の軸になります。変化点でのp95レイテンシ、キャッシュヒット率、スロットリング、OOM近傍指標を束ねた“リサイズ有効性レポート”をダッシュボード化し、右サイズの学習速度を上げると、密度とSLOの最適点に早く近づけます。

将来の波及と戦略価値

• エネルギーとコストの弾力化
  需要の山谷に合わせて素早く増減できることは、単なる費用削減に留まらず、電力需給のひっ迫時に“落とさずに絞る”オプションを提供します。製造・金融・通信など常時高可用が求められる領域でも、業務影響を最小化した需要応答が描けます。

• アプリケーションアーキテクチャの再設計
  これまで“落ちない設計”のために組み込んでいた冗長なキャッシュやワーカの過剰配置は、インプレース拡張と組み合わせることでスリム化の余地が生まれます。ミドル層でのキャッシュ政策（例：ヒット率閾値でメモリ増枠）を取り込んだ「アプリ主導オートチューニング」への流れが加速するはずです（仮説）。

• 認証・権限・責任の再定義
  Pod再起動を伴わない“静的想定の変更”が可能になったことで、変更管理の責務境界が曖昧になりやすいです。SRE/プラットフォーム/アプリの分掌と、誰がどの閾値で増減をトリガできるのかを再合意するタイミングです。監査と回帰抑止（ガードレール）を前提化した“変更の自由”が、結果として組織の俊敏性を高めます。

セキュリティ担当者のアクション

• RBACの見直し
  Podのupdate権限（特にspec.resourcesの更新）を原則コントローラ（VPA等）に限定し、人手の直接パッチは申請フロー経由に制限します。名前空間ごとの最小権限を徹底します。

• Admission/Policyでのガードレール
  Gatekeeper/Kyverno等で以下を制約します。

  • 1回あたりの増枠上限、総増枠回数（時間窓）
  • QoSクラスを跨ぐ更新の禁止（仮説）
  • リクエスト＞クォータ超過を即時拒否
  • 更新は特定のServiceAccountのみ許可

• 監査と検知
  APIサーバ監査でPodのpatch/update（resources変更）を必ず記録し、SIEMでアラートを設定します。未知の主体からの連続増枠、業務時間外の大幅増枠、VPAを介さない更新は高優先度で調査します。加えて、増枠直後の暗号資産マイニング様のメトリクス（CPU 100%張り付き、異常な外部接続）を相関検出します。

• Quota/LimitRangeの“動的時代”対応
  最大・最小・デフォルトのrequests/limitsを現実のプロファイルに合わせて再定義し、Burstの幅を明確にします。名前空間ごとの上限はインプレース増枠が重なる前提で余白を計算し直します。

• HPA/VPAの責務分離
  制御の干渉を避けるため、HPAはスケールアウト（Pod数）に専念、VPAはスケールアップ（Pod当たり資源）に専念という原則を敷きます。メモリのみVPA、CPUはHPAという分担は現実的です。制御ループの安定化のため、クールダウンとヒステリシスを強めに設定します。

• 失敗モードの演習
  「ノードに余白がない状態での増枠要求」「縮小しすぎてスロットリング/OOMが出る」「Quota衝突」などを事前にGameDayで検証し、Runbook化します。イベント相関（増枠→EvictionManager発火など）をモニタで見える化しておくと実戦で強いです。

参考情報

• The New Stack: Kubernetes VPA In-Place Resize

（注）上記は機能の一般的な設計・運用知見に基づく分析で、一部に仮説を含みます。各クラスタの特性（ランタイム、cgroup、スケジューラ設定、CSI対応）によって挙動が異なる場合があります。実機検証で前提を固めたうえで、段階的な導入をお勧めします。