ACK クラスターがサポートするスケジューリングポリシー - Container Service for Kubernetes

事前準備

役割とビジネスシナリオに基づいてスケジューリングポリシーを選択してください。
- 運用保守エンジニアは、クラスターコストとリソース使用率の最大化、クラスターの高可用性の確保、ノード負荷の分散、単一障害点の回避に重点を置きます。
- アプリケーション開発者は、アプリケーションのシンプルなデプロイと管理、およびアプリケーションのパフォーマンスを確保するための、CPU、GPU、メモリなどの十分なリソースを必要とします。
ACK のスケジューリングポリシーを効果的に使用するには、Kubernetes スケジューラ、ノードラベル、ノードプレッシャーエビクション、Pod トポロジー分布制約について学習してください。

ACK スケジューラは、フィルターおよびスコアプラグインで構成される、オープンソースの Kubernetes スケジューラと同じデフォルトポリシーを使用します。

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

Kubernetes ネイティブのスケジューリングポリシーは、ノードスケジューリングと Pod 間スケジューリングの 2 つのカテゴリに分類されます。

ノードスケジューリングポリシー：特定の特性とリソース条件に一致するノードに Pod をスケジュールします。
Pod 間スケジューリングポリシー：デプロイを最適化し、アプリケーションの高可用性を確保するために Pod の分散を制御します。

ポリシー	説明	シナリオ
nodeSelector	ノードにキーと値のペアのラベルを付け、`nodeSelector` を使用して一致するノードに Pod をスケジュールします。例：特定のノードに Pod をスケジュールまたは特定のノードプールに Pod をスケジュール。	基本的なノード選択方法であり、ソフトスケジューリングルールなどのより複雑なスケジューリング機能はサポートしていません。
nodeAffinity	`requiredDuringSchedulingIgnoredDuringExecution` ハードスケジューリングルールと `preferredDuringSchedulingIgnoredDuringExecution` ソフトスケジューリングルールがあります。	リージョン、デバイスタイプ、ハードウェアなどの特定の特性を持つノードに Pod をスケジュールします。アンチアフィニティルールは、Pod をノード全体に分散させます。
Taint と Toleration	`Taint` は、キー、値、および効果 (一般的な効果：`NoSchedule`、`PreferNoSchedule`、`NoExecute`) で構成されます。一致する `Toleration` を持つ Pod のみが、`Taint` が設定されたノードにスケジュールされます。	AI や ML ワークロード用の GPU 搭載ノードなど、特定のアプリケーション専用のノードリソースを予約します。ノードプールに Taint またはラベルを追加して、アプリケーション Pod を特定のプールにスケジュールします。詳細については、「ノードプールの作成と管理」および「ノードプールの変更」をご参照ください。 `Taint` と `Toleration` に基づいて Pod を退去させます。たとえば、異常なノードに `Taint` を追加し、効果を `NoExecute` に設定します。
Pod 間アフィニティ/アンチアフィニティ	Pod のラベルが、Pod からノードへのスケジューリングを決定します。`requiredDuringSchedulingIgnoredDuringExecution` (ハードルール) と `preferredDuringSchedulingIgnoredDuringExecution` (ソフトルール) をサポートします。	ネットワーク遅延を削減するために、連携する Pod を同じまたは隣接するノードに配置します。重要なアプリケーション Pod を異なるノードまたは障害ドメインに分散させます。

ACK スケジューリングポリシー

ACK は、逆順スケールインを伴う順序付きスケールアウトや、ノードの実際のリソース使用状況に基づく負荷認識スケジューリングなどの要件に対応するため、Kubernetes のスケジューリング機能を拡張しています。

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

対象ロール：クラスター運用保守エンジニア。
説明：Elastic Compute Service (ECS) インスタンスや Elastic Container Instance などの混合インスタンスタイプ、およびサブスクリプション、従量課金、プリエンプティブルインスタンスなどの課金方法を使用するクラスターの場合、優先度ベースのリソーススケジューリングを設定して、Pod スケジューリングのノード選択順序を定義し、スケールイン時にはその逆順にします。

ポリシー

説明

シナリオ

参照

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

リリースまたはスケーリング時にカスタム ResourcePolicy 値を指定して、ノードリソースの選択順序を定義します。たとえば、サブスクリプション ECS インスタンス、従量課金 ECS インスタンス、Elastic Container Instance の順に優先します。

スケールインではこの順序が逆になり、Elastic Container Instance、従量課金 ECS インスタンス、サブスクリプション ECS インスタンスの順になります。

クラスターリソース使用率のバランスをとるために、優先または回避するノードを定義します。
高性能アプリケーション Pod は、高性能ノードに優先的にスケジュールされます。
パフォーマンスが重要でない Pod は、プリエンプティブルインスタンスまたはアイドルリソースのあるノードに優先的にスケジュールされ、コストを削減します。

エラスティックリソースのカスタム優先度スケジューリング

ジョブスケジューリング

対象ロール：クラスター運用保守エンジニア。
説明：デフォルトのスケジューラは、バッチジョブのスケジューリングには適していません。ACK は、バッチジョブ用のギャングスケジューリングとキャパシティスケジューリングをサポートしています。

ポリシー	説明	シナリオ	参照
ギャングスケジューリング	関連するすべての Pod が一緒にスケジュールされるか、まったくスケジュールされないかのいずれかであり、異常なプロセスがグループをブロックするのを防ぎます。	バッチジョブ：ジョブに複数の相互依存タスクが含まれており、同時に処理する必要があります。分散コンピューティング：機械学習のトレーニングジョブや、同時に実行する必要があるその他の分散アプリケーション。高性能コンピューティング：ジョブの実行前に、すべてのリソースを同時に利用可能にする必要がある場合があります。	ギャングスケジューリングの使用
キャパシティスケジューリング	特定の Namespace またはユーザーグループのリソースを予約し、クラスターリソースが限られている場合にリソース共有によって使用率を向上させます。	マルチテナントクラスターでは、リソースのライフサイクルと使用パターンが多様であるため、使用率が低くなります。リソースの共有と回収により、全体的な使用率が向上します。	キャパシティスケジューリングの使用

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

対象ロール：クラスター運用保守エンジニア。
説明：機械学習とビッグデータのワークロードには、Pod 間の集中的な通信が必要ですが、デフォルトのスケジューラは Pod をクラスター全体に均等に分散させるため、ジョブの完了時間が延長されます。ネイティブのアフィニティメカニズムでは、複数のトポロジードメインにわたって再試行できません。

説明

シナリオ

参照

スケジューラは、ギャングスケジューリングラベルを使用して、すべての Pod リソース要求が同時に満たされることを保証します。トポロジー対応スケジューリングは、トポロジードメインを反復処理して、すべての Pod 要件を満たすドメインを見つけます。

ノードプールを配置セットに関連付けて、同じ低遅延の配置セット内の ECS インスタンスに Pod をスケジュールし、ジョブのパフォーマンスを向上させます。

機械学習またはビッグデータジョブでは、Pod は頻繁に通信する必要があります。スケジューラは、トポロジードメインを反復処理して、すべての Pod 要件を満たすドメインを見つけ、ジョブ完了時間を短縮します。

負荷認識スケジューリング

対象ロール：クラスター運用保守エンジニアおよびアプリケーション開発者。
説明：ネイティブのスケジューラは、実際の使用状況ではなくリソース割り当てに基づいて Pod を割り当てます。ノード負荷はトラフィックとワークロードによって動的に変化するため、ネイティブのスケジューラはリアルタイムのリソース負荷を検出できません。

説明	シナリオ	参照
ACK スケジューラは、ノード負荷履歴を監視し、新しい Pod のリソース使用量を推定して、低負荷ノードに Pod をスケジュールし、過負荷に起因するクラッシュを防ぎます。	負荷、アクセス遅延、またはリソース QoS に敏感なアプリケーション。	負荷認識スケジューリングの使用

ノード負荷の不均衡を防ぐには、「負荷認識ホットスポットデスケジューリングの使用」をご参照ください。

QoS 対応スケジューリング

対象ロール：クラスター運用保守エンジニアおよびアプリケーション開発者。
説明：Kubernetes QoS クラス (Guaranteed、Burstable、BestEffort) は、ノードリソースが不足している場合の Pod 退去の優先順位を決定します。ACK は、SLO 対応スケジューリングを追加して、低優先度ジョブのリソースアクセスを確保しながら、レイテンシーに敏感なアプリケーションのパフォーマンスを向上させます。

ポリシー	説明	シナリオ	参照
CPU Burst	OS は、サイクル内でコンテナの CPU 使用量をスロットリングする場合があります (CPU スロットリング)。CPU Burst により、アイドル状態のコンテナは CPU タイムスライスを蓄積し、需要が急増したときに CPU 制限を超えてバーストでき、パフォーマンスが向上し、遅延が削減されます。	起動時とロード時に高い CPU を消費しますが、その後は通常の CPU を必要とするコンテナ。 e コマース、ゲーム、その他の Web サービスなど、CPU の急激なスパイクがあり、トラフィックの急増に迅速に対応する必要があるアプリケーション。	CPU Burst パフォーマンス最適化ポリシーの有効化
トポロジー対応 CPU スケジューリング	CPU に敏感な Pod を特定の CPU コアにピン留めして、頻繁なコンテキストスイッチやクロス NUMA メモリアクセスによるパフォーマンス低下を回避します。	クラウドネイティブ環境に適応していないアプリケーション。たとえば、コンテナ仕様ではなく物理コアに基づくスレッド数により、パフォーマンスが低下します。 Intel または AMD CPU を搭載したマルチコアの ECS Bare Metal インスタンス上のアプリケーションでは、クロス NUMA メモリアクセスによるパフォーマンス低下が発生します。 CPU コンテキストスイッチに非常に敏感で、パフォーマンスの変動を許容できないアプリケーション。	CPU トポロジー対応スケジューリングの有効化
トポロジー対応 GPU スケジューリング	複数の GPU 集約型 Pod が同時に実行されると、GPU リソースを奪い合い、GPU または NUMA ノード間で切り替わり、パフォーマンスが低下する可能性があります。トポロジー対応 GPU スケジューリングは、ワークロードを特定の GPU に割り当て、クロス NUMA メモリアクセスを削減し、パフォーマンスを向上させます。	高性能コンピューティングなど、効率的なデータ転送を必要とする大規模分散コンピューティング。広範な GPU リソースを必要とし、トレーニングジョブを GPU 全体に適切に割り当てる必要がある機械学習とディープラーニングワークロード。レンダリングジョブを GPU 全体に効率的に割り当てる必要があるグラフィックスレンダリングとゲーム開発。	GPU トポロジー対応スケジューリング NUMA トポロジー対応スケジューリングの有効化
動的リソースオーバーコミット	Pod に割り当てられているが使用されていないリソースを回収し、低優先度のジョブに割り当てることでオーバーコミットします。アプリケーションが互いに影響を与えないように、次の単一ノード QoS ポリシーを併用します。 CPU Suppress：ノード全体の使用量がしきい値を超過した場合、低優先度 Pod が使用できる CPU リソースを制限し、コンテナの安定性を確保します。 CPU QoS：高優先度アプリケーションに十分な CPU 割り当てを確保します。 Memory QoS：高優先度アプリケーションに十分なメモリ割り当てを確保し、メモリ回収を遅延させます。 L3 キャッシュとメモリ帯域幅割り当て (MBA) に基づくリソース分離：高優先度アプリケーションに L3 キャッシュと MBA を優先します。	コロケーションによりクラスターのリソース使用率を向上させます。典型的なシナリオには、ML モデルのトレーニングと推論、ビッグデータのバッチ処理と分析、オンラインサービス、オフラインバックアップなどがあります。	動的リソースオーバーコミットの有効化 CPU Suppress の有効化コンテナの CPU QoS の有効化 Memory QoS L3 キャッシュと MBA に基づくリソース分離の有効化コロケーションのベストプラクティス
Pod のリソースパラメータの動的変更	Kubernetes 1.27 以前では、コンテナパラメータを変更するには、Pod を削除して再作成する必要があります。ACK では、Pod を再起動せずに CPU、メモリ、ディスクの IOPS 制限を変更できます。	一時的な CPU またはメモリリソースの調整。	Pod リソースパラメータの動的変更

デスケジューリング

対象ロール：クラスター運用保守エンジニアおよびアプリケーション開発者。
説明：クラスターの状態が変化すると、実行中の Pod をより適切なノードに移行する必要がある場合があります。

ポリシー	説明	シナリオ	参照
デスケジューリング	リソース使用量の不均衡やノード属性の変更によりホットスポットが形成された場合、不適切に配置された Pod を最適なノードに再スケジュールし、ワークロードの高可用性と効率を確保します。	ワークロード分散の不均衡によるノードの過負荷 (コロケーションシナリオなど)。クラスターのリソース使用率が低く、コスト削減のためにノードの削除が必要になる状況。リソースの断片化により、クラスター全体では十分な容量があるにもかかわらず、個々のノードに十分なリソースがない状態。ノードへの Taint またはラベルの追加や削除。	デスケジューリングデスケジューリング機能の有効化
負荷認識ホットスポットデスケジューリングの使用	負荷認識スケジューリングとホットスポットデスケジューリングを組み合わせて、ノード負荷を監視し、負荷しきい値を超えたノードを自動的に再バランスします。		負荷認識ホットスポットデスケジューリング

課金

ACK スケジューリングでは、課金ルールに基づいて、クラスター管理とクラウドリソースの料金が発生します。追加のスケジューリングコンポーネントに関する料金は次のとおりです。

デフォルトの ACK スケジューラ (kube-scheduler) は、インストールも使用も無料です。
ACK のリソーススケジューリングとデスケジューリングは、ack-koordinator に基づいています。ack-koordinator は、インストールも使用も無料ですが、特定のシナリオでは追加料金が発生する場合があります。詳細については、「ack-koordinator (旧 ack-slo-manager)」をご参照ください。

よくある質問

スケジューリングに関する問題については、「スケジューリングに関する FAQ」をご参照ください。

Container Service for Kubernetes:スケジューリングの概要