※この投稿は米国時間 2026 年 10 月 3 日に、Google Cloud blog に 投稿 されたものの抄訳です。 トラフィックの急増に対応してマイクロサービスを起動する場合でも、新しいソフトウェア リリースをデプロイする場合でも、アプリケーション レプリカをスケールアップする場合でも、Google Kubernetes Engine（GKE）で実行されるアプリケーションの高速で応答性の高いユーザー エクスペリエンスを維持するには、 Pod の起動時間 が重要です しかし、プラットフォーム エンジニアと開発者は、アプリケーションが起動時に定常状態の運用時よりも大幅に多くの CPU パワーを必要とすることが多いという、根強いジレンマに直面しています。通常の定常状態の使用量に合わせて CPU リクエストをサイジングすると、起動時に CPU スロットリングが発生し、コールド スタートの遅延や、readiness プローブのタイムアウトにつながる可能性があります。逆に、短時間の起動バーストに対応するためにベースライン CPU リクエストをオーバープロビジョニングすると、貴重なコンピューティング リソースが無駄になり、インフラストラクチャの費用が膨らみます。 このたび、GKE 向け CPU 起動ブースト のプレビュー版をリリースいたしました。GKE の VerticalPodAutoscaler（VPA）に直接統合された CPU 起動ブーストは、初期化中にコンテナの CPU 割り当てを動的に引き上げ、アプリケーションの準備が整うとシームレスにベースラインの定常状態レベルにスケールバックします。 コンテナを再起動する必要はありません。 新しいコンテナが起動すると、ユーザー リクエストの処理を開始する前に、負荷の高い初期化タスクが実行されることがあります。技術スタックによっては、起動時のワークロードで膨大な CPU サイクルが必要となります。 Java JVM アプリケーション : Spring Boot などのフレームワークでは、クラスの読み込み、クラスパスのスキャン、依存関係インジェクション コンテナのインスタンス化、ジャストインタイム（JIT）コンパイルの実行に、高い CPU バースト性能が必要です。 Node.

js サーバー : アプリは JavaScript ファイルを解析し、複雑なモジュール依存関係ツリー（ require / import ）を構築し、初期実行時に V8 エンジンの最適化と JIT コンパイルパスを実行します。 Python と AI / ML マイクロサービス : これらのサービスは、初期サイクルで、重いライブラリ（PyTorch、NumPy、LangChain など）のインポート、 .

pyc バイトコードのコンパイル、ORM データベース スキーマの確立、キャッシュ構造のプリロードを行います。 定常状態のパフォーマンスに合わせて CPU リクエストを厳密にサイジングすると、これらの初期化ワークロードでは起動時に CPU スロットリングが発生し、readiness プローブが遅延します。コールド スタートの遅延を防ぐために、CPU リクエストをオーバープロビジョニングするケースがよく見られます。しかし、アプリケーションが安定すると、それらの余分な CPU リソースはアイドル状態になり、何のメリットもないままクラウド費用を増加させることになります。 CPU 起動ブーストは、起動時にワークロードに一時的な vCPU「ブースト」を与え、初期化が完了すると自動的にベースラインに戻すことで、この問題を解決します。 これまで、Pod のリソース リクエストや上限を変更するには、Pod を削除して再作成する必要がありました。このように影響の大きいプロセスは、コンテナの再起動、キャッシュの無効化、そしてノードの再スケジューリングによるオーバーヘッドを引き起こしていました。 これを解決するために、CPU 起動ブーストは Kubernetes の インプレース Pod サイズ変更（IPPR） を基盤としています。 KEP-1287 として管理されている IPPR は、動的なインプレース リソース ミューテーションを導入しました。Kubernetes 1.

35 で一般提供（GA）となった IPPR を使用すると、Kubernetes コントロール プレーンと kubelet が、 コンテナ プロセスを再起動することなく 、実行中の Pod のコンテナ CPU とメモリのリクエストを更新できます。 GKE は、VPA 内の IPPR を活用して、Pod のアドミッション時に起動時の CPU ブーストを適用し、準備完了後にスムーズに引き下げます。 アドミッション フェーズ : Pod をデプロイすると、VPA アドミッション Webhook が作成リクエストをインターセプトします。ポリシー（2 倍の乗数や +2 vCPU など）に基づいて引き上げられた CPU リクエストを計算し、追跡アノテーションとともに Pod 仕様に挿入します。 起動フェーズ : Pod がスケジュールされ、ブーストされた CPU 割り当てで初期化されます。アプリケーションは、CPU スロットリングを発生させることなく、クラスの読み込み、JIT コンパイル、モジュールの解析を最高速度で完了します。 ブースト解除フェーズ : Pod の readinessProbe が成功すると（さらに、構成された durationSeconds のクールダウン遅延が経過すると）、VP