容量バッファを使用すると、クラスタ内のアクティブまたはスタンバイの容量バッファの階層を事前に宣言できるため、Google Kubernetes Engine（GKE）ワークロードの Pod の起動レイテンシを短縮できます。予備容量を事前に宣言することで、費用対効果の高い方法でワークロードを迅速に起動できます。
このドキュメントでは、容量バッファの仕組みについて説明します。容量バッファを有効にして使用する方法については、容量バッファを構成するをご覧ください。
容量バッファを使用する場合
起動レイテンシの影響を受けやすく、迅速なスケーリングが必要なアプリケーションには、容量バッファを使用します。トラフィックが急増した場合、アクティブ バッファは、低レイテンシのスケーリング用に事前にプロビジョニングされた容量を提供します。トラフィックが継続的に増加する場合は、スタンバイ バッファを使用すると、事前プロビジョニングよりも低コストで Pod をスケジューリングできます。
容量バッファには次の利点があります。
- スケーリング レイテンシを最小限に抑える: アクティブ バッファは実行中のノードを提供するため、 レイテンシを最小限に抑えることができます。スタンバイ バッファは迅速に再開されるため、アクティブ バッファよりも低コストで、新しいノードよりも迅速に容量を利用できます。
- 費用対効果の高いオーバー プロビジョニング: 容量バッファは セーフティ ネットの維持に役立ちます。大規模なワークロードの場合、このアプローチは、クラスタの成長に伴ってアイドル状態の容量が直線的に増加する可能性がある他のオーバー プロビジョニング方法（HorizontalPodAutoscaler（HPA）の使用率ターゲットを下げるなど）よりも 費用対効果が高くなります。
- ワークロードの要件を満たす: 容量バッファの構成を完全に制御できます。カスタム DaemonSet を組み込んでイメージをプリロードしたり、起動時間を調整したり、ニーズに合わせてバッファサイズを制御したりできます。
容量バッファは、AI エージェント、AI 推論、セールイベント中の小売アプリケーション、プレーヤー アクティビティのピーク時のゲームサーバーなど、迅速なスケールアップが必要なレイテンシの影響を受けやすいワークロードにおすすめします。
容量バッファの仕組み
容量バッファを実装するには、Kubernetes CapacityBuffer カスタム リソースを使用して、予備容量のバッファを定義します。GKE クラスタ オートスケーラーは CapacityBuffer リソースをモニタリングし、保留中の需要として処理して、予備容量が使用可能であることを確認します。バッファで定義されたリソース リクエストを満たすのに十分な容量がクラスタにない場合、クラスタ オートスケーラーは追加のノードをプロビジョニングします。
優先度の高いワークロードがスケールアップすると、GKE はバッファ内の使用可能な容量にワークロードをすぐにスケジューリングします。この即時スケジューリングは、バッファに予約されているレプリカ数またはリソース量に適用され、ノードのプロビジョニングに伴う一般的な遅延を回避できます。ワークロードがバッファユニットを使用すると、クラスタ オートスケーラーはバッファを補充するために新しいノードをプロビジョニングします。
容量バッファの戦略
レイテンシと費用に関する要件に基づいて、さまざまなプロビジョニング戦略を使用して容量バッファを構成できます。
アクティブ バッファ
アクティブ バッファ は、予約容量内に収まるワークロードの低レイテンシ スケーリング用の実行中のノードを提供します。ノードはすでに実行されているため、スケールアップ イベント中に Pod を要求する際のレイテンシを最小限に抑えることができます。
スタンバイ バッファ
スタンバイ バッファ は、一時停止されたノードを提供します。スタンバイ戦略はアクティブ戦略よりも費用対効果が高くなりますが、ワークロードを受け入れる前にノードを再開する際に短い遅延が発生します。
費用と料金
容量バッファの課金は、バッファの種類によって異なります。
- アクティブ バッファ: GKE がアクティブ バッファ容量として維持する実行中の VM に対して、標準の GKE コンピューティング 料金が課金されます。Autopilot では、実行中の Pod に標準の Pod ベースの課金レートが適用されます。
- スタンバイ バッファ: VM インスタンスが一時停止されている間は、コンピューティング 費用（CPU またはメモリ）は発生しません。少額のストレージ費用（VM ブートディスクなど）と、静的外部 IP アドレスなどの関連リソースの費用が発生します。GKE がワークロードをホストするためにスタンバイ VM を再開すると、標準のコンピューティングまたは Pod ベースの課金レートが適用されます。
CapacityBuffer CRD
容量バッファを構成するには、CapacityBuffer CustomResourceDefinition（CRD）を作成します。容量バッファは、さまざまな条件を満たすように構成できます。
- 固定レプリカ: 参照される Pod テンプレートのリソース リクエストに基づいて作成するバッファ Pod の固定数を指定します。この構成は、既知のサイズのバッファを作成する最も簡単な方法です。
- リソース上限: バッファが予約する CPU とメモリの合計量を指定します。コントローラは、参照される Pod テンプレートのリソース リクエストに基づいて、作成するバッファ Pod の数を計算します。
- 割合ベース: スケール サブリソース（Deployment、 StatefulSet、ReplicaSet、Job など）を定義する既存の スケーラブル オブジェクトの割合としてバッファサイズを定義します。参照ワークロードのスケーリングに応じて、バッファサイズが動的に調整されます。割合ベースの容量バッファは、Kubernetes スケール サブリソースを実装するオブジェクトでのみ サポートされます。
詳細については、CapacityBuffer CRD リファレンス ドキュメントをご覧ください。
ベスト プラクティス
容量バッファを構成する際に費用対効果と応答性を最適化するには、次の推奨事項を使用します。
- 費用対効果の高いスタンバイ優先戦略を使用する: ワークロードが 約 30 秒の短いスケールアップ遅延を許容できる場合は、スタンバイ バッファを優先します。この戦略では、アクティブ VM の費用を全額負担することなく、新しい VM のコールドノードの起動を回避できます。
- レイテンシの影響を受けやすいワークロードにはアクティブ バッファを使用する: Pod のスケジューリング時間を可能な限り短くする必要がある場合に、ノードの再開時間を許容できないワークロードにはアクティブ バッファを使用します。
- ハイブリッド戦略を使用してパフォーマンスと費用のバランスを取る: 費用対効果の高い設定にするには、小さなアクティブ バッファと大きなスタンバイ バッファを組み合わせます。 GKE は、スタンバイ バッファからノードを再開して（約 30 秒）、アクティブ バッファを補充することを優先します。その間、新しいノードがバックグラウンドでプロビジョニングされ、スタンバイ バッファが補充されます。この設定では、アクティブ容量で最初のスパイクを吸収し、低コストのスタンバイ容量を使用して持続的な成長に対応します。
- 最初のバースト用にアクティブ バッファのサイズを設定する: スタンバイ バッファノードが再開される前に発生すると予想される最初のレプリカの急増をカバーするように、アクティブ バッファのサイズを定義します。
- 持続的な負荷に対応するようにスタンバイ バッファのサイズを設定する: 発生すると予想される拡張負荷をカバーするのに 十分なスタンバイ バッファを定義します。これにより、 バッファはコールド スタートからバックグラウンドで補充できます。十分なサイズのスタンバイ バッファを使用すると、Pod の最大スケジューリング レイテンシをノードの再開時間（約 30 秒）まで短縮できます。容量バッファの使用が開始され、補充されると、新しいバッファノードは一時停止する前にアクティブ状態に移行します。この戦略は、負荷が長時間続く場合にアクティブ容量を増やすのに役立ちます。
- バッファ シミュレータを使用する: さまざまなアクティブ バッファサイズとスタンバイ バッファサイズを試して、特定のワークロードに最適な結果を得ます。https://github.com/gke-labs/buffers-simulator でオープンソースの GKE バッファ シミュレータを使用して、ワークロードのスケーリング動作のシミュレーションを実行し、バッファサイズのルールを微調整して、パフォーマンス目標を達成します。
要件と制限事項
容量バッファには、次の要件と制限事項があります。
- 容量バッファは、アクティブ バッファの場合はバージョン 1.35.2-gke.1842000 以降、スタンバイ バッファの場合はバージョン 1.36.0-gke.2253000 以降を実行している GKE クラスタで使用できます。
- 容量バッファは、Standard ノードプールと 特定のハードウェアを選択する Autopilot ノードプールで ノードベースの課金モデルを使用するワークロードのみをサポートします。容量バッファは、 Pod ベースの課金モデルを使用するワークロードをサポートしていません。
- Standard クラスタでは、 ノード自動プロビジョニングを有効にすることをおすすめします。ノード自動プロビジョニングにより、クラスタ オートスケーラーは CapacityBuffer のリソース リクエストに基づいて新しいノードプールを作成できます。ノード自動プロビジョニングを有効にしない場合、クラスタ オートスケーラーは既存のノードプールのみをスケールアップします。
- アクティブ容量バッファとスタンバイ容量バッファの両方が Compute Engine の割り当てにカウントされます。
スタンバイ バッファには、次の追加の制限があります。
- ノード自動プロビジョニングが有効になっている Standard クラスタでのみサポートされます。
- GPU または TPU が接続されたノードはサポートされていません。
- ローカル SSD は対象外です。
- 顧客管理の暗号鍵（CMEK）はサポートされていません。
- Confidential Google Kubernetes Engine ノードはサポートされていません。
- Compute Engine の一時停止と再開のオペレーションに関連する制限事項を理解しておく必要があります。
主な制限事項は次のとおりです。
- 顧客指定の暗号鍵（CSEK）で保護されたディスクを持つノードはサポートされていません。
- 208 GB を超えるメモリを持つノードは対象外です。
- ベアメタル インスタンスはサポートされていません。
- ノード OS は ACPI S3 スリープ信号をサポートしている必要があります。
- 一時停止プロセスの長さはメモリサイズに比例します。
- 再開は、再開に必要な基盤となるリソースの取得可能性によって異なります。
次のステップ
- 容量バッファを実装する方法については、容量バッファを構成するをご覧ください。