サポートコンソール開発者トライアルの開始お問い合わせ

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 は退避されることがありません。
  • priorityClassName が system-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 もエビクションの対象と見なされる点が異なります。

注記

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

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

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る