起動時と定常時のCPU需要

Google Cloudは、2026年10月16日付の日本語ブログでCPU起動ブーストを紹介しています [2]。CPU起動ブーストは起動時にCPU requestsを一時的に増やす機能です。CPU requestsはPodの配置に使うCPU要求量です。

アプリケーションは初期化処理やライブラリの読み込みで、定常運用より多くのCPU（中央処理装置）を必要とすることがあります。Google Cloudは起動時の遅延に備えて定常時のCPU requests（要求量）まで大きくすると、起動後に使わないリソースを確保し続ける課題を挙げています（Google Cloudの公式ブログ）。

Google Cloudは起動時と定常時のCPU需要に差が出やすい例として、Java仮想マシン（JVM）を使うアプリケーションとNode.jsサーバを挙げています。PythonやAI・ML（人工知能／機械学習）のマイクロサービス（小さな機能単位で構成するサービス）も例に含めています [1]。

2026年10月16日時点の公式ガイドでは、本機能はPreview（一般提供前）です。サポートが限定される可能性があります [3]。

VPAによる起動時の増量と縮小

Kubernetesはコンテナ化されたアプリケーションを管理する基盤です。Pod（1つ以上のコンテナをまとめる実行単位）にrequests（配置先決定に使うリソース要求量）とlimits（リソースの利用上限）を設定します。

requestsは、スケジューラーが配置先のノード（Podを実行するクラスタ内のマシン）を決める際に使う値です [4]。ノードに余裕があれば、コンテナはrequestsを超えてCPUを利用できます [4]。limitsは、カーネルがCPU利用を抑える処理（CPUスロットリング）で適用する上限です [5]。

リソースの自動調整機能であるVPA（Vertical Pod Autoscaler）は稼働実績に基づいてPodのrequestsやlimitsを垂直方向に調整します [6]。HPA（Horizontal Pod Autoscaler）は、CPU使用率などに応じてPod数を増減させます [6]。DeploymentはPodを管理するコントローラです。HPAはDeploymentのPod数を水平方向に調整します。CPU起動ブーストはVPAの仕組みを活用し、Podの初期化時だけrequestsを一時的に増やす機能です [7]。

Pod作成時、VPAのAdmission Webhookが作成要求を受け取ります。Admission Webhookは、Pod作成要求の設定を変更する仕組みです。VPAはブースト用のCPU requestsを適用します。追跡用アノテーション（Podに付けるメタデータ）もPodに付与します [8]。Podが準備完了（Ready状態）になった後、設定された待機時間（durationSeconds）の経過を待ちます。待機時間の経過後、VPAはコンテナを再起動せず、稼働中のままrequestsを定常時のベースラインまで縮小します [8, 9]。

Pod作成からブースト解除までの処理順を示します [8, 9]。

ブースト解除は、VPA Updaterが1分周期で状態を確認して実行します [9]。そのため、設定したdurationSecondsが経過した直後ではなく、ブースト状態が最大で約1分長く続く場合があります [9]。

ブースト値はFactor（乗算）なら基準のCPU requestsに倍率を掛け、Quantity（固定加算）なら固定量を加えて計算します [10]。updateModeがOffの場合、基準はPodマニフェストのrequestsです。Auto・Recreate・InPlaceOrRecreateではVPAの推奨値を使い、推奨値がない場合はPod仕様の値を使います（CPU起動ブーストの公式仕様）。

Offでは起動ブーストと起動後の縮小を行い、定常時のCPU requestsをマニフェストの値に固定します [11]。

GKEではcontrolledValuesの既定値がRequestsAndLimitsです。この設定では、CPU requestsとlimitsの双方が元の比率を保ったまま引き上げられます。RequestsOnlyを指定するとCPU requestsだけが引き上げられ、設定済みCPU limitsの直下までに制限されます [12]。

対象ワークロードとクラスタの条件

Google Kubernetes Engine（GKE）は、Google CloudのマネージドKubernetesサービスです。Standardでは利用者がノードを管理し、AutopilotではGKEが管理します。本機能には、両方式ともGKE 1.36.0-gke.4447000以降が必要です [13]。公式ドキュメントではPreviewとして提供されています [13]。StandardクラスタではVPAアドオンを有効にする必要があります。AutopilotクラスタではVPAが既定で有効です [14]。また、対象ワークロードはDeploymentやStatefulSet（状態を保つPodを管理するコントローラ）など、Kubernetes標準のコントローラで管理されている必要があります [14]。

クラスタの運用環境によって、リソース管理上の制約が異なります。Standardクラスタでは、ブースト後のPod requestsを収容できるノード容量が必要です [15]。容量が不足する場合、GKEはブースト後の要求値をノードに収まる範囲まで抑制します [15]。

Autopilotではコンピュートクラス（CPUやメモリの構成を定める区分）ごとにCPUとメモリの比率条件があります。ブースト後のCPU要求量は、割り当てられたメモリ量に応じて上限が決まります。条件によってはブースト自体が適用されません。コンピュートクラスのScale-Outではメモリを増やさずCPUだけを増やそうとすると、ブーストが無視される場合があります [16]。

Javaは公式ブログの利用例に含まれます [1]。一方、VPAの一般的な公式ガイドは、JVMの実際のメモリ使用量の把握が限られるため、JVMベースのワークロードはVPAの利用準備が整っていないと説明しています。起動ブーストの利用と、定常時のCPU・メモリをVPAで継続調整する運用は分けて評価することが妥当です（VPAの制約）。

設定例と運用上の制約

定常時のCPU requestsを変えずに評価する場合は、updateModeをOffにします [11]。以下はPod全体のCPU要求量にFactor 2を適用する未実行の設定例です。sample-appは対象Deploymentの名前に置き換えます。設定構造は公式ガイドのPod単位の例に合わせ、待機時間は後述するHPA併用条件の0秒にしています。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: sample-app-startup-boost
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: sample-app
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 0

既存のVPAはkubectl get vpa --all-namespacesで確認します。同じワークロード（spec.targetRef）に複数のVPAを重複して設定してはいけません（公式のVPAトラブルシューティング）。

CPU使用率に基づくHPAと併用する場合は、readinessProbeを定義します。readinessProbeは、Podがトラフィックを受け入れられるかを確認するプローブです。併せてdurationSeconds: 0を指定します [17]。公式ブログには0〜10秒の例もありますが、本稿の設定例は現行ガイドの0秒を採用しています [18]。

StandardクラスタでCluster Autoscaler（ノード数の自動調整）を有効にしている場合、起動時の一時的なCPU requests増大がノードのスケールアップを誘発することがあります [19]。その後、PodがReadyになってrequestsが縮小すると、ノードの利用率低下を検知してスケールダウンとPodの退避（eviction）が起きる場合があります。退避されたPodの再起動によって再びスケールアップが起き、退避ループに陥る可能性があります [19]。

GKEはこの問題の緩和策として、Autopilotの利用を強く推奨しています [19]。

CPU起動ブーストの適用対象はPodの初回作成時であり、同じPod内でのコンテナ再起動には再適用されません [20]。

項目GKE StandardGKE Autopilot
VPAの前提 [14]有効化が必要既定で有効
ブーストが抑えられる主な条件 [15, 16]ノード容量が不足すると要求量を制限CPU・メモリ比などの条件で抑制・無効化
ノード増減ループ [19]スケールアップ後の縮小とPod退避が循環する可能性GKEが緩和策として利用を推奨
CPUベースHPAとの併用 [17]readinessProbe、durationSeconds: 0readinessProbe、durationSeconds: 0

効果と費用の確認

以下は導入時の評価案です。本稿では設定例を実行しておらず、起動時間や料金も測定していません。小規模な評価用Deploymentで、ブースト有無を比較する際のコンテナイメージ、定常requests、ノード条件をそろえる案です。

Pod作成からReady、初回成功応答までの時間と、プローブ失敗数・再起動数を併記します。配置待ちや外部通信の時間も分けて記録し、CPU初期化の短縮と全体の起動時間を区別して検討する案です。

適用の確認ではPod作成直後にkubectl describe pod POD_NAMEでCPU requestsを確認します。次にkubectl get pod POD_NAME -o yamlでPodの定義を取得します。metadata.annotationsにあるvpaCpuStartupBoost/<CONTAINER_NAME>には元の値が記録されるため、現在のCPU requestsと照合します [21]。適用の記録と、起動時間が改善したかどうかは別に確認する項目です。

Ready到達後はreason=InPlaceResizedByVPAのイベントと現在のCPU requestsを照合し、基準値へ戻ったか確認します [22]。VPA Updaterは1分周期のため、待機時間の経過直後にイベントがなくても、最大約1分の遅れを見込んで再確認します [23]。縮小前後のrestartCount（再起動回数）と、Standardでノードの増減やPod退避が反復していないかも確認する項目です [20]。

料金ページでは、通常のStandardノードはVM（仮想マシン）の稼働に課金され、一般的なAutopilotワークロードはPodのrequestsに基づく課金です。特定ハードウェアを選ぶAutopilotワークロードには、ノード単位の課金が適用されます（GKEの料金）。

費用の評価案では同等の負荷期間の請求額を比較します。Pod課金なら起動中の要求量増加と定常時の低下を合わせて確認し、ノード課金ならノード数や稼働時間まで確認する必要があります。requestsの縮小と請求額の削減は分けて評価します。

課金方式主な確認対象費用が減ったかを確かめる観点
一般的なAutopilotのPod課金Podのrequestsと実際の請求額起動中の増加を含む期間全体で比較
通常のStandardノードのVM課金ノード数・稼働時間とVM請求額要求量の削減がノードの利用量に反映されたか
特定ハードウェアを選ぶAutopilotのノード課金ノード全体の利用と請求額Podのrequestsだけで見積もらず、ノード単位で確認