Googleは2026年10月2日、GKEの「CPU startup boost」を発表しました。アプリを動かすコンテナの初期化時だけ、CPUの処理能力の割り当てを一時的に増やす機能で、現在はプレビュー提供です。Googleは、アプリの初期化を最大2倍高速化し、起動時に備えたCPUの過剰確保を抑えるとしています。
起動時だけCPUを増やし、通常の水準に戻す
CPU startup boostは、起動時と通常の稼働時でCPUの割り当てを切り替える仕組みです。Googleによると、初期化中は割り当てを増やし、起動完了後は通常の水準に戻します。この変更のためにコンテナを再起動する必要はありません。
増強を解除するタイミングには、アプリが処理を受け付けられるかを確かめる「readinessProbe」を使います。この確認が成功した後、設定した待機時間を経て、増強を解除します。
Googleが示したCPU startup boostの流れ。起動時に増やし、準備完了後に戻す 出典: Google Cloud Blog (引用) 設定は、CPUやメモリの割り当てを調整するVertical Pod Autoscaler(VPA)に統合されています。Podというコンテナをまとめて扱う単位ごとに倍率を指定したり、コンテナ別に増強ルールを設定したりできます。内部では、Podを動かしたまま割り当てを変更するKubernetes In-place Pod Resizeを利用します。
最大2倍という効果はGoogleが示したものです。自社アプリでも同じ効果が出ると決めつけず、初期化時間の実測で判断することが大切です。
対象バージョンと設定条件
対象はGKE 1.36.0-gke.4447000以降です。GKE StandardとAutopilotの両方が対象で、対応するアプリの配置・管理方式にはDeploymentsとStatefulSetsが含まれます。
StandardではVPAを有効にする必要があります。AutopilotではVPAが標準で有効ですが、増強時にもCPUとメモリの比率が規定を満たさなければなりません。CPUの増強倍率だけでなく、メモリを含めた設定の確認が必要です。
具体的な設定は、VPAの構成を記述するVerticalPodAutoscalerマニフェストの「startupBoost」に書きます。Googleによると、「updateMode」を「Off」にすると、通常時のCPU要求量を固定できます。
また、Pod数を負荷に応じて増減させるHorizontal Pod Autoscaler(HPA)との併用時には、確実なreadinessProbeと、短い「durationSeconds」の設定が推奨されています。起動完了の判定と増強を続ける時間を、併せて見直す必要があります。
情シス・会社への影響
検討の出発点は、通常の稼働時ではなく、起動時のためにCPUを多く確保しているアプリがあるかどうかです。今回の機能は、初期化に必要な割り当てと、その後に必要な割り当てを分けて考えるための選択肢になります。
Googleは、起動時に備えた過剰確保を抑え、費用を最適化すると説明しています。ただし、具体的な削減額や自社での効果は、この発表の情報だけでは判断できません。導入を検討する場合は、起動時間とCPUの設定、費用を一緒に比較するのがよいでしょう。
提供段階はプレビューです。すべての本番環境へ一度に適用する前提ではなく、検証環境で起動完了の判定や増強解除後の動作を確かめる進め方が適切です。運用を委託している場合も、バージョンや設定条件を委託先と共有しておきましょう。
いま確かめること
GKEの管理画面で、対象クラスタのバージョンが1.36.0-gke.4447000以降か、StandardとAutopilotのどちらかを確認する。
VPAの有効化状況とマニフェストを確認し、startupBoostの倍率やコンテナ別ルール、通常時のCPU要求量を整理する。
readinessProbeが実際の起動完了を判定できるか確認する。HPAを併用している場合は、durationSecondsも見直す。
Autopilotでは、増強時のCPUとメモリの比率が規定を満たすか確認する。
プレビュー機能を使う社内ルール を確認し、検証環境で導入前後の初期化時間、割り当て、費用を比較する。
