起動時の過剰プロビジョニングはもう不要：GKEの新機能CPU startup boost

トレードオフ：起動速度か、アイドル時の無駄か

Kubernetes上でレイテンシに敏感な重いワークロードを運用するチームは、どちらも悩ましい2つの妥協のいずれかを選ばざるを得ません。

起動に合わせてサイジングし、その分を払い続ける。 初期化を素早く終えられるよう、CPUリクエストを高めに設定します。ウォームアップ後のアプリはわずかなCPUしか必要としないにもかかわらず、です。そのリクエストは24時間365日そこに居座り続けます。スケジューラがPodの配置に使うのも、クラスタオートスケーラーがノード追加の判断に使うのも、課金の対象になるのも、この値です。レプリカが数百規模になれば、起動の高速化と引き換えに続く無駄はあっという間に積み上がります。

定常状態に合わせてサイジングし、起動のたびに苦しむ。 リクエストを実際のランタイム使用量に合わせ、再起動・ローリングデプロイ・ノードアップグレードのたびにReadyまでの長い道のりを受け入れる、というやり方です。CPUスロットリングの影響で、本来5秒で終わるはずのJVMウォームアップが30秒以上に延びることもあります。その結果、ロールアウトは遅くなり、HPAイベント時のスケールアウトも遅れ、ユーザーにレイテンシスパイクが及ぶおそれもあります。

どちらも到底受け入れられるものではありません。CPU startup boostは、このギャップを埋めるために作られた機能です。

CPU startup boostが実際に解決すること

CPU startup boostは、GKEのVertical Pod Autoscaler（VPA）の新機能で、現在プレビュー版として提供されています。Podの初期化中にコンテナのCPUリクエストを一時的に引き上げ、その後コンテナを再起動することなく自動的にベースラインまで戻すことができます。

リソースを大量に消費するランタイム（Java、Node.js、重いインポートを伴うPython）は、必要なとき、つまり初期化中にだけ、必要なCPUの余裕を確保できます。ベースラインのリクエストは、Podの寿命の最初の数秒のために水増しした妥協の値ではなく、実際の定常状態の使用量を反映した値にできます。ブースト値からベースラインへの縮小には、Podの退避と再作成ではなくKubernetesのインプレースPodリサイズ（IPPR）が使われるため、コンテナはその間ずっと動き続けます。

この機能は、長期的なリソースサイジングを推奨・適用するというVPA本来の役割と併用できます。startup boostは実のところ、VPA（またはユーザー自身）がすでに確立したベースラインの上に重ねる、短命のオーバーライドにすぎません。

仕組みと設定方法

詳しい手順はこちら：Accelerate application startup with CPU startup boost。

CPU startup boostは、VerticalPodAutoscalerオブジェクトにstartupBoostブロックを追加することで定義します。Podレベルで適用してすべてのコンテナに同じブーストをかけることも、コンテナレベルで特定のコンテナだけを対象にしたり、Pod全体のブーストから特定のコンテナを除外したりすることもできます。

発動するのはPod作成時のみです。Pod自体は生きたまま後からコンテナが再起動した場合（たとえばOOMKill後など）には、ブーストは再適用されません。ブーストを注入するアドミッションWebhookは、Podの最初のアドミッション時にしか実行されないためです。

ブーストは倍率でも固定量でも指定できます。type: "Factor"はベースラインのCPUリクエストを倍率でスケールし（factor: 2なら2倍）、type: "Quantity"はベースラインに固定量のCPUを上乗せします。

この機能はVPAの更新モードを置き換えるのではなく、併用する形で動作します。ブーストの挙動だけが欲しければupdateMode: "Off"で運用し、継続的な使用状況に基づいてVPAにリソース調整も続けさせたければupdateMode: "InPlaceOrRecreate"と組み合わせてください。

Podレベルのブーストを設定するには、次のいずれかのオプションを使用します。

Podレベルのブースト（VPAの適用はオフ）

ブーストだけが欲しい場合はこちらを使います。VPAはそれ以外のリソース推奨を一切適用しません。

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Pod内のすべてのコンテナは、PodがReadyになってから最初の10秒間、ベースラインCPUリクエストの2倍を受け取り、その後GKEがインプレースで元のサイズに戻します。

Podレベルのブーストと継続的なVPA管理の併用

起動時のブーストに加えて、その後も継続的なインプレースのライトサイジングを行いたい場合はこちらです。

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

ブーストの挙動は同じですが、updateMode: "InPlaceOrRecreate"により、VPAはPodのライフタイム全体を通じてリソース変更の推奨と適用を続けます。その際、まずインプレースのリサイズを試み、できない場合に再作成へフォールバックします。

コンテナレベルのブースト：特定のコンテナだけを対象に

Deploymentにサイドカーやユーティリティコンテナがあり、起動時のCPUスパイクを必要としない場合に便利です。resourcePolicy.containerPoliciesを使って、ブーストを必要とするコンテナだけにスコープを絞ります。

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

この例では、boosted-container-nameは起動中、ベースラインのリクエストに加えて2 vCPUを追加で受け取ります。倍率ではなく固定量による指定です。

Podレベルのブーストから特定のコンテナを除外する

逆のケースです。Podレベルのブーストが設定されているものの、あるコンテナだけは他と一緒にブーストしたくない場合に使います。

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

Podレベルのブーストはデフォルトですべてのコンテナに2倍の係数を適用しますが、コンテナポリシーにより、指定したコンテナだけは係数1にオーバーライドされます。