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

Autopilot Standard

---

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

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

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 を含むノードプールの費用削減を考慮します。
• クラスタ オートスケーラーは、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: クラスタ オートスケーラーは、未使用の予約リソースの活用を優先し、利用可能なリソースの現在の制約を考慮します。

ベスト プラクティス:

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

予約

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 \
    --zone=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 \
    --zone=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 を超える可能性があります。

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

• スケールダウンの仕組み
• スケールダウン時にクラスタ オートスケーラーは PodDisruptionBudget と連携しますか？
• クラスタ オートスケーラーによるノードの削除を防ぐ Pod の種類はありますか？
• GKE でクラスタ オートスケーラーをチューニングする仕組み

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 を追加し（費用が安いため）、2 つの Pod をスケジューリングします。残りの 8 つの Pod はオンデマンド VM に残ります。
• クラスタ オートスケーラーが再度スケールダウンする必要がある場合、Spot VM が最初にプリエンプトされ、ほとんどのポッドがオンデマンド 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 に移行できます。

カスタム コンピューティング クラスを使用できない場合は、ノード アフィニティ、タグ、toleration を追加します。たとえば、次のノード アフィニティ ルールは、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

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

ProvisioningRequest CRD

ProvisioningRequest は、クラスタ自動スケーリングから Pod のグループの容量をリクエストできる、Namespace 方式のカスタム リソースです。これは、相互接続された Pod があり、単一のユニットとして一緒にスケジュールする必要があるアプリケーションに特に便利です。

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

サポートされている ProvisioningClasses は次の 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 の 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 コントロール プレーンのバージョンが 1.22 より前の場合、GKE クラスタ オートスケーラーは空の（ゼロノード）クラスタですべてのノードプールのスケールアップを停止します。この動作は、GKE バージョン 1.22 以降では生じません。

トラブルシューティング

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

• クラスタ オートスケーラーがスケールダウンしない問題のトラブルシューティング
• クラスタ オートスケーラーがスケールアップしない問題のトラブルシューティング

次のステップ

• ノードを自動スケーリングする方法を学習する。
• ノードを自動アップグレードする方法を学習する。
• ノードを自動修復する方法を学習する。
• 新しいノードでのイメージの pull 時間を短縮する方法を確認する。