4.9. descheduler


4.9.1. descheduler の概要

スケジューラー は、新しい Pod をホストするのに最適なノードを決定するために使用されます。一方 descheduler は、実行中の Pod を退避させて、Pod をより適切なノードに再スケジュールできるようにするために使用できます。

4.9.1.1. descheduler について

デスケジューラーを使用すると、特定のストラテジーに基づいて Pod をエビクトし、より適切なノードに再スケジュールすることができます。

次のような状況では、実行中の Pod を再スケジュールするとメリットがあります。

  • ノードの使用率が低くなっているか、使用率が高くなっている。
  • taint またはラベルなどの、Pod およびノードアフィニティーの各種要件が変更され、当初のスケジュールの意思決定が特定のノードに適さなくなっている。
  • ノードの障害により、Pod を移動する必要がある。
  • 新規ノードがクラスターに追加されている。
  • Pod が再起動された回数が多すぎる。
重要

descheduler は退避された Pod の置き換えをスケジュールしません。スケジューラーは、退避された Pod に対してこのタスクを自動的に実行します。

descheduler がノードから Pod を退避することを決定する際には、以下の一般的なメカニズムを使用します。

  • openshift-* および kube-system namespace の Pod は退避されることがありません。
  • priorityClassNamesystem-cluster-critical または system-node-critical に設定されている Critical Pod は退避されることがありません。
  • レプリケーションコントローラー、レプリカセット、デプロイメント、ステートフルセット、またはジョブの一部ではない静的、ミラーリング、またはスタンドアロンの Pod は、再作成されないためエビクトされません。
  • デーモンセットに関連付けられた Pod は退避されることがありません。
  • ローカルストレージを持つ Pod は退避されることがありません。
  • Best effort Pod は、Burstable および Guaranteed Pod の前に退避されます。
  • descheduler.alpha.kubernetes.io/evict アノテーションを持つすべてのタイプの Pod はエビクションの対象になります。このアノテーションはエビクションを防ぐチェックをオーバーライドするために使用され、ユーザーはエビクトする Pod を選択できます。ユーザーは、Pod を再作成する方法と、Pod が再作成されるかどうかを認識している必要があります。
  • Pod の Disruption Budget (PDB) が適用される Pod は、スケジュール解除が PDB に違反する場合には退避されません。Pod は、エビクションサブリソースを使用して PDB を処理することでエビクトされます。

4.9.1.2. descheduler プロファイル

デスケジューラープロファイルを使用すると、Pod のライフサイクルやノードの使用率などの基準に基づいてクラスターのバランスを再調整する、特定のエビクションストラテジーを有効化できます。

以下の descheduler ストラテジーを利用できます。

AffinityAndTaints

このプロファイルは、Pod 間のアンチアフィニティー、ノードアフィニティー、およびノードの taint に違反する Pod を退避します。

これにより、以下のストラテジーが有効になります。

  • RemovePodsViolatingInterPodAntiAffinity: Pod 間のアンチアフィニティーに違反する Pod を削除します。
  • RemovePodsViolatingNodeAffinity: ノードのアフィニティーに違反する Pod を削除します。
  • RemovePodsViolatingNodeTaints: ノード上の NoSchedule taint に違反する Pod を削除します。

    ノードのアフィニティータイプが requiredDuringSchedulingIgnoredDuringExecution の Pod は削除されます。

TopologyAndDuplicates

このプロファイルは、ノード間で同様の Pod または同じトポロジードメインの Pod を均等に分散できるように Pod を退避します。

これにより、以下のストラテジーが有効になります。

  • RemovePodsViolatingTopologySpreadConstraint: 均等に分散されていないとポロジードメインを見つけ、DoNotSchedule 制約を違反している場合により大きなものから Pod の退避を試行します。
  • RemoveDuplicates: 1 つの Pod のみが同じノードで実行されているレプリカセット、レプリケーションコントローラー、デプロイメントまたはジョブに関連付けられます。追加の Pod がある場合、それらの重複 Pod はクラスターに Pod を効果的に分散できるようにエビクトされます。
LifecycleAndUtilization

このプロファイルは長時間実行される Pod を退避し、ノード間のリソース使用状況のバランスを取ります。

これにより、以下のストラテジーが有効になります。

  • RemovePodsHavingTooManyRestarts: コンテナーが何度も再起動された Pod を削除します。

    すべてのコンテナー (Init Container 含む) での再起動の合計が 100 を超える Pod。

  • LowNodeUtilization: 使用率の低いノードを検出し、可能な場合は過剰に使用されているノードから Pod を退避し、退避された Pod の再作成がそれらの使用率の低いノードでスケジュールされるようにします。

    ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) で 20% 未満の場合に使用率が低いと見なされます。

    ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) について 50% を超える場合に過剰に使用されていると見なされます。

  • PodLifeTime: 古くなり過ぎた Pod をエビクトします。

    デフォルトでは、24 時間以上経過した Pod は削除されます。Pod のライフタイム値をカスタマイズできます。

SoftTopologyAndDuplicates

このプロファイルは TopologyAndDuplicates と同じですが、whenUnsatisfiable: ScheduleAnyway などのソフトトポロジー制約のある Pod もエビクションの対象と見なされる点が異なります。

注記

SoftTopologyAndDuplicatesTopologyAndDuplicates の両方を有効にしないでください。両方を有効にすると、競合が生じます。

EvictPodsWithLocalStorage
このプロファイルにより、ローカルストレージを備えた Pod がエビクションの対象になります。
EvictPodsWithPVC
このプロファイルを使用すると、永続的なボリュームクレームを持つ Pod をエビクションの対象にすることができます。Kubernetes NFS Subdir External Provisioner を使用している場合は、プロビジョナーがインストールされている namespace に除外された namespace を追加する必要があります。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る