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

Autopilot Standard

---

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

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

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

ベスト プラクティス:

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

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

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: クラスタ オートスケーラーは、未使用の予約とアカウントの利用を優先させ、使用可能なリソースの現在の制約を考慮します。

ベスト プラクティス:

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 \
    --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 に設定されているスケジューリング ルールとエビクション ルールを考慮します。この制限により、オートスケーラーによってノードが削除されるのを防ぐことができます。次のいずれかの条件を持つ Pod が含まれていると、ノードの削除を防ぐことができます。

• 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 スライス ノードプールの作成方法については、ノードプールを作成するをご覧ください。

その他の情報

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

制限事項

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

• クラスタ オートスケーラーはローカル PersistentVolume をサポートしていません。
• 1.24.5-gke.600 より前の GKE コントロール プレーンでは、Pod がエファメラル ストレージをリクエストするときに、クラスタ オートスケーラーは、エファメラル ストレージとしてローカル SSD を使用するゼロノードでのノードプールのスケールアップをサポートしていません。
• クラスタサイズの制限: 最大 15,000 ノード。このサイズのクラスタを実行する場合は、他のクラスタ制限とベスト プラクティスを考慮してください。
• スケールダウンの場合、ノードの Pod を別のノードに再スケジューリングするため、クラスタ オートスケーラーは 10 分間の猶予期間を使用します。この期間が経過すると、ノードを強制終了します。
• 場合によっては、クラスタ オートスケーラーのスケールダウンが完全でなく、スケールダウン後に余分なノードが存在することがあります。これは、必要なシステム Pod が別のノード用にスケジュールされているときに発生する可能性があります。これらのポッドを別のノードに移動するためのトリガーがないためです。使用率が低いノードがいくつかありますが、スケールダウンされません。どうしてでしょうか？をご覧ください。この制限を回避するには、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 時間を短縮する方法を確認する。