ACK クラスタでサポートされているスケジューリングポリシー - Container Service for Kubernetes

Kubernetes クラスタでは、kube-scheduler という名前のスケジューリングコンポーネントが、リソース割り当てに基づいてポッドをノードにスケジュールし、アプリケーションの高可用性を確保し、クラスタリソースの使用率を向上させます。Container Service for Kubernetes (ACK) は、ジョブスケジューリング、トポロジー対応スケジューリング、サービス品質 (QoS) 対応スケジューリング、デスクジューリングなど、さまざまなワークロードに対して柔軟で多様なスケジューリングポリシーを提供します。

始める前に

このトピックでは、クラスタ O&M エンジニア (クラスタリソース管理者を含む) およびアプリケーション開発者を対象としたクラスタスケジューリングソリューションについて説明します。ビジネスシナリオとビジネスロールに基づいてスケジューリングポリシーを選択できます。
- O&M エンジニアはクラスタのコストに関心があり、リソースの無駄を避けるためにクラスタリソースの使用率を最大化する必要があります。また、クラスタの高可用性とノード間の負荷分散を確保し、単一障害点 (SPOF) を回避する必要があります。
- アプリケーション開発者は、簡単な方法でアプリケーションをデプロイおよび管理したいと考えています。アプリケーションは、パフォーマンス要件に基づいて、CPU、GPU、メモリリソースなどの必要なリソースを取得できます。
ACK が提供するスケジューリングポリシーをより適切に活用するために、スケジューリング用語について学習することをお勧めします。詳細については、「Kubernetes スケジューラ」、「ノードラベル」、「ノードプレッシャーエビクション」、および「ポッドトポロジースプレッド制約」をご参照ください。
ACK スケジューラのデフォルトのスケジューリングポリシーは、オープンソースの Kubernetes スケジューラのデフォルトのスケジューリングポリシーと同じです。デフォルトのスケジューリングポリシーは、フィルタプラグインとスコアプラグインで構成されています。

Kubernetes ネイティブスケジューリングポリシー

Kubernetes ネイティブスケジューリングポリシーは、ノードスケジューリングポリシーとポッド間スケジューリングポリシーに分類できます。

ノードスケジューリングポリシー: ノードの特性とリソース条件に焦点を当て、ポッドが要件を満たすノードにスケジュールされるようにします。
ポッド間スケジューリングポリシー: ポッドの分散を制御することに焦点を当て、ポッドの全体的なデプロイを最適化し、アプリケーションの高可用性を確保します。

ポリシー	説明	シナリオ
nodeSelector	キーと値のペアを追加することでノードにラベルを付け、nodeSelector を使用して、指定されたラベルを持つノードにポッドをスケジュールできます。たとえば、nodeSelector を使用して、ポッドを特定のノードにスケジュールしたり、ポッドを特定のノードプールにスケジュールしたりできます。	これは基本的なノード選択機能であり、アンチアフィニティルールなどの複雑なスケジューリング機能はサポートしていません。
nodeAffinity	このスケジューリングポリシーは、NodeSelector を使用するスケジューリングポリシーよりも柔軟で詳細です。たとえば、`requiredDuringSchedulingIgnoredDuringExecution` アフィニティルールと `preferredDuringSchedulingIgnoredDuringExecution` アンチアフィニティルールです。	リージョン、デバイスタイプ、ハードウェア構成など、特定の特性を持つノードにポッドをスケジュールします。アンチアフィニティルールは、ポッドをノードに分散するために使用されます。
テイントと許容	テイントは、キー、値、および効果で構成されます。一般的な効果は、`NoSchedule`、`PreferNoSchedule`、`NoExecute` です。ノードにテイントを追加した後、テイントを許容するように許容が構成されているポッドのみがノードにスケジュールされます。	テイントと許容を使用して、特定のアプリケーション専用のノードリソースを予約できます。たとえば、AI または機械学習 (ML) ワークロード用に GPU アクセラレーションノードを予約します。 ACK では、ノードプールにテイントまたはラベルを追加して、特定のアプリケーションポッドを指定されたノードプールにスケジュールできます。詳細については、「ノードプールを作成および管理する」および「ノードプールを変更する」をご参照ください。テイントと許容に基づいてポッドをエビクトします。たとえば、異常なノードにテイントを追加し、効果を `NoSchedule` に設定します。
ポッド間のアフィニティとアンチアフィニティ	ポッドラベルを使用して、ポッドを特定のノードにスケジュールするかどうかを指定します。`requiredDuringSchedulingIgnoredDuringExecution` アフィニティルールと `preferredDuringSchedulingIgnoredDuringExecution` アンチアフィニティルールがサポートされています。	連携して動作するポッドを同じノードまたは隣接ノードにスケジュールして、ネットワークレイテンシを削減し、通信効率を向上させます。ビジネスクリティカルなアプリケーションポッドを異なるノードまたは障害ドメインに分散します。

ACK が提供するスケジューリングポリシー

Kubernetes ネイティブスケジューリングポリシーがビジネス要件 (異なるインスタンスリソースの順次スケールアウトと逆スケールイン、ノードの実際のリソース使用量に基づく負荷対応スケジューリングなど) を満たせない場合は、ACK が提供する次のスケジューリングポリシーを参照できます。

優先度ベースのリソーススケジューリングを構成する

対象ロール: クラスタ O&M エンジニア。
説明: ACK クラスタに、サブスクリプション、従量課金、プリエンプティブルインスタンスなど、さまざまな課金方法で、Elastic Compute Service (ECS) インスタンスやエラスティックコンテナインスタンスなど、さまざまなタイプのインスタンスリソースが含まれている場合は、優先度ベースのリソーススケジューリングを構成することをお勧めします。これにより、ポッドのスケジューリング中にさまざまなタイプのノードリソースが選択される順序を指定し、逆の順序でスケールインアクティビティを実行できます。

ポリシー

説明

シナリオ

参照

カスタム優先度ベースのリソーススケジューリング

アプリケーションのリリースまたはスケーリング中に ResourcePolicy パラメータにカスタム値を指定して、ポッドのスケジューリング中にさまざまなタイプのノードリソースが選択される順序を指定できます。たとえば、ポッドは優先的にサブスクリプション ECS インスタンスにスケジュールされ、次に従量課金 ECS インスタンスにスケジュールされ、最後にエラスティックコンテナインスタンスにスケジュールされます。

アプリケーションは逆の順序でスケールインできます。たとえば、クラスタは優先的にエラスティックコンテナインスタンス上のポッドを削除し、次に従量課金 ECS インスタンス上のポッドを削除し、最後にサブスクリプション ECS インスタンス上のポッドを削除します。

優先されるノードまたは回避する必要があるノードを指定して、クラスタ内のノードのリソース使用量を調整します。
アプリケーションが高パフォーマンスを必要とする場合、アプリケーションを実行しているポッドは優先的に高パフォーマンスのノードにスケジュールされます。
アプリケーションが高パフォーマンスを必要としない場合、アプリケーションを実行しているポッドは優先的にプリエンプティブルインスタンスまたはアイドル状態の計算リソースが残っているノードにスケジュールされます。これにより、リソース使用コストが削減されます。

優先度ベースのリソーススケジューリングを構成する

ジョブスケジューリング

対象ロール: クラスタ O&M エンジニア。
説明: スケジューラは、事前定義されたルールに基づいてポッドを実行するノードを決定できます。ただし、スケジューラはバッチジョブのポッドのスケジューリングには適していません。ACK は、バッチジョブのギャングスケジューリングとキャパシティスケジューリングをサポートしています。

ポリシー	説明	シナリオ	参照
ギャングスケジューリング	関連するすべてのポッドがスケジュールされるか、ポッドがまったくスケジュールされません。これにより、特定の異常プロセスが相関プロセスのグループ全体をブロックするのを防ぎます。	バッチジョブ: ジョブには、同時に処理する必要がある複数の相互依存タスクが含まれています。分散コンピューティング: 機械学習トレーニングジョブ、または厳密に同時に実行する必要があるその他の分散アプリケーション。高性能コンピューティング: ジョブを実行する前に、ジョブですべてのリソースを同時に使用できる必要がある場合があります。	ギャングスケジューリングを使用する
キャパシティスケジューリング	特定の名前空間またはユーザーグループに特定量のリソースを予約し、クラスタリソースがほとんど不足しているときにリソース共有を実装することで、全体的なリソース使用率を向上させます。	マルチテナントシナリオでは、テナントごとに異なるリソースライフサイクルが要求され、リソースを異なる方法で使用します。その結果、クラスタリソースの使用率は低くなります。リソース使用率を向上させるには、一定量のリソースに基づいてリソースを共有および再利用する必要があります。	キャパシティスケジューリングを使用する

トポロジー対応スケジューリング

対象ロール: クラスタ O&M エンジニア。
説明: 機械学習とビッグデータ分析のワークロードでは、ポッドは多くの場合、集中的なポッド間ネットワーク通信を必要とします。デフォルトでは、スケジューラはクラスタ全体にポッドを均等に分散しますが、最終的にはジョブの完了時間が長くなります。既存のノードまたはポッドのアフィニティメカニズムでは、マルチトポロジードメインのスケジューリング再試行を実行できません。ノードにはゾーン固有のラベルのみがあります。

説明

シナリオ

参照

スケジューラは、ジョブにギャングスケジューリングラベルを追加して、すべてのポッドのリソースリクエストが同時に満たされるようにします。また、トポロジー対応スケジューリングを使用して、すべてのポッドの要件を満たすトポロジードメインが見つかるまで、スケジューラがトポロジードメインのリストをループするようにすることもできます。

ノードプールをデプロイメントセットに関連付けて、同じ低レイテンシデプロイメントセット内の ECS インスタンスにポッドをスケジュールし、ジョブのパフォーマンスを向上させることができます。

機械学習またはビッグデータ分析ジョブでは、ポッドは頻繁に通信する必要があります。スケジューラは、すべてのポッドの要件を満たすトポロジードメインが見つかるまで、トポロジードメインのリストをループする必要があります。これにより、ジョブの完了に必要な時間が短縮されます。

負荷対応スケジューリング

対象ロール: クラスタ O&M エンジニアおよびアプリケーション開発者。
説明: ネイティブスケジューリングポリシーに基づいて、スケジューラはリソース割り当てに基づいてポッドをスケジュールします。スケジューラは、ポッドのリソースリクエストとノード上の割り当て可能なリソースをチェックして、ポッドスケジューリングを決定します。ただし、ノードのリソース使用量は、時間の経過とともに、またはクラスタ環境、トラフィック、またはワークロードリクエストに基づいて動的に変化します。ネイティブスケジューラは、ノードの実際のリソース負荷を検出できません。

説明	シナリオ	参照
ノードの負荷の履歴統計を確認し、新しくスケジュールされたポッドのリソース使用量を推定することにより、ACK スケジューラはノードの負荷を監視し、負荷の低いノードにポッドをスケジュールして負荷分散を実装できます。これにより、単一の過負荷ノードによって引き起こされるアプリケーションまたはノードのクラッシュを防ぎます。	負荷またはアクセスレイテンシに敏感なアプリケーション、またはリソースの QoS クラスに要件があるアプリケーション。	負荷対応スケジューリングを使用する

ノード間の負荷分散の不均衡を防ぐために、負荷対応ホットスポットデスクジューリングを使用することをお勧めします。

QoS 対応スケジューリング

対象ロール: クラスタ O&M エンジニアおよびアプリケーション開発者。
説明: Guaranteed、Burstable、BestEffort など、ポッドの QoS クラスを構成します。ノードリソースが不足している場合、kubelet は QoS クラスに基づいてノードからエビクトするポッドを決定します。ACK は、サービスレベル目標 (SLO) 対応リソーススケジューリング機能を提供して、遅延の影響を受けやすいアプリケーションのパフォーマンスとサービス品質を向上させ、優先度の低いジョブのリソース使用量を確保します。

ポリシー	説明	シナリオ	参照
CPU バースト	CPU 制限のため、オペレーティングシステムはサイクル内でのリソースの使用を制限するため、コンテナでリソーススロットリング (CPU スロットリング) が発生する可能性があります。CPU バーストを使用すると、コンテナがアイドル状態のときに CPU タイムスライスを累積できます。コンテナは、リソース需要が急増したときに、累積された CPU タイムスライスを使用して CPU 制限を超えてバーストできます。これにより、コンテナのパフォーマンスが向上し、レイテンシが短縮され、サービス品質が向上します。	起動フェーズとロードフェーズでコンテナが大量の CPU リソースを消費するが、ロード完了後は通常の量の CPU リソースを占有するシナリオ。 e コマース、オンラインゲーム、その他の Web サービスやアプリケーションなど、CPU リソース需要が急激に増加するシナリオでは、コンテナはビジネストラフィックの急増に迅速に対応する必要があります。	CPU バーストを有効にする
トポロジー対応 CPU スケジューリング	CPU 依存ワークロードのポッドをノードの CPU コアに固定します。これにより、NUMA ノード間の頻繁な CPU コンテキストスイッチングとメモリアクセスによって引き起こされるアプリケーションパフォーマンスの低下という問題に対処します。	クラウドネイティブシナリオに適応していないアプリケーション。たとえば、スレッド数は、コンテナ仕様ではなく、デバイスの物理コアの合計に基づいて指定されます。その結果、アプリケーションのパフォーマンスが低下します。 Intel CPU または AMD CPU を搭載したマルチコア ECS ベアメタルインスタンスで実行され、NUMA ノード間のメモリアクセスが原因でパフォーマンスが低下するアプリケーション。 CPU コンテキストスイッチングに非常に敏感で、パフォーマンスの変動に耐えられないアプリケーション。	トポロジー対応 CPU スケジューリングを有効にする
トポロジー対応 GPU スケジューリング	クラスタに複数の GPU がデプロイされ、複数の GPU 集中型ポッドが同時に実行されている場合、ポッドは GPU リソースを競合し、異なる GPU または NUMA ノード間で頻繁に切り替わる可能性があります。これはアプリケーションのパフォーマンスに影響します。トポロジー対応 GPU スケジューリングは、ワークロードを異なる GPU にスケジュールできるため、NUMA ノード間のメモリアクセスが削減され、アプリケーションのパフォーマンスと応答速度が向上します。	高性能コンピューティングなど、効率的なデータ転送と処理を必要とする大規模分散コンピューティングシナリオ。機械学習やディープラーニングなど、学習とトレーニングに大量の GPU リソースと、トレーニングジョブを異なる GPU に適切に割り当てる必要があるシナリオ。グラフィックレンダリングやゲーム開発など、レンダリングジョブを異なる GPU に効率的に割り当てる必要があるシナリオ。	GPU トポロジー対応スケジューリング NUMA トポロジー対応スケジューリングを有効にする
動的リソースオーバーコミットメント	ポッドに割り当てられているが使用されていないリソースを定量化し、低優先度ジョブにリソースをスケジュールして、リソースオーバーコミットメントを実現します。アプリケーションが相互に影響しないように、次の単一ノード QoS ポリシーを一緒に使用する必要があります。 CPU サプレス: ノードの全体的なリソース使用率がしきい値を下回っている場合に、優先度の低いポッドが使用できる CPU リソースの量を制限します。これにより、ノード上のコンテナの安定性が確保されます。 CPU QoS: QoS クラスを使用して、優先度の高いアプリケーションに十分な CPU リソースが割り当てられるようにします。メモリ QoS: QoS クラスを使用して、優先度の高いアプリケーションに十分なメモリリソースが割り当てられ、メモリ再利用メカニズムがトリガーされる時間を遅らせます。 L3 キャッシュとメモリの帯域幅割り当て (MBA) に基づくリソース分離: QoS クラスを使用して、L3 キャッシュと MBA が高優先度アプリケーションで優先されるようにします。	コロケーションを使用してクラスタのリソース使用率を向上させます。典型的なコロケーションシナリオは、機械学習モデルのトレーニングと推論、ビッグデータバッチ処理とデータ分析、オンラインサービス、オフラインバックアップサービスです。	動的リソースオーバーコミットメントを有効にする CPU サプレスを有効にするコンテナの CPU QoS を有効にするメモリ QoS L3 キャッシュと MBA に基づくリソース分離を有効にするコロケーションのベストプラクティス
ポッドのリソースパラメータを動的に変更する	Kubernetes 1.27 以前を実行しているクラスタのポッドのコンテナパラメータを変更する場合は、PodSpec パラメータを変更して変更を送信する必要があります。次に、ポッドが削除され、再作成されます。ACK では、ポッドを再起動せずに、ポッドの CPU パラメータ、メモリパラメータ、およびディスク IOPS 制限を変更できます。	この機能は、CPU とメモリリソースを一時的に調整する場合に適しています。	ポッドのリソースパラメーターを動的に変更する

デスクジューリング

対象ロール: クラスタ O&M エンジニアおよびアプリケーション開発者。
説明: クラスタの状態は常に変化しています。シナリオによっては、実行中のポッドを別のノードに移行する必要がある場合があります。つまり、ポッドを別のノードに再スケジュールする必要があります。

ポリシー	説明	シナリオ	参照
デスクジューリング	異なるノードのクラスタリソースが均等に使用されていないためにホットスポットノードが存在するシナリオ、またはノード属性の変更が原因で事前定義されたポリシーに基づいてポッドをスケジュールできないシナリオでは、ノードで適切にスケジュールされていないポッドを別のノードにスケジュールして、ポッドが最適なノードで実行されるようにすることができます。これにより、クラスタ内のワークロードの高可用性と効率性が確保されます。	クラスタ内のワークロードが均等に分散されていません。一部のノードは過負荷になっています。たとえば、コロケーションシナリオでは、異なるアプリケーションが同じノードにスケジュールされています。クラスタの全体的なリソース使用率は低いです。コストを削減するために一部のノードを削除したいと考えています。クラスタには多数のリソースフラグメントが含まれています。その結果、クラスタ内のリソースの合計量が十分であっても、ノードに十分なリソースがない場合があります。ノードにテイントまたはラベルが追加または削除されます。	デスクジューリングデスクジューリング機能を有効にする
負荷対応ホットスポットデスクジューリングを使用する	負荷対応スケジューリングとホットスポットデスクジューリングの組み合わせを使用して、ノードの負荷の変化を監視し、負荷しきい値を超えるノードを自動的に最適化して、ノードの過負荷を防ぐことができます。		負荷対応ホットスポットデスクジューリングを使用する

課金

ACK のスケジューリング機能を使用する場合、課金ルールに基づいて、クラスタ管理とクラウドリソースの料金が請求されます。さらに、スケジューリングコンポーネントに対して次の料金が請求されます。

kube-scheduler によって提供されるデフォルトの ACK スケジューラは、無料でインストールして使用できるコントロールプレーンコンポーネントです。
ACK のリソーススケジューリング最適化とデスクジューリング機能は、ack-koordinator に基づいて実装されています。ack-koordinator のインストールと使用は無料ですが、特定のシナリオでは追加料金が発生する場合があります。詳細については、「ack-koordinator (ack-slo-manager)」をご参照ください。

FAQ

スケジューリング機能の使用中に問題が発生した場合は、トラブルシューティングについて「スケジューリングに関する FAQ」をご参照ください。

参照

kube-scheduler と ack-koordinator の紹介とリリースノートの詳細については、「kube-scheduler」および「ack-koordinator (旧称 ack-slo-manager)」をご参照ください。
kube-scheduler の動作をカスタマイズする方法の詳細については、「kube-scheduler のカスタムパラメータ」をご参照ください。
コロケーションアーキテクチャのベストプラクティスなど、スケジューリングシナリオのベストプラクティスの詳細については、「リソーススケジューリングのベストプラクティス」をご参照ください。
コストインサイトを有効にして、ACK クラスタのリソースの使用状況とコスト配分を取得できます。コストインサイトは、全体的なリソース使用率を向上させるためのコスト削減に関する提案も提供します。詳細については、「コストインサイト」をご参照ください。
GPU スケジューリングとメモリ分離を実装する方法の詳細については、「GPU 共有」をご参照ください。
仮想ノードのスケジューリングソリューションの詳細については、「仮想ノードにポッドをスケジュールする」をご参照ください。