Google Kubernetes Engine（GKE）には、ワークロードがスケールアップしたときに Pod の起動レイテンシを短縮するのに役立つ複数の戦略が用意されています。ノードのプロビジョニング、コンテナ イメージの pull 、アプリケーションの初期化の遅延を短縮することで、トラフィックの急増時のサービスの応答性を向上させ、インフラストラクチャのコストのバランスを取ることができます。
このドキュメントでは、Pod の起動ライフサイクル全体で GKE の起動レイテンシ短縮戦略を比較し、ワークロードの要件に合った単一の戦略または階層化された組み合わせを選択します。
Pod の起動ライフサイクルを理解する
GKE でワークロードがスケールアップし、既存のノードに新しい Pod を割り振るのに十分な容量がない場合、エンドツーエンドの起動レイテンシは次の 3 つの連続したステージに及びます。
- ノードのプロビジョニングと Pod のスケジューリングのステージでは、クラスタ オートスケーラーが新しい Compute Engine VM をプロビジョニングし、ノードを初期化してコントロール プレーンに登録します。これにより、Kubernetes スケジューラが保留中の Pod を配置できるようになります。
- コンテナ イメージの pull ステージでは、ノード上の
kubeletコンポーネントが、Pod に必要なコンテナ イメージをコンテナ レジストリからダウンロードして展開します。 - アプリケーションの初期化ステージでは、コンテナ ランタイムがアプリケーション プロセスを開始し、依存関係またはモデルの重みをメモリにロードして、Kubernetes の起動プローブと準備プローブを渡します。
GKE の機能は、このライフサイクルの特定のステージを対象としています。 ワークロードの起動時間に最も影響するステージを確認するには、 起動レイテンシ指標をモニタリングするをご覧ください。
起動レイテンシ短縮戦略を比較する
次の表に、Pod の起動ライフサイクル全体で GKE の起動レイテンシ短縮戦略を比較します。
| 戦略 | ライフサイクル ステージ | レイテンシの情報 | 費用と割り当てのプロファイル | クラスタモードとハードウェアのサポート | 最適な用途 |
|---|---|---|---|---|---|
| アクティブ容量バッファ（プレビュー版） | ノードのプロビジョニングと Pod のスケジューリング | ノードがすでに実行されているため、Pod をすぐにスケジュールできます。 |
実行中の VM の標準ノードベースのコンピューティング レート。 Compute Engine の vCPU、メモリ、ディスク、IP アドレスの割り当て と、Namespace の Kubernetes リソースの割り当てを消費します。 |
Standard クラスタと、 カスタム ComputeClass を使用する Autopilot クラスタ（ノードベースの課金）。 CPU、GPU、TPU をサポートしています。 |
トラフィックの急増を吸収し、レイテンシの影響を受けやすい GPU、 TPU、CPU ワークロードをスケーリングします。 |
| スタンバイ 容量バッファ（プレビュー版） | ノードのプロビジョニングと Pod のスケジューリング | 一時停止したノードを約 30 ～ 35 秒で再開します。これは、新しいノードをプロビジョニングするよりも高速です。 |
一時停止中は VM コンピューティングの料金は発生しません。ブートディスクと保存されたメモリ状態に対して Persistent Disk ストレージ料金が発生します。 一時停止中は、ディスクと IP アドレスの割り当てと、Namespace の Kubernetes リソースの割り当てを消費します。 |
Standard クラスタ（ノード自動プロビジョニングを使用）と Autopilot クラスタ（カスタム ComputeClass を使用）。 CPU のみをサポートします（GPU、TPU、ローカル SSD はサポートしていません）。 |
持続的なトラフィック の増加に対応するため、費用対効果の高いバースト容量を維持します。 |
| 高速起動ノード | ノードのプロビジョニングと Pod のスケジューリング | 事前初期化されたハードウェアを使用して、コールド ノードの起動時間をベスト エフォートで短縮します。 | 追加料金なしで提供されます。 |
Autopilot クラスタと、 Standard クラスタの Autopilot ワークロード。 ローカル SSD または Spot VM を使用しない、対象となる汎用マシンシリーズと GPU マシンシリーズをサポートしています。 |
構成やアイドル容量のコストなしで、ベースライン ノードのプロビジョニングを高速化します。 |
| 優先度の低いプレースホルダ Pod | ノードのプロビジョニングと Pod のスケジューリング | 優先度の低いプレースホルダ Pod を強制削除した後、Pod をすぐにスケジュールします。 |
実行中のノードの標準コンピューティング レート。 Deployment と PriorityClass の手動管理が必要です。 |
Standard クラスタと Autopilot クラスタ。 | Pod ベースの課金または 1.35 より前のバージョンを使用するクラスタで予備容量を予約します。 |
| イメージ ストリーミング | コンテナ イメージの pull | イメージ全体のダウンロードを待たずにコンテナを起動できます。 |
追加料金なしで提供されます。 Artifact Registry または対象となる Docker Hub リポジトリが必要です。 |
Autopilot（デフォルトで有効）クラスタと Standard クラスタ。 | 大規模なコンテナ イメージのイメージ pull 時間を短縮します。 |
| セカンダリ ブートディスク | コンテナ イメージの pull | ノードのプロビジョニングと並行して 、事前入力された Persistent Disk を新しいノードに接続します。 | 各ノードに接続された Persistent Disk とディスク イメージ ストレージに対して課金されます。 | Standard クラスタと Autopilot クラスタ。 | 大規模なコンテナ イメージや、機械 学習モデルの重みなどの静的データセットをプリロードします。 |
| Pod スナップショット | アプリケーションの初期化 | プロセス メモリとファイル システムの状態の保存されたチェックポイントから、新しい Pod レプリカを直接復元します。 | Cloud Storage のスナップショット ストレージに対して課金されます。 |
GKE Sandbox で Pod を実行する Standard クラスタと Autopilot クラスタ。 対象となる CPU マシンタイプと GPU マシンタイプをサポートしています（TPU はサポートしていません）。 |
AI 推論モデルと 起動ルーチンが重いアプリケーションの長い初期化を回避します。 |
| CPU 起動ブースト（プレビュー版） | アプリケーションの初期化 | Pod の起動時に CPU リクエストと上限を一時的に増やし、 その場でサイズを変更します。 | 起動ウィンドウ中、追加のノード CPU 容量を一時的に消費します。 | 垂直 Pod 自動スケーリングが有効になっている Standard クラスタと Autopilot クラスタ。 | Java、 Python、Node.js などのランタイムの CPU バインドの初期化を高速化します。 |
Pod の起動ステージごとに戦略を選択する
以降のセクションでは、Pod の起動ライフサイクルの各ステージで使用できるオプションについて説明します。
ノードのプロビジョニングと Pod のスケジューリングを高速化する
保留中の Pod が既存のノードに収まらない場合、新しいノードの起動を待つことがスケールアップ レイテンシの最大の要因となることがよくあります。この遅延は、次の戦略を使用して短縮または解消できます。
-
容量バッファを使用して、予備のノード容量を宣言的に予約します。
- アクティブ バッファ（
buffer.x-k8s.io/active-capacity戦略）を構成して、事前プロビジョニングされたノードを実行し、Pod をすぐにスケジュールできるようにします。アクティブ バッファは、CPU、GPU、TPU ワークロードをサポートしています。 - スタンバイ バッファ（
buffer.gke.io/standby-capacity戦略）を構成して、事前プロビジョニングされた CPU ノードを一時停止状態にします。ワークロードがスケールアップすると、GKE はスタンバイ ノードを約 30 ～ 35 秒で再開し、アイドル状態の VM を実行する際のコンピューティング コストを回避します。
- アクティブ バッファ（
- 対象となる Autopilot ワークロードと GPU マシンシリーズで、高速起動ノードを使用して、自動のベスト エフォート ハードウェア の事前初期化を行います。GKE は、対象となるワークロードの新しいノードをプロビジョニングするときに、高速起動ノードを自動的に使用します。これには、互換性のある Autopilot カスタム ComputeClass の容量バッファを補充するために作成されたノードが含まれます。
- ワークロードで Autopilot Pod ベースの課金モデルを使用している場合、または GKE バージョン 1.35 より前のバージョンで実行している場合は、Kubernetes PriorityClass を使用して優先度の低いプレースホルダ Pod をデプロイします。サポートされている GKE バージョンでノードベースの課金を使用するクラスタの場合は、プレースホルダ Deployment や Pod 強制削除ループの管理が不要なため、宣言型容量バッファを使用することをおすすめします。
コンテナ イメージの pull を高速化する
スケジューラが Pod をノードに配置した後、ノードはコンテナを起動する前にコンテナ イメージを pull する必要があります。イメージの pull レイテンシは、次の戦略を使用して短縮できます。
- イメージ ストリーミングを有効にすると、イメージの残りの部分がバックグラウンドでダウンロードされている間に、必要なファイルがネットワーク経由でストリーミングされるとすぐにコンテナを起動できます。Autopilot クラスタでは、Artifact Registry の対象となるイメージに対して、イメージ ストリーミングがデフォルトで有効になっています。
- セカンダリ ブートディスクを構成して、大規模なコンテナ ベースレイヤ または静的データセットをカスタム ディスク イメージにプリロードします。GKE は、ノードを作成するときに、ノードのプロビジョニングと並行して、ディスク イメージからインスタンス化された Persistent Disk を接続します。
- DaemonSet を実行して、スタンバイ バッファにコンテナ イメージをプリロードします。ノードの初期化ウィンドウ（
buffer.gke.io/standby-capacity-init-timeアノテーション）中。GKE がスタンバイ ノードを一時停止する前に、DaemonSet はワークロード イメージをノードのブートディスクに pull します。これにより、ノードが再開されるときにイメージがすでにキャッシュに保存されます。
アプリケーションの初期化を高速化する
ノードが実行され、コンテナ イメージが存在する場合でも、アプリケーションがフレームワークをロードしたり、ジャストインタイム（JIT）コードをコンパイルしたり、モデルの重みをメモリにロードしたりするのに時間がかかることがあります。初期化時間は、次の戦略を使用して短縮できます。
- Pod スナップショットを構成して、実行中の Pod の メモリとファイル システムの状態のチェックポイントを GKE Sandbox にキャプチャします。ワークロードが水平方向にスケーリングされると、GKE は Cloud Storage のスナップショットから新しいレプリカを復元します。これにより、Pod は新しい状態から初期化されるのではなく、スナップショットが取得された時点から実行を再開します。
- VerticalPodAutoscaler で CPU 起動ブーストを構成して、アドミッションと初期化中に Pod に
追加の CPU を割り当てます。Pod が
Readyステータスに達し、構成されたブースト期間が終了すると、GKE はコンテナを再起動せずに、Pod の CPU リクエストをベースライン レベルにスケールダウンします。
エンドツーエンドの最適化のために戦略を組み合わせる
これらの戦略は Pod の起動ライフサイクルの異なるステージで動作するため、階層化してエンドツーエンドのスケールアップ時間を最適化できます。
- 小さいアクティブ容量バッファと大きいスタンバイ容量バッファを組み合わせます。トラフィックが急増すると、アクティブ バッファは Pod の最初のバーストをすぐに吸収します。一方、GKE はスタンバイ バッファからノードを約 30 ～ 35 秒で再開し、アクティブ バッファを補充して持続的な増加に対応します。バックグラウンドで、クラスタ オートスケーラーは新しいノードをプロビジョニングして一時停止し、スタンバイ バッファを補充します。
- スタンバイ容量バッファの場合は、ノードが一時停止する前にイメージ ストリーミングを有効にするか、 DaemonSet を使用してコンテナ イメージをプリロードします 。これにより、ノードが再開されたときに大規模なコンテナ イメージをダウンロードする時間がかかりません 。
- GKE が事前プロビジョニングまたは事前初期化されたノードに Pod をスケジュールした後、Pod が起動中に CPU スロットリングを回避するか、保存されたスナップショットから直接復元するように、容量バッファまたは高速起動ノードの上に CPU 起動ブーストまたは Pod スナップショットをレイヤリングします。
単一または複数の戦略がワークロードに与える影響を測定するには、Cloud Monitoring の [Pod の起動レイテンシ分布] グラフと [Pod の最初の準備完了までのレイテンシ] グラフを表示し、Cloud Logging でスケジューリング レイテンシ ログを調べます。手順については、起動レイテンシ指標をモニタリングするをご覧ください。