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-systemnamespace の 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: ノード上のNoScheduletaint に違反する 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 を追加する必要があります。