GKE クラスタの自動スケーリングについて


このページでは、Google Kubernetes Engine(GKE)がワークロードの需要に基づいて Standard クラスタのノードプールのサイズを自動的に変更する方法について説明します。需要が高い場合、クラスタのオートスケーラーはノードプールにノードを追加します。クラスタ オートスケーラーの構成方法については、クラスタの自動スケーリングをご覧ください。

このページは、容量とインフラストラクチャのニーズを計画し、システム アーキテクチャとリソースを最適化して、会社またはビジネス ユニットの総所有コストを最小限に抑える管理者、アーキテクト、オペレーターを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

Autopilot クラスタを使用すると、ノードプールがノード自動プロビジョニングによって自動的にプロビジョニングされ、またワークロードの要件に合わせて自動的にスケーリングされるため、ノードのプロビジョニングやノードプールの管理について心配する必要はありません。

このページを読む前に、基本的な Kubernetes のコンセプトと、リソース リクエストと上限の仕組みを理解しておいてください。

ベスト プラクティス:

組織の管理者、アーキテクト、デベロッパー、またはアプリケーションの実装とメンテナンスを担当する他のチームと協力して、クラスタ構成を計画し、設計します。

クラスタ オートスケーラーを使用する理由

GKE クラスタ オートスケーラーは、ワークロードの需要に基づいて、特定のノードプール内のノード数を自動的に変更します。需要が少ない場合、クラスタのオートスケーラーは指定した最小サイズにスケールダウンします。これにより、ワークロードの可用性が向上し、コストも抑えられます。ノードを手動で追加または削除する必要はありません。また、ノードプールを過剰にプロビジョニングする必要もありません。ノードプールの最小サイズと最大サイズを指定するだけで、あとは自動的に設定されます。

クラスタの自動スケーリング時にリソースを削除または移動すると、ワークロードが一時的に中断することがあります。たとえば、ワークロードが 1 つのレプリカを持つコントローラで構成されている場合、現在のノードを削除すると、レプリカのポッドは別のノードに再スケジュールされる可能性があります。クラスタ オートスケーラーを有効にする前に、一時的な中断が許容されるようにワークロードを設計するか、重要な Pod で割り込みが発生しないように設計してください。

ベスト プラクティス:

中断に対するワークロードの許容度を高めるには、Deployment などの複数のレプリカを持つコントローラを使用して、ワークロードをデプロイします。

クラスタ オートスケーラーのパフォーマンスを向上させるには、イメージ ストリーミングを使用します。これにより、対象となるコンテナ イメージから必要なイメージデータがリモートでストリーミングされると同時に、イメージがローカルのキャッシュに保存され、新しいノードのワークロードが迅速に開始できるようにします。

クラスタ オートスケーラーの仕組み

クラスタ オートスケーラーはノードプールごとに機能します。クラスタ オートスケーラーを使用してノードプールを構成する場合は、ノードプールの最小サイズと最大サイズを指定します。

クラスタ オートスケーラーは、ノードプールの基盤となる Compute Engine マネージド インスタンス グループ(MIG)で仮想マシン(VM)インスタンスを追加または削除して、ノードプールのサイズを自動的に調整します。クラスタ オートスケーラーは、実際のリソース使用率ではなくノードプールのノードで実行されている Pod のリソース リクエスト数に基づいてスケーリングを決定します。Pod とノードのステータスを定期的にチェックし、次の処理を行います。

  • 現在のノードに Pod をスケジュールできない場合、クラスタ オートスケーラーはノードプールの最大サイズまでノードを追加します。クラスタ オートスケーラーがクラスタのサイズを変更するタイミングについては、クラスタ オートスケーラーがクラスタのサイズを変更するタイミングをご覧ください。
  • GKE がノードプールに新しいノードを追加することを決定した場合、クラスタ オートスケーラーは、ノードプールごとまたはクラスタごとの上限まで、必要に応じてノードを追加します。
  • クラスタ オートスケーラーは、ノードを順番に作成するわけではありません。GKE が作成するノードの数を決定すると、ノードの作成は並行して行われます。目的は、スケジューリングできない Pod が Active になるまでの時間を最小限に抑えることです。
  • 割り当てが不足して一部のノードが作成されない場合、クラスタ オートスケーラーはリソースが正常にスケジュールされるまで待機します。
  • ノードの使用率が低く、ノードプール内のノード数を少なくしてもすべての Pod のスケジューリングが可能な場合、クラスタ オートスケーラーはノードプールの最小サイズになるまでノードを削除します。クラスタ内の他のノードに移動できないノードに Pod がある場合、クラスタ オートスケーラーはそのノードをスケールダウンしません。Pod を他のノードに移動できるが、タイムアウト期間(現在は 10 分)の経過後にノードを正常にドレインできない場合、ノードは強制終了されます。GKE クラスタの猶予期間は構成できません。スケールダウンの仕組みについて詳しくは、クラスタ オートスケーラーのドキュメントをご覧ください。

クラスタ オートスケーラーがクラスタを検査してスケジューリングできない Pod を探す頻度は、クラスタのサイズに大きく依存します。小規模なクラスタでは、検査は数秒ごとに行われる場合があります。この検査に必要な正確な期間を定義することはできません。

Pod がリクエストするリソースが少なすぎる場合、あるいは、過小なデフォルト値をそのまま使用している場合、クラスタ オートスケーラーで状況を改善することはできません。クラスタ オートスケーラーが正常に動作するように、すべてのワークロードに明示的なリソース リクエストを行う必要があります。

クラスタのノードで、マネージド インスタンス グループに対する Compute Engine の自動スケーリングを有効にしないでください。GKE のクラスタ オートスケーラーは、Compute Engine の自動スケーリングとは別のものです。Compute Engine オートスケーラーが GKE のクラスタ オートスケーラーと競合するため、ノードプールのスケールアップまたはスケールダウンに失敗する場合があります。

動作条件

ノードプールのサイズを変更する場合、クラスタ オートスケーラーは次のことを前提とします。

  • 複製対象のすべての Pod を他のノードで再起動できます。これにより、短い中断が発生する可能性があります。
  • ユーザーまたは管理者はノードを手動で管理しません。クラスタ オートスケーラーによって、手動で行ったノード管理オペレーションが無効になる可能性があります。
  • 1 つのノードプール内のすべてのノードに同じラベルセットが使用されます。
  • クラスタ オートスケーラーは、各プール内のインスタンス タイプの相対的なコストを考慮し、最もコストのかからないノードプールを拡張しようとします。ただし、クラスタ オートスケーラーのこの動作には次の条件が適用されます。
    • クラスタ オートスケーラーは、プリエンプティブルな Spot VM を含むノードプールの費用削減を考慮します。ただし、クラスタ オートスケーラーは各ゾーンのリソースの可用性も考慮するため、より高価だが使用可能なリソースを選択する場合があります。
    • 複数のノードプールで Spot VM を使用している場合、クラスタ オートスケーラーは最も低コストのオプションを自動的に選択しません。費用対効果の高い Spot VM の使用を最適化し、このシナリオを防ぐには、カスタム コンピューティング クラスを使用することをおすすめします。
  • クラスタ オートスケーラーは、Pod をスケジューリングする前に init コンテナのリクエストを考慮します。init コンテナのリクエストでは、ノードで利用可能な未割り当てリソースが使用可能であるため、Pod をスケジューリングできない可能性があります。クラスタ オートスケーラーは、Kubernetes で使用されるものと同じリクエスト計算ルールに従います。詳細については、init コンテナの使用に関する Kubernetes のドキュメントをご覧ください。
  • 最初のクラスタまたはノードプールの作成後に手動で追加されたラベルは追跡されません。クラスタ オートスケーラーによって作成されたノードには、ノードプールの作成時に --node-labels で指定されたラベルが割り当てられます。
  • GKE バージョン 1.21 以前では、クラスタ オートスケーラーはノードプールの既存のノードの taint 情報をノードプール全体を表すものと見なします。GKE バージョン 1.22 以降、クラスタ オートスケーラーは、クラスタ内の既存のノードとノードプールからの情報を結合します。クラスタ オートスケーラーは、ノードとノードプールに手動で加えた変更も検出します。
ベスト プラクティス:

アプリケーションで中断が許容される場合は、クラスタ オートスケーラーを有効にしないでください。

ゾーン間での均衡化

ノードプールに同じインスタンス タイプを持つ複数のマネージド インスタンス グループが含まれている場合、クラスタ オートスケーラーは、スケールアップ時にこうしたマネージド インスタンス グループのサイズの均衡化を図ります。これにより、ノードプールの複数のゾーン内にあるマネージド インスタンス グループ間でノードの分配が不均一になる事態を回避できます。GKE はスケールダウン時に自動スケーリング ポリシーを考慮しません。

クラスタ オートスケーラーがゾーン間で均衡化を図るのは、スケールアップ時のみです。スケールダウン時には、ノードプール内の基盤マネージド インスタンス グループの相対サイズに関係なく、使用率の低いノードが削除されるため、ゾーン間でノードの分配が不均一になる可能性があります。

ロケーション ポリシー

GKE バージョン 1.24.1-gke.800 以降では、クラスタ オートスケーラーのロケーション ポリシーを変更できます。クラスタ オートスケーラーの配布ポリシーは、location_policy フラグに次のいずれかの値を指定することにより制御できます。

  • BALANCED: クラスタ オートスケーラーは、Pod の要件と各ゾーンのリソースの可用性を考慮します。クラスタ オートスケーラーは、特定のゾーン内で使用可能な容量や、スケールアップをトリガーした Pod のゾーン アフィニティなど、多くの要因を考慮するため、同様のノードグループのサイズがまったく同じになるとは限りません。
  • ANY: クラスタ オートスケーラーは、未使用の予約とアカウントの利用を優先させ、使用可能なリソースの現在の制約を考慮します。
ベスト プラクティス:

Spot VM を使用している場合や、ゾーン間で均等でない VM 予約を使用する場合は、ANY ポリシーを使用します。

予約

GKE バージョン 1.27 以降では、クラスタ オートスケーラーは、スケールアップの決定時に常に予約を考慮します。未使用の予約と一致するノードプールは、ノードプールが最も効率的なものでない場合でも、スケールアップするノードプールを選択する際に優先されます。また、マルチゾーンのスケールアップの均衡化を図る際には、未使用の予約が常に優先されます。

ただし、クラスタ オートスケーラーは独自のプロジェクトでのみ予約を確認します。その結果、クラスタのプロジェクト内でより安価なノード オプションが利用可能な場合、オートスケーラーは共有予約ではなく、そのオプションを選択する可能性があります。プロジェクト間で予約を共有する必要がある場合は、カスタム コンピューティング クラスの使用を検討してください。これにより、クラスタ オートスケーラーがノードのスケーリングに使用する優先度(共有予約を含む)を構成できます。

デフォルト値

Spot VM ノードプールの場合、デフォルトのクラスタ オートスケーラー配布ポリシーは ANY です。このポリシーでは、Spot VM がプリエンプトされるリスクが低くなります。

プリエンプティブル以外のノードプールの場合、デフォルトのクラスタ オートスケーラー配布ポリシーは BALANCED です。

ノードプールの最小サイズと最大サイズ

新しいノードプールを作成するときに、クラスタ内の各ノードプールの最小サイズと最大サイズを指定できます。クラスタ オートスケーラーは、これらのスケーリングの制約内で再スケーリングを決定します。最小サイズを更新するには、新しい最小値を指定してから、クラスタを新しい制約内のサイズに手動でサイズ変更します。クラスタ オートスケーラーは、新しい制約に基づいて再スケーリングを決定します。

現在のノードプール サイズ クラスタ オートスケーラーのアクション スケーリングの制約
指定した最小値を下回っている クラスタ オートスケーラーは、保留中の Pod をプロビジョニングするためにスケールアップします。スケールダウンが無効になります。 ノードプールは、指定した値以下にスケールダウンされません。
指定した最小サイズと最大サイズの範囲内 クラスタ オートスケーラーは、需要に応じてスケールアップまたはスケールダウンします。 ノードプールは、指定したサイズの制限内に収まります。
指定した最大値を超えている クラスタ オートスケーラーは、安全に削除できるノードのみをスケールダウンします。スケールアップが無効になります。 ノードプールは、指定した値を超えてスケーリングすることはありません。

Standard クラスタでは、クラスタ オートスケーラーがクラスタをゼロノードまで自動的にスケールダウンすることはありません。システム Pod を実行するには、クラスタ内で 1 つ以上のノードが常に使用可能である必要があります。また、ノードを手動で削除したために現在のノード数がゼロになっている場合は、クラスタ オートスケーラーとノードの自動プロビジョニングにより、ゼロノード クラスタからスケールアップされます。

オートスケーラーの決定の詳細については、クラスタ オートスケーラーの制限をご覧ください。

自動スケーリングの制限

クラスタ オートスケーラーがノードプールをスケーリングするときに使用するノードの最小数と最大数を設定できます。--min-nodes フラグと --max-nodes フラグを使用して、ゾーンあたりのノードの最小数と最大数を設定します。

GKE バージョン 1.24 以降では、新しいクラスタに --total-min-nodes フラグと --total-max-nodes フラグを使用できます。これらのフラグは、すべてのゾーンのノードプール内にあるノードの最小数と最大数を設定します。

最小ノード数と最大ノード数の例

次のコマンドでは、6 ノードから構成される自動スケーリングのマルチゾーン クラスタを 3 つのゾーンに作成します。各ゾーンの最小ノード数は 1、最大ノード数は 4 になります。

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --min-nodes=1 --max-nodes=4

この例では、クラスタの合計サイズは 3~12 ノードで、これらのノードは 3 つのゾーンに分散しています。いずれかのゾーンで障害が発生すると、クラスタの合計サイズは 2~8 ノードになります。

合計ノード数の例

GKE バージョン 1.24 以降で利用可能な次のコマンドは、最初に 3 つのゾーンに 6 つのノードを持つ自動スケーリング マルチゾーン クラスタを、すべてのゾーンで、ノードプール内の最小 3 つ、最大 12 個のノードで作成します。

gcloud container clusters create example-cluster \
    --num-nodes=2 \
    --location=us-central1-a \
    --node-locations=us-central1-a,us-central1-b,us-central1-f \
    --enable-autoscaling --total-min-nodes=3 --total-max-nodes=12

この例では、ゾーン間の分散に関係なく、クラスタの合計サイズを 3~12 ノードにできます。

自動スケーリング プロファイル

ノードを削除するタイミングを決定することは、使用率の最適化とリソースの可用性とのトレードオフです。使用率の低いノードを削除するとクラスタの使用率は向上しますが、新しいワークロードの実行の際に、リソースが再度プロビジョニングされるのを待機しなければならない状況が生じる可能性があります。

このような決定を行うときに使用する自動スケーリング プロファイルを指定できます。利用可能なプロファイルは以下のとおりです。

  • balanced: 受信 Pod で使用可能なリソースを増やすことを優先し、Standard クラスタでリソースを有効にする時間を短縮するデフォルトのプロファイル。balanced プロファイルは、Autopilot クラスタでは使用できません。
  • optimize-utilization: クラスタ内で余剰リソースを保持するよりも使用率の最適化を優先させます。このプロファイルを有効にすると、クラスタ オートスケーラーはクラスタをより積極的にスケールダウンします。GKE は、ノードをより多く、より迅速に削除できます。GKE は、すでに CPU、メモリ、または GPU が大量に割り当てられているノードで Pod をスケジュールすることを優先します。ただし、同じ Deployment、StatefulSet、Service に属する Pod のノード間の分散など、他の要因はスケジューリングに影響します。

optimize-utilization 自動スケーリング プロファイルを使用すると、クラスタ オートスケーラーが使用率の低いノードを特定して削除しやすくなります。この最適化を実現するために、GKE により Pod 仕様のスケジューラ名が gke.io/optimize-utilization-scheduler に設定されます。カスタム スケジューラを指定する Pod は影響を受けません。

次のコマンドを使用すると、既存のクラスタで optimize-utilization 自動スケーリング プロファイルが有効になります。

gcloud container clusters update CLUSTER_NAME \
    --autoscaling-profile optimize-utilization

Pod のスケジューリングと停止の考慮

スケールダウンする場合、クラスタ オートスケーラーは、Pod に設定されているスケジューリング ルールとエビクション ルールを考慮します。この制限により、オートスケーラーによってノードが削除されるのを防ぐことができます。次のいずれかの条件を持つポッドが含まれていると、ノードの削除を防ぐことができます。

  • ポッドのアフィニティまたは反アフィニティ ルールにより、再スケジューリングが防止される。
  • ポッドが、Deployment、StatefulSet、Job、ReplicaSet などのコントローラによって管理されていない。
  • Pod にローカル ストレージがあり、GKE コントロール プレーン バージョンが 1.22 未満である。コントロール プレーン バージョン 1.22 以降の GKE クラスタでは、ローカル ストレージを使用する Pod でスケールダウンがブロックされなくなりました。
  • Pod に "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" アノテーションがある。
  • ノードの削除が、構成された PodDisruptionBudget を超える可能性があります。

クラスタ オートスケーラーの詳細と中断を防ぐ方法については、クラスタ オートスケーラーに関するよくある質問をご覧ください。

GKE での TPU の自動スケーリング

GKE は、ML ワークロードを高速化するために Tensor Processing Unit(TPU)をサポートしています。単一ホストの TPU スライス ノードプールマルチホストの TPU スライス ノードプールはどちらも、自動スケーリングと自動プロビジョニングをサポートしています

GKE クラスタで --enable-autoprovisioning フラグを指定すると、GKE は、TPU のバージョンとトポロジが保留中のワークロードの要件を満たしている単一ホストまたはマルチホストの TPU スライス ノードプールを作成または削除します。

--enable-autoscaling を使用すると、GKE はタイプに基づいてノードプールを次のようにスケーリングします。

  • 単一ホストの TPU スライス ノードプール: GKE は、既存のノードプールで TPU ノードを追加または削除します。ノードプールには、0 からノードプールの最大サイズまでの任意の数の TPU ノードが含まれます。最大サイズは、--max-nodes フラグと --total-max-nodes フラグによって決まります。ノードプールがスケーリングされると、ノードプール内のすべての TPU ノードのマシンタイプとトポロジは同じになります。単一ホストの TPU スライス ノードプールを作成する方法については、ノードプールを作成するをご覧ください。

  • マルチホスト TPU スライス ノードプール: GKE は、ノードプールを 0 から TPU トポロジを満たすために必要なノード数までアトミックにスケールアップします。たとえば、マシンタイプが ct5lp-hightpu-4t でトポロジが 16x16 の TPU ノードプールの場合、ノードプールには 64 個のノードが含まれます。GKE オートスケーラーは、このノードプールのノード数が 0 または 64 になるように調整します。スケールダウンすると、GKE はスケジュールされたすべての Pod を強制排除し、ノードプール全体が 0 になるようにドレインします。マルチホスト TPU スライス ノードプールの作成方法については、ノードプールを作成するをご覧ください。

Spot VM とクラスタ オートスケーラー

クラスタ オートスケーラーは最も安価なノードプールの拡張を優先するため、ワークロードとリソースの可用性で許容される場合は、スケールアップ時に Spot VM を追加します。

ただし、クラスタ オートスケーラーは Spot VM の追加を優先しますが、この設定によって Pod の大部分がこれらのタイプの VM で実行されることが保証されるわけではありません。Spot VM はプリエンプトできます。このプリエンプトにより、Spot VM の Pod が削除される可能性が高くなります。強制排除されると、15 秒以内に終了する必要があります。

たとえば、10 個の Pod とオンデマンド VM と Spot VM の混合があるとします。

  • Spot VM が使用できなかったため、オンデマンド VM で 10 個の Pod が実行されています。
  • 10 個の Pod がすべて必要ないため、クラスタ オートスケーラーは 2 つの Pod を削除し、余分なオンデマンド VM をシャットダウンします。
  • 10 個の Pod が再び必要になると、クラスタ オートスケーラーは Spot VM を追加し(安価であるため)、その VM に 2 個の Pod をスケジュールします。残りの 8 個の Pod はオンデマンド VM に残ります。
  • クラスタ オートスケーラーが再度スケールダウンする必要がある場合、Spot VM が最初にプリエンプトされ、ほとんどの Pod がオンデマンド VM で実行される可能性があります。

Spot VM を優先し、上記のシナリオを回避するには、カスタム コンピューティング クラスを使用することをおすすめします。カスタム コンピューティング クラスを使用すると、スケールアップ時に Spot VM を優先する優先度ルールを作成できます。このルールでは、オンデマンド ノードよりも高い優先度を Spot VM に付与します。Spot VM に基づくノードで Pod が実行される可能性をさらに高めるには、アクティブな移行を構成します。

次の例は、カスタム コンピューティング クラスを使用して Spot VM を優先する方法の 1 つを示しています。

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: prefer-l4-spot
spec:
  priorities:
  - machineType: g2-standard-24
    spot: true
    gpu:
      type: nvidia-l4
      count: 2
  - machineType: g2-standard-24
    spot: false
    gpu:
      type: nvidia-l4
      count: 2
  nodePoolAutoCreation:
    enabled: true
  activeMigration:
    optimizeRulePriority: true

上記の例では、優先度ルールで g2-standard-24 マシンタイプと Spot VM を使用してノードを作成する優先度が宣言されています。Spot VM が使用できない場合、GKE はフォールバック オプションとしてオンデマンド VM を使用します。このコンピューティング クラスでは activeMigration も有効になり、容量が使用可能になったときにクラスタ オートスケーラーがワークロードを Spot VM に移行できるようになります。

カスタム コンピューティング クラスを使用できない場合は、ノード アフィニティ、テイスト、容認を追加します。たとえば、次のノード アフィニティ ルールは、Spot VM によってバックアップされているノードで Pod をスケジュールすることを指定します(GKE は、これらのタイプのノードに cloud.google.com/gke-spot=true ラベルを自動的に追加します)。

affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
    preference:
      matchExpressions:
      - key: cloud.google.com/gke-spot
        operator: Equal
        values:
        - true

ノード アフィニティ、taint、toleration を使用して Spot VM をスケジュールする方法については、オンデマンド ノードをフォールバックとして Spot ノードで GKE アプリケーションを実行するブログをご覧ください。

ProvisioningRequest CRD

ProvisioningRequest は、ユーザーがクラスタ自動スケーラーから Pod のグループの容量をリクエストできるようにする名前空間付きのカスタム リソースです。これは、単一のユニットとして一緒にスケジュールする必要がある相互接続された Pod を持つアプリケーションで特に役立ちます。

サポートされているプロビジョニング クラス

サポートされている ProvisioningClass は次の 3 つです。

  • queued-provisioning.gke.io: この GKE 固有のクラスは Dynamic Workload Scheduler と統合されており、リソースが使用可能になったときにリクエストをキューに登録して処理できます。これは、バッチジョブや遅延許容ワークロードに最適です。GKE でキューに格納されたプロビジョニングを使用する方法については、Dynamic Workload Scheduler を使用してバッチ ワークロードと AI ワークロード用の GPU をデプロイするをご覧ください。Standard クラスタでは GKE バージョン 1.28.3-gke.1098000 以降、Autopilot クラスタでは GKE バージョン 1.30.3-gke.1451000 以降でサポートされています。

  • check-capacity.autoscaling.x-k8s.io: このオープンソース クラスは、Pod のスケジュール設定を試みる前にリソースの可用性を検証します。GKE バージョン 1.30.2-gke.1468000 以降でサポートされています。

  • best-effort-atomic.autoscaling.x-k8s.io: このオープンソース クラスは、リクエスト内のすべての Pod のリソースをまとめてプロビジョニングしようとします。すべての Pod に十分なリソースをプロビジョニングできない場合、リソースはプロビジョニングされず、リクエスト全体が失敗します。GKE バージョン 1.31.27 以降でサポートされています。

CheckCapacity クラスと BestEffortAtomicScaleUp クラスの詳細については、オープンソースのドキュメントをご覧ください。

ProvisioningRequest を使用する場合の制限事項

  • GKE クラスタ オートスケーラーは、ProvisioningRequest ごとに 1 つの PodTemplate のみをサポートします。
  • GKE クラスタ オートスケーラーは、一度に 1 つのノードプールのみをスケールアップできます。ProvisioningRequest で複数のノードプールのリソースが必要な場合は、ノードプールごとに個別の ProvisioningRequest を作成する必要があります。

ProvisioningRequest を使用する際のベスト プラクティス

  • total-max-nodes: ノードの最大数(--max nodes)を制限する代わりに、--total-max-nodes を使用して、アプリケーションが消費するリソースの合計を制限します。
  • location-policy=ANY を使用する: この設定により、Pod を使用可能な任意のロケーションにスケジュールできます。これにより、プロビジョニングを迅速化し、リソース使用率を最適化できます。
  • (省略可)Kueue との統合: Kueue は ProvisioningRequest の作成を自動化し、ワークフローを効率化できます。詳細については、Kueue のドキュメントをご覧ください。

その他の情報

クラスタ オートスケーラーの詳細については、オープンソースの Kubernetes プロジェクトの自動スケーリングに関する FAQ をご覧ください。

制限事項

クラスタ オートスケーラーには次の制限があります。

  • クラスタ オートスケーラーはローカル PersistentVolume をサポートしていません。
  • 1.24.5-gke.600 より前の GKE コントロール プレーンでは、Pod がエフェメラル ストレージをリクエストするときに、クラスタ オートスケーラーは、エフェメラル ストレージとしてローカル SSD を使用するゼロノードでのノードプールのスケールアップをサポートしていません。
  • クラスタサイズの制限: 最大 15,000 ノード。このサイズのクラスタを実行する場合は、他のクラスタ制限ベスト プラクティスを考慮してください。
  • スケールダウンの場合、ノードの Pod を別のノードに再スケジューリングするため、クラスタ オートスケーラーは 10 分間の猶予期間を使用します。この期間が経過すると、ノードを強制終了します。
  • 場合によっては、クラスタ オートスケーラーのスケールダウンが完全でなく、スケールダウン後に余分なノードが存在することがあります。これは、必要なシステムポッドが別のノード用にスケジュールされているときに発生する可能性があります。これらのポッドを別のノードに移動するためのトリガーがないためです。使用率が低いノードがいくつかありますが、スケールダウンされません。どうしてでしょうか?をご覧ください。この制限を回避するには、Pod 停止予算を構成できます。
  • フィルタを変更したカスタム スケジュール設定はサポートされていません。
  • クラスタ オートスケーラーは、保留中の Pod の新しいノードをプロビジョニングするかどうかを決定する際に、デフォルトの kube-scheduler の動作を考慮します。カスタム スケジューラの使用はサポートされておらず、予期しないスケーリング動作が発生する可能性があります。
  • Pod の PriorityClass 値が -10 以下の場合、ノードはスケールアップされません。詳細については、クラスタ オートスケーラーが Pod の優先度とプリエンプションでどのような役割を果たしているかをご覧ください。
  • クラスタ オートスケーラーには、新しいノードや Pod を追加するのに十分な IP アドレス空間が割り振られていないことがあり、その場合はスケールアップ エラーが発生します。このエラーでは、eventResult イベントの理由が scale.up.error.ip.space.exhausted となります。ノードの IP アドレスを追加するには、プライマリ サブネットを拡張するか、不連続マルチ Pod CIDRを使用して新しい IP アドレスを Pod に追加します。詳細については、Pod 用の空き IP スペースが不足しているをご覧ください。
  • GKE クラスタ オートスケーラーは、オープンソースの Kubernetes プロジェクトのクラスタ オートスケーラーとは異なります。GKE クラスタ オートスケーラーのパラメータはクラスタ構成に依存し、変更される可能性があります。自動スケーリングの動作をより細かく制御する必要がある場合は、GKE クラスタ オートスケーラーを無効にして、オープンソースの Kubernetes のクラスタ オートスケーラーを実行します。ただし、オープンソースの Kubernetes は Google Cloud サポートされていません。
  • 自動スケーリングが有効になっている GKE ノードプールを削除すると、ノードに NoSchedule フラグが設定され、これらのノード上の Pod は直ちに強制排除されます。使用可能なリソースの急激な減少を緩和するために、ノードプールのオートスケーラーは同じノードプール内に新しいノードをプロビジョニングすることがあります。新しく作成されたノードはスケジューリングに使用できるようになり、強制排除された Pod はこれらのノードに再度スケジューリングされます。最終的に、新しくプロビジョニングされたノードとその Pod を含むノードプール全体が削除され、サービスが中断される可能性があります。回避策として、削除中にオートスケーラーが新しいノードをプロビジョニングしないようにするには、削除を開始する前にノードプールで自動スケーリングを無効にします。

既知の問題

  • GKE コントロール プレーンのバージョンが 1.22 より前の場合、GKE クラスタ オートスケーラーは空の(ゼロノード)クラスタですべてのノードプールのスケールアップを停止します。この動作は、GKE バージョン 1.22 以降では生じません。

トラブルシューティング

トラブルシューティングのヒントについては、次のページをご覧ください。

次のステップ