16.3. 再スケジュール (Descheduling)
16.3.1. 概要
再スケジュール (Descheduling) には、Pod がより適切なノードに再スケジュールされるように 特定のポリシー に基づいて Pod をエビクトすることが関係しています。
クラスターは、さまざまな理由で、すでに実行中の Pod のスケジュールを解除および再スケジュールすることで恩恵を受けることができます。
- ノードの使用率が低くなっているか、または高くなっている。
- テイントまたはラベルなどの、Pod およびノードアフィニティーの各種要件が変更され、当初のスケジューリングの意思決定が特定のノードに適さなくなっている。
- ノードの障害により、Pod を移動する必要がある。
- 新規ノードがクラスターに追加されている。
Descheduler はエビクトされた Pod の置き換えをスケジュールしません。スケジューラー は、エビクトされた Pod に対してこのタスクを自動的に実行します。
DNS など、クラスターの完全な機能に欠かせないコアコンポーネントであるものの、マスターではなく通常のクラスターノードで実行されるコアコンポーネントが多数あることに留意する必要があります。クラスターはコンポーネントがエビクトされると正常な機能を停止する可能性があります。Descheduler がこれらの Pod を削除することを防ぐには、 scheduler.alpha.kubernetes.io/critical-pod アノテーションを Pod 仕様に追加して、Pod を Critical Pod として設定します。
Descheduler ジョブは Critical Pod としてみなされ、これは Descheduler Pod が Descheduler のエビクトの対象になることを防ぎます。
Descheduler ジョブおよび Descheduler Pod は、デフォルトで作成される kube-system プロジェクトに作成されます。
descheduler はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。
Descheduler は以下のタイプの Pod をエビクトしません。
-
Critical Pod (
scheduler.alpha.kubernetes.io/critical-podアノテーションを持つ)。 - レプリカセット、レプリケーションコントローラー、デプロイメント、またはジョブに関連付けられていない Pod (静的およびミラー Pod またはスタンドアロンモードの Pod) (これらの Pod 再作成されないため)。
- DaemonSet に関連付けられた Pod。
- ローカルストレージを持つ Pod。
- Pod の Disruption Budget (PDB) が適用される Pod は、スケジュール解除が PDB に違反する場合にエビクトされません。Pod は、エビクションポリシー を使用してエビクトできます。
Best Effort Pod は、Burstable および Guaranteed Pod の前にエビクトされます。
以下のセクションでは、Descheduler を設定し、実行するプロセスについて説明します。
- ロールを作成します。
- ポリシーファイル にスケジュール解除動作を定義します。
- ポリシーファイルを参照するための参照マップ を作成します。
- Descheduler ジョブ設定 を作成します。
- Descheduler ジョブを実行します。
