CPU 起動ブーストでアプリケーションの起動を高速化する

このドキュメントでは、Google Kubernetes Engine（GKE）で垂直 Pod 自動スケーラー（VPA）を使用して CPU 起動ブーストを使用し、Pod の初期化フェーズ中に Pod に割り当てられる CPU リソースを一時的に増やす方法について説明します。

CPU 起動ブーストは、初期化中に CPU リクエストを一時的に増やし、その場でベースライン レベルに戻すことで、アプリケーションの起動を高速化し、費用対効果を高めます。このドキュメントでは、起動ブーストの要件、構成（Pod レベルとコンテナレベル）、検証、ベスト プラクティスについて説明します。

このドキュメントは、GKE でアプリケーションの起動パフォーマンスを最適化する DevOps、プラットフォーム エンジニア、アプリケーション デベロッパーを対象としています。

利点

CPU 起動ブーストを使用すると、次のメリットがあります。

• 起動の高速化: Java、Node.js、Python で記述されたアプリケーションなど、リソースを大量に消費するアプリケーションの初期化を高速化します。
• 費用効率: 起動時の需要を満たしながら、定常状態のオペレーションで CPU の過剰なプロビジョニングを回避します。定常状態のオペレーションとは、アプリの初期化が完了し、リソース使用量が安定した後の期間です。
• 中断なし: コンテナを再起動せずに、Kubernetes のインプレース Pod サイズ変更（IPPR）を使用して、リソースをベースライン レベルにスケールバックします。
• 手作業の削減: リソースの無駄を最小限に抑え、ワークロードのサイズ調整に必要な手作業を削減します。

要件

CPU スタートアップ ブーストを使用するには、次の要件を満たす必要があります。

• GKE バージョン: Standard クラスタと Autopilot クラスタの両方で 1.36.0-gke.4447000 以降を使用します。
• VPA が有効: Standard クラスタで垂直 Pod 自動スケーリングを有効にします。GKE は、Autopilot クラスタで VPA をデフォルトで有効にします。特定の更新モードを選択することで、CPU 起動ブーストに VPA を排他的に使用できます。VPA を有効にして構成するには、Pod のリソース リクエストを自動的に設定するをご覧ください。
• ワークロード タイプ: Deployment や StatefulSet などのコントローラを使用して、ワークロードを管理します。
• ノード容量: Standard クラスタにブーストされた Pod に十分な容量があることを確認します。容量が不足している場合、GKE はノードに合わせてブーストされた Pod リクエストを上限設定します。

CPU 起動ブーストの仕組み

ブーストのライフサイクルと CPU 起動ブーストによるリソース増加の計算方法については、CPU 起動ブーストの仕組みをご覧ください。

始める前に

始める前に、ブーストするクラスタを含む Cloud de Confiance by S3NS プロジェクトが選択されていることと、次のタスクが完了していることを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API を有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。gcloud CLI をインストール済みの場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。

• 選択したプロジェクトを使用するように gcloud CLI を構成します。

  gcloud config set project PROJECT_ID
  

  PROJECT_ID は、プロジェクトの ID に置き換えます。

• 既存の GKE クラスタがあることを確認します。ない場合は、クラスタを作成するをご覧ください。

必要なロール

CPU スタートアップ ブーストを有効にして使用するために必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

• Kubernetes Engine 管理者（roles/container.admin）
• Kubernetes Engine デベロッパー （roles/container.developer）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

CPU 起動ブーストを有効にする

CPU 起動ブーストを有効にするには、VerticalPodAutoscaler（VPA）マニフェストに startupBoost 構成ブロックを追加します。ブーストは、Pod 内のすべてのコンテナに適用するように構成することも、特定のリソースの増加で個々のコンテナをターゲットにすることもできます。

Pod レベルのブーストを構成する

Pod レベルのブーストでは、ワークロード内のすべてのコンテナに同じ CPU リソースの増加が適用されます。VPA の継続的なリソース管理の有無にかかわらず、CPU 起動ブーストを構成できます。

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

オプション A: 起動ブーストが有効で、VPA 更新モードが無効

このオプションを使用すると、通常の VPA の推奨事項を適用せずに、CPU の起動ブースト機能のみに VPA を活用できます。次の例では、CPU 乗数を 2 に適用し、Pod が Ready ステータスに達してから 10 秒間維持します。

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

オプション B: スタートアップ ブーストと VPA 更新モードの両方が有効になっている

GKE で起動ブーストを管理し、継続的な使用状況に基づいて Pod のリソース リクエストを自動的に調整する場合は、このオプションを使用します。次の例では、起動ブーストを適用し、updateMode フィールドを InPlaceOrRecreate に設定します。

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

コンテナレベルのブーストを構成する

ワークロードに、追加のリソースを必要としないサイドカーやその他のコンテナが含まれている場合は、resourcePolicy セクション内で特定のコンテナを起動ブーストの対象にできます。containerName の値は、Deployment 仕様のコンテナの name フィールドと一致する必要があります。

コンテナレベルのブーストを構成するには、次のいずれかのオプションを使用します。

オプション A: 特定のコンテナをブーストする（VPA の動作が無効）

このオプションを使用すると、Pod の残りのリソース リクエストを変更せずに、単一のコンテナにブーストを適用できます。次のマニフェストの例では、boosted-container-name という名前のコンテナのベースライン リクエストに 2 つの vCPU を追加します。

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"

オプション B: Pod レベルのブーストから特定のコンテナをオプトアウトする

Pod レベルのブーストが構成されているが、特定のコンテナを除外する場合は、このオプションを使用します。次のマニフェストの例では、Pod 全体に CPU 乗数を 2 に適用しますが、disable-cpu-boost-for-this-container という名前のコンテナの乗数を 1 に設定してブーストを無効にします。

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

CPU 起動ブーストを検証する

Pod がブーストを受け取っていることを確認するには、VPA 構成、Pod リソース リクエスト、Pod アノテーション、VPA イベントを確認します。

VPA 構成を確認する

VerticalPodAutoscaler オブジェクトの詳細を確認するには、次のコマンドを実行します。

kubectl describe vpa VPA_NAME

VPA_NAME は、VPA オブジェクトの名前に置き換えます。

Pod のブーストされた CPU リクエストを確認する

Pod の現在のリソース リクエストを確認するには、次のコマンドを実行します。

kubectl describe pod POD_NAME

POD_NAME は、Pod の名前に置き換えます。

Pod アノテーションを使用して CPU ブーストを確認する

VPA アドミッション Webhook は、ブーストの有効期限が切れたときに各コンテナが戻るべき元のリソースを追跡するために、コンテナ スコープのアノテーションを挿入します。これらのアノテーションを確認するには、次のコマンドを実行します。

kubectl get pod POD_NAME --output yaml

metadata.annotations セクションで、vpaCpuStartupBoost/CONTAINER_NAME 形式のアノテーションを探します。次に例を示します。

metadata:
  annotations:
    vpaCpuStartupBoost/slow-starter: '{"requests":{"cpu":"50m","memory":"64Mi"},"limits":{"cpu":"200m","memory":"128Mi"}}'

コマンドの出力には、次のいずれかの検証結果が表示されます。

• ブーストの成功: Pod に vpaCpuStartupBoost/CONTAINER_NAME アノテーションが存在します。
• ブーストが失敗した: アノテーションが完全に欠落しています。これは、アドミッション コントローラがブーストを無視したことを意味します。これは、ノード容量の上限または Autopilot のリソース制限が原因である可能性があります。

スケールダウン イベントを確認する

GKE が CPU リソースの割り当てをベースラインに正常に減らしたことを確認するには、次のコマンドを実行してクラスタ イベントを確認します。

kubectl get events --field-selector reason=InPlaceResizedByVPA

コマンドの出力には、次のいずれかの検証結果が表示されます。

• ブースト解除に成功: VPA アップデータによって Pod のサイズがインプレースで変更されたことを示すメッセージを含む InPlaceResizedByVPA イベントが表示されます。これにより、コンテナを再起動せずに CPU リクエストがベースライン値に戻ったことが確認されます。
• ブーストの解除に失敗した: ブーストの有効期限が切れてからかなり経っても、vpaCpuStartupBoost/CONTAINER_NAME アノテーションが Pod に残り、InPlaceResizedByVPA イベントが発生しない。

ベスト プラクティスと制限事項

CPU 起動ブーストを使用する場合は、次の点を確認してください。

水平 Pod 自動スケーリングとの相互作用

CPU スタートアップ ブーストで水平 Pod オートスケーラー（HPA）を使用する場合は、次のガイドラインに従ってください。

• ヘルスプローブを定義する: ワークロードの readinessProbe を定義する必要があります。
• 期間の遅延を構成する: durationSeconds パラメータを 0 に設定する必要があります。この構成により、起動時の CPU 使用率が高いために HPA がアプリケーションを早期にスケールアウトすることを防ぐことができます。

クラスタ オートスケーラーとエビクション ループ

GKE Standard クラスタでクラスタ オートスケーラーを使用する場合は、次のノードの動作を考慮してください。

• 潜在的な削除ループ: 一時的な CPU ブーストにより、ノードのスケールアップがトリガーされる可能性があります。Pod の準備が完了してスケールダウンすると、使用率の低下によってノードのスケールダウンがトリガーされ、Pod が強制排除されて、無限ループが発生する可能性があります。
• 軽減策: GKE Autopilot を使用して、ノードのデフラグと削除ループの問題を軽減することを強くおすすめします。

コンテナの再起動回数

次の動作を確認して、コンテナの再起動が CPU の起動ブーストに与える影響を理解します。

• Pod の作成時のみ: CPU 起動ブーストは、Pod の初期作成段階でのみ適用されます。
• 再起動時のブーストなし: コンテナが再起動しても（OOMKill イベントなど）、Pod がアクティブな状態を維持している場合、GKE はブーストを再度適用しません。この動作は、Pod アドミッション Webhook が最初の Pod 作成プロセスでのみトリガーされるために発生します。

クリーンアップ

既存のワークロードで CPU スタートアップ ブーストを構成するため、ワークロードの中断を回避するために次の点に注意してください。

• Kubernetes リソースを削除する必要はありません。
• VerticalPodAutoscaler オブジェクトまたはワークロード コントローラ（Deployment や StatefulSet など）が定常状態のオペレーションにまだ必要な場合は、削除しないでください。

• CPU 起動ブーストが必要ない場合は、スコープに応じて次のいずれかの方法でブーストのみを無効にできます。

  • ワークロード全体のブーストを無効にする: VerticalPodAutoscaler オブジェクト仕様から startupBoost ブロックを削除し、更新されたマニフェストをクラスタに適用します。

  • 特定のコンテナのブーストを無効にする: Pod レベルのブーストから特定のコンテナを除外するには、containerPolicies セクションにコンテナ ポリシーを追加し、CPU 乗数を 1 に設定します。

      startupBoost:
        cpu:
          type: "Factor"
          factor: 1
    

    詳細については、コンテナレベルのブーストを構成するをご覧ください。

次のステップ

• コンテナ リソースのリクエストと上限のスケール
• 水平 Pod 自動スケーリングの構成
• ワークロードのサイズ適正化を大規模に行う