Kubernetes のスケジュール管理を 1 つの記事で学ぶ

基本的な紹介

日常業務では、すべての空港に航空機の着陸場所や駐機場所を管理するためのディスパッチルームがあります。 Kubernetes にも同様のスケジューラがあり、その主な機能は Pod を適切なノードにスケジュールすることです。

Kubernetes のスケジューラは kube-scheduler であり、ワークフローは次のとおりです。

クラスター内のすべてのノードの中で、スケジューリングアルゴリズムに従って Pod を実行できるすべてのノードを選択します。

前のステップに基づいて、選択されたノードはスケジューリングアルゴリズムに従ってスコア付けされ、最も高いスコアを持つノードがスケジューリング用に選択されます。

ポッドの spec.nodeName に、スケジュール結果のノード名を入力します。

概略図は以下のとおりです。

上の図からわかるように、Kubernetes のスケジューラの中核は 2 つの独立した制御ループです。 1. インフォーマーパス: 主な機能は、Etcd 内の Pod、Node、Service などのスケジューラ関連の API オブジェクトの変更を監視するためにインフォーマーを起動することです。 Pod が作成されると、Informer Handler を通じてスケジュールキューに配置されます。デフォルトでは、Kubernetes のスケジューリング戦略は優先キューであり、クラスター情報が変更されると、スケジューラはスケジューリングキューの内容に対していくつかの特別な操作も実行します。さらに、Kubernetes のデフォルトのスケジューラは、スケジューリングアルゴリズムの実行効率を向上させるために、スケジューラキャッシュを更新する役割も担っています。

2. Scheduler Parh の主なロジックは、キューから Pod を継続的に選択し、フィルタリングのために Predicate を呼び出して、ノードのセット (つまり、スケジューラキャッシュから取得される、Pod を実行できるすべてのノード情報) を取得することです。次に、Priorities を呼び出してフィルタリングされたノードにスコアを付け、スコアが最も高いノードがこのスケジュールに選択されます。スケジューリングが完了したら、スケジューラは Pod の spec.nodeName の値をスケジュールされたノードの名前に変更する必要があります。このステップはバインドと呼ばれます。

ただし、バインドフェーズでは、Kubernetes のデフォルトのスケジューラはスケジューラキャッシュ内の情報のみを更新します。楽観的な仮定に基づくこの API オブジェクト更新メソッドは、Assume と呼ばれます。 Assume 後、スケジューラは API サーバーにリクエストを送信して Pod を更新し、バインド操作を実際に完了させます。今回バインドが失敗した場合は、スケジューラキャッシュが更新された後、正常に戻ります。

Assume により、Pod がスケジュールを完了し、ノード上で実行する必要がある場合、kubelet は Admit 操作を実行して、Pod がノード上で実行できるかどうかを確認します。これは、kubelet の二次検証として機能します。

一般的な予算編成戦略には次のようなものがあります。

チェックノード条件
一般的な予測:

ホスト名、PodFitsHostPort、MatchNodeSelector、PodFitsResources

ディスク競合なし

優先権と先取権のメカニズム

通常、Pod のスケジュールに失敗した場合、Pod が更新されるかクラスターのステータスが変化するまで Pod は保留され、スケジューラによって Pod が再スケジュールされます。ただし、スケジュールが失敗したときに、優先度の高い Pod を棚上げにしたくない場合があります。代わりに、特定のノード上のいくつかの低優先度のポッドを削除して、高優先度のポッドが正常にスケジュールされるようにします。

Kubernetes の優先度は、ProrityClass によって次のように定義されます。

 apiバージョン:スケジューリング.k8s .io / v1
種類: PriorityClass
メタデータ:
 名前:高優先度
値: 1000000
グローバルデフォルト: false
説明: 「この優先度クラスは、優先度の高いサービス ポッドにのみ使用してください。」

値は優先度の値です。値が大きいほど優先度が高くなります。優先度は 32 ビットの整数で、最大値は 10 億以下です。 10 億を超える値は、システム Pod がプリエンプトされないようにするために、Kubernetes によってシステム Pod が使用するために予約されています。また、globalDefault の値が true に設定されている場合、この PriorityClass の値がシステムのデフォルト値になることを意味します。 false の場合、この PriorityClass を宣言する Pod のみがこの優先度を持ち、宣言されていない他の Pod の優先度は 0 になります。

次のようにポッドを定義し、優先順位を定義します。

 APIバージョン: v1
種類:ポッド
メタデータ:
 名前: nginx
 ラベル:
 環境:テスト
仕様:
 コンテナ:
 -名前: nginx
 画像: nginx
 imagePullPolicy : IfNotPresent
 priorityClassName :高優先度

上記の PriorityClassName は PriorityClass を定義します。この Pod が Kubernetes に送信されると、Kubernetes の PriorityAdmissionController は、この Pod の spec.priority フィールドを定義した値に自動的に設定します。このポッドにこの優先度が設定されている場合、優先度の高いポッドは優先度の低いポッドよりも先にキューから削除され、スケジュールができるだけ早く完了します。

優先度の高いポッドのスケジュールに失敗した場合、そのプリエンプションメカニズムがトリガーされます。このとき、スケジューラは現在のクラスター内でノードを見つけて、このノード上の 1 つ以上の低優先度 Pod を削除し、高優先度 Pod をこのノードにスケジュールできるようにします。プリエンプションが発生した場合、優先度の高いポッドはプリエンプトされるノードにすぐにはスケジュールされません。スケジューラは、Pod の spec.nominatedNodeName の値を、プリエンプトされたノードのノード名に設定するだけです。その後、ポッドは次のスケジューリングサイクルに再び入り、このサイクル内でポッドがどのノードにスケジュールされるかを決定します。この再スケジュール期間中に、より優先度の高い Pod もこのノードをプリエンプトしたい場合、スケジューラは元の Pod の nominatedNodeName の値をクリアし、より優先度の高い Pod がこの値をプリエンプトします。

実装原則: Kubernetes は、プリエンプションアルゴリズムを実装するために、ActiveQ と unschedulableQ の 2 つのキューを使用します。

ActiveQ: ActiveQ 内のすべてのポッドは、次のサイクルでスケジュールする必要があるオブジェクトです。したがって、Kubernetes が新しい Pod を作成すると、この Pod は ActiveQ に配置されます。
unschedulableQ: スケジュールに失敗した Pod を保存するために使用されます。

Pod のスケジュールに失敗した場合、スケジューラはそれを unschedulableQ に設定します。次に、スケジューラはスケジューリング失敗の原因をチェックし、プリエンプションを使用してスケジューリングの問題を解決できるかどうかを分析して確認します。プリエンプションが可能であると判断された場合、スケジューラはキャッシュされているすべての情報を再コピーし、このコピーを使用してプリエンプションプロセスをシミュレートします。シミュレーションが成功すると、スケジューラは実際に操作のプリエンプトを開始します。

スケジューラは被害者リストをチェックし、これらのポッドの nominatedNodeName フィールドをクリアします。
スケジューラは、プリエンプターの nominatedNodeName フィールドをプリエンプトされたノードの名前に設定します。
スケジューラは Goroutine を開始し、同期的に被害者を削除します。

次に、スケジューラは通常のスケジューリングプロセスを実行し、プリエンプターを正常にスケジュールします。このプロセス中、スケジューラはこのノードで述語アルゴリズムを 2 回実行します。

上記のプリエンプターがすでにこのノードで実行されていると仮定し、述語アルゴリズムを実行します。
スケジューラは Predicates アルゴリズムを通常どおり実行します。

上記の両方が合格した場合にのみ、ノードとポッドがバインドされます。

高度なスケジュール

上記は Kubernetes のデフォルトのスケジューリング戦略です。特定のノードにポッドをスケジュールしたり、特定のノードがポッドをスケジュールできないようにするなど、デフォルトのスケジューリング戦略ではニーズを満たせない場合があります。現時点では、主に次のような、より高度なスケジューリング戦略が必要です。

ノードセレクタ
ノード名
ノードアフィニティ
ポッドアフィニティ
ポッドアンチアフィニティ
汚染スケジュール

ノードセレクタ

NodeSelector はノードセレクターとも呼ばれます。その原理は、ノード上でラベルタグを定義し、ポッド内でこれらのラベルを指定して選択し、ポッドを指定されたノードにスケジュールできるようにすることです。

たとえば、kk-node01 の env=uat ラベルを指定するには、コマンドは次のようになります。

 $ kubectl ラベルノード kk - node01 env = uat

次に、Pod の YAML マニフェストで nodeSelector を次のように構成します。

 APIバージョン: v1
種類:ポッド
メタデータ:
 名前:ポッド-ノードセレクタ
仕様:
 コンテナ:
 -名前: myapp
 画像: ikubernetes / myapp : v1
 ノードセレクタ:
 環境: uat

このようにして、Pod は kk-node01 ノードにスケジュールされます。 Pod が env=prod として指定されている場合、kk-node01 ノードにはスケジュールされません。

ノード名

nodeName もノードセレクターです。 nodeSelector との違いは、nodeName がノード名を直接指定し、強調することです。定義は次のとおりです。

 APIバージョン: v1
種類:ポッド
メタデータ:
 名前:ポッド-ノード名
仕様:
 コンテナ:
 -名前: myapp
 画像: ikubernetes / myapp : v1
 nodeName : kk - node01 # ノード名

ノードアフィニティ

nodeAffinity はノードアフィニティスケジューリングと呼ばれ、nodeSelector や nodeName よりも強力です。

現在、nodeAffinity は次の 2 つのスケジューリング戦略をサポートしています。

優先スケジュール中は無視実行中は無視
スケジュール中は必須、実行中は無視

preferredDuringSchedulingIgnoredDuringExecution は、一致するノードがある場合、最初にそのノードにスケジュールされることを意味します。そうでない場合は、構成に応じて他のノードにスケジュールできます。 requiredDuringSchedulingIgnoredDuringExecution は、条件を満たすノードをスケジュールできることを意味します。

preferredDuringSchedulingIgnoredDuringExecution を定義する例は次のとおりです。

 APIバージョン: v1
種類:ポッド
メタデータ:
 名前:ポッド-ノードアフィニティ-推奨
仕様:
 コンテナ:
 -名前: myapp
 画像: ikubernetes / myapp : v1
 親和性:
 ノードアフィニティ:
 優先スケジュール中は無視実行中:
 -好み：
 一致する表現:
 -キー:ディスクタイプ
 演算子:
 値: [ "ssd" 、 "ハードディスク" ]
 重量: 60

requiredDuringSchedulingIgnoredDuringExecution の例は次のとおりです。

 APIバージョン: v1
種類:ポッド
メタデータ:
 名前:ポッド-ノードアフィニティ-必須
仕様:
 コンテナ:
 -名前: myapp
 画像: ikubernetes / myapp : v1
 親和性:
 ノードアフィニティ:
 スケジュール中に必須、実行中に無視:
 ノードセレクタ用語:
 -一致する表現:
 -キー:ディスクタイプ
 演算子:
 値: [ "ssd" 、 "ハードディスク" ]

このうち、演算子は In、NotIn、Exists、DoesNotExist をサポートします。 Gt、およびLt。

ポッドアフィニティ

上記の nodeSelector、nodeName、および nodeAffinity はすべてノード用ですが、下記の podAffinity および podAntiAffinity は Pod 用です。

podAffinity は Pod アフィニティスケジューリングを示します。これは、次のように、Pod をそれに近い Pod にスケジュールすることを意味します。

 APIバージョン: v1
種類:ポッド
メタデータ:
 名前:フロント
 ラベル:
 アプリ: myapp
 列:正面
仕様:
 コンテナ:
 -名前: myapp
 画像: ikubernetes / myapp : v1
 ---
 APIバージョン: v1
種類:ポッド
メタデータ:
 名前:バックエンド
 ラベル:
 アプリ: db
 行:バックエンド
仕様:
 コンテナ:
 -名前: db
 画像:ビジーボックス
 imagePullPolicy : IfNotPresent
 指示：
 - "/bin/sh"
 - 「-c」
 - 「睡眠3600」
 親和性:
 ポッドアフィニティ:
 スケジュール中に必須、実行中に無視:
 -ラベルセレクター:
 一致する表現:
 -キー:アプリ
 演算子:
 値: [ "myapp" ]
 トポロジキー: kubernetes .io /ホスト名

これは、バックエンドポッドとフロントエンドポッドを一緒にスケジュールすることを意味します。

podAffinity には、ハードアフィニティとソフトアフィニティである preferredDuringSchedulingIgnoredDuringExecution と requiredDuringSchedulingIgnoredDuringExecution もあります。使用方法は nodeAffinity と同じです。

ポッドアンチアフィニティ

ポッドの親和性については上記で紹介しました。ここで紹介する podAntiAffinity はポッドのアンチアフィニティであり、このようなポッドは一緒にスケジュールされないことを意味します。日常業務では、このような親和性は頻繁に使用されます。マイクロサービスには単一の Pod が存在することはほとんどなく、基本的に複数の Pod が存在します。アプリケーションの高可用性を向上させるために、同じアプリケーションの複数の Pod が同じマシンにスケジュールされることはありません。このとき、podAntiAffinity は次のように使用されます。

 apiバージョン:アプリ/ v1
種類:デプロイメント
メタデータ:
 名前: nginx
 ラベル:
 アプリ: nginx
仕様:
 レプリカ: 3
 セレクター:
 マッチラベル:
 アプリ: nginx
 テンプレート：
 メタデータ:
 ラベル:
 アプリ: nginx
 仕様:
 親和性:
 ポッドアンチアフィニティ:
 スケジュール中に必須、実行中に無視:
 -ラベルセレクター:
 一致する表現:
 -キー:アプリ
 演算子:
 値：
 - nginx
 トポロジキー: kubernetes .io /ホスト名
 コンテナ:
 -名前: nginx
 画像: nginx

汚染スケジュール

Kubernetes では、マスターノードなどの一部のノードに組み込みの taint があります。このようなノードでは、ポッドがテイントを許容するように構成されていない場合、これらのポッドはそのようなノードにスケジュールされません。

実際には、汚染スケジュールも非常に役立ちます。シナリオによっては、特定のノードが特定のプロジェクトグループのポッドのみを許可します。たとえば、ビッグデータプロジェクトは、他の通常のプロジェクトと混在させたくない高 IO プロジェクトです。しかし、ラベルセレクターを使用して他のプロジェクトを設定およびデプロイするのは面倒です。この場合、汚染セレクターを使用できます。

テイントに関連する構成情報は、kubectl explain node.spec.taints を通じて表示できます。

 $ kubectl ノード.spec .taintsを説明します
種類:ノード
バージョン: v1

リソース: taints < [ ]オブジェクト>

説明：
 指定されている場合、ノードの汚染。

  このTaintが添付されているノードは、
  汚染を容認しないでください。

 フィールド:
  effect <文字列> -必須-
  必須。汚染を許容しないポッドに対する汚染の影響。
  有効な効果は、NoSchedule、PreferNoSchedule、および NoExecute です。

  可能な列挙値:
  - `"NoExecute"` すでに実行中のポッドのうち、
  汚染。現在、NodeController によって強制されています。
  - `"NoSchedule"` ノードに新しいポッドをスケジュールすることを許可しない。
  彼らは汚染を許容しますが、Kubeletに送信されたすべてのポッドは
 スケジューラを経由して開始し、すでに実行中のすべてのポッドが
 走り続けます。スケジューラによって強制されます。
  - `"PreferNoSchedule"` TaintEffectNoScheduleと同様だが、スケジューラは
 新しいポッドを禁止するのではなく、ノードに新しいポッドをスケジュールしないようにする
 ノードへのスケジュール設定を完全に排除します。スケジューラによって強制されます。

  キー <文字列> -必須-
  必須。ノードに適用される汚染キー。

  追加された時間 <文字列>
  TimeAdded は、汚染が追加された時刻を表します。それはただ
 NoExecute 汚染のために書かれています。

  値 <文字列>
  汚染キーに対応する汚染値。

効果はポッドに対する除外効果を定義します。

NoSchedule: スケジュールプロセスにのみ影響し、既存の Pod には影響しません。
NoExecute: スケジュールに影響するだけでなく、既存の Pod にも影響します。許容されない Pod オブジェクトは削除されます。
PreferNoSchedule: Pod のスケジュールを完全に禁止するのではなく、ソフトに除外します。

ノードに汚染を追加する場合は、次のようにします。

 $ kubectl taint ノード kk - node01 ノードタイプ= dev : NoSchedule

キー名が node-type、キー値が dev、効果が NoSchedule であるノード kk-node01 にテイントを追加します。つまり、この汚染に一致する許容値を持つ Pod のみがノード kk-node01 に割り当てられます。

汚染を削除する場合は、次のコマンドを使用します。

 $ kubectl taint ノード kk - node01 ノード-タイプ= dev : NoSchedule -

許容汚染を設定する場合は、次のようにします。

 apiバージョン:アプリ/ v1
種類:デプロイメント
メタデータ:
 名前: nginx -デプロイメント
 ラベル:
 アプリ: nginx
仕様:
 レプリカ： 2
 セレクター:
 マッチラベル:
 アプリ: nginx
 テンプレート：
 メタデータ:
 ラベル:
 アプリ: nginx
 仕様:
 コンテナ:
 -名前: nginx
 イメージ: nginx : 1.7.9
 imagePullPolicy : IfNotPresent
 ポート:
 -コンテナポート: 80
 許容範囲:
 -キー: "ノードタイプ"
 演算子:等しい
 値: dev
 効果:スケジュールなし
 許容秒数: 20

演算子は Equal と Exists をサポートし、デフォルトは Equal です。

等しい場合は、汚染のキー値が一貫している必要があることを意味します。 Exists が使用されている場合、キーの汚染が存在する限り、次のようになります。

許容範囲:
 -キー: "key1"
 演算子: "存在する"
 効果: "NoSchedule"

この構成は、許容値が一致し、key1 のキーが存在する限り、スケジューリングを実行できることを意味します。

許容値のキーが空で、演算子が Exists である場合、この許容値は任意のキー、値、および効果と一致することを意味します。つまり、この許容値は任意の汚れを許容できます。効果が空の場合、キー名が key1 のすべての効果が一致します。

ノードに複数のテイントを追加したり、ポッドに複数の許容設定を追加したりできます。 Kubernetes は、複数の taint と toleration をフィルターのように処理します。つまり、ノード上のすべての taint から開始し、Pod 内で一致する toleration を持つ taint を除外します。残りのフィルタリングされていないテイントの効果値によって、特に次の状況で、ポッドがノードに割り当てられるかどうかが決まります。

無視されないテイントの中に、効果値が NoSchedule のテイントが少なくとも 1 つある場合、Kubernetes は Pod をノードにスケジュールしません。
無視されないテイントの中に効果値が NoSchedule のテイントが存在しないが、効果値が PreferNoSchedule のテイントが存在する場合、Kubernetes は Pod をノードにスケジュールしないようにします。
無視されないテイントの中に、効果値が NoExecute のテイントが少なくとも 1 つある場合、Kubernetes は Pod をノードにスケジュールしません (Pod がノード上でまだ実行されていない場合)。または、Pod をノードから削除します (Pod がノード上ですでに実行されている場合)。

例えば、ノードに次の汚染を追加するとします。

 $ kubectl taint ノード node1 key1 = value1 : NoSchedule
 $ kubectl taint ノード node1 key1 = value1 : NoExecute
 $ kubectl taint ノード ノード1 キー2 =値2 : NoSchedule

2 つの許容値を持つ Pod があると仮定します。

許容範囲:
 -キー: "key1"
 演算子: "等しい"
 値: "値1"
 効果: "NoSchedule"
 -キー: "key1"
 演算子: "等しい"
 値: "値1"
 効果: "NoExecute"

この場合、3 番目の汚染に一致する許容範囲がないため、ポッドはノード上でスケジュールされません。ただし、上記のテイントがノードに追加される前に Pod がすでにノード上で実行されている場合、3 番目のテイントは、この Pod が許容できない 3 つのテイントのうちの 1 つだけであるため、ノード上で引き続き実行できます。

通常、効果値が NoExecute の汚染がノードに追加されると、この汚染を許容できない Pod は直ちに排除され、この汚染を許容できる Pod は排除されません。ただし、Pod の効果値が NoExecute で、オプション属性 toleranceSeconds の値を指定する許容値がある場合、上記の汚染がノードに追加された後、Pod がノード上で実行を継続できる期間を示します。例えば：

許容範囲:
 -キー: "key1"
 演算子: "等しい"
 値: "値1"
 効果: "NoExecute"
 許容秒数: 3600

つまり、このポッドが実行中で、それが存在するノードに一致するテイントが追加された場合、ポッドは削除されるまで 3600 秒間ノード上で実行され続けます。それまでに上記の汚染が除去された場合、ポッドは排除されません。

スケジュール変更

Kubernetes では、kube-scheduler が適切なノードにポッドをスケジュールする役割を担います。ただし、Kubernetes は非常に動的で弾力性の高い環境であるため、1 つ以上のノードで Pod が不均等に分散されることがあります。例えば：

一部のノードは十分に活用されていないか、過度に使用されている
ラベルやテイントを追加または削除したり、ポッドやノードのアフィニティを変更したりすると、元のスケジュールが満たされなくなる可能性があります。
一部のノードに障害が発生し、そのノードで実行されているポッドが他のノードにスケジュールされる
新しいノードがクラスターに参加する

上記の理由により、複数のポッドが理想的とは言えないノードで実行される可能性があり、K8S クラスター全体が一定期間、不均衡な状態になります。この時点で、クラスターを再バランスする必要があります。 Descheduler はそのようなプロジェクトです。

Descheduler は、いくつかのルール構成に従ってクラスターのステータスを再調整できます。現在サポートされている戦略は次のとおりです。

重複を削除
低ノード使用率
ポッドの削除、ポッド間の反アフィニティ違反
ノードアフィニティに違反しているポッドを削除します
ポッド違反ノードテイントの削除
トポロジー拡散制約に違反しているポッドを削除します
再起動が多すぎるポッドを削除する
ポッドライフタイム

これらのポリシーは有効または無効にすることができ、デフォルトではすべてのポリシーが有効になっています。

さらに、次のような一般的な構成がいくつかあります。

nodeSelector: 処理するノードを制限する
evictLocalStoragePods: LocalStorage を使用して Pod を削除する
ignorePvcPods: PVCで設定されたPodを無視するかどうか。デフォルトはFalseです。
maxNoOfPodsToEvictPerNode: ノードによって排除されるポッドの最大数

クラスターのバージョンは 1.24.2 なので、descheduler v0.24 をインストールしました。

（1）対応するHelmチャートをダウンロードします。バージョン0.24を選択しました。

 $ wget https://github.com/kubernetes-sigs/descheduler/releases/download/descheduler-helm-chart-0.24.0/descheduler-0.24.0.tgz

（２）科学的にインターネットにアクセスできる場合は、以下のコマンドを直接使用して展開することができます。

 descheduler をインストールします。

科学的にインターネットにアクセスできない場合は、イメージを置き換え、value.yaml のイメージ情報を次のように変更します。

画像：
 リポジトリ: registry .cn - hangzhou .aliyuncs .com / coolops / descheduler
 # デフォルトがチャートバージョンである画像タグを上書きします
 タグ: "v0.24.0"
 プルポリシー: IfNotPresent

次にインストールコマンドを実行します。

インストールが完了すると、デフォルトのスケジュール戦略は次のように構成されます。

 APIバージョン: v1
データ：
 ポリシー.yaml : |
 apiVersion : "descheduler/v1alpha1"
 種類: "DeschedulerPolicy"
 戦略:
 低ノード使用率:
 有効: true
 パラメータ:
 ノードリソース使用率しきい値:
 ターゲットしきい値:
 CPU : 50
 メモリ: 50
 ポッド： 50
 閾値:
 CPU : 20
 メモリ: 20
 ポッド： 20
 重複を削除:
 有効: true
 ポッド間のアンチアフィニティに違反しているポッドを削除します:
 有効: true
 ポッド違反ノードアフィニティを削除します:
 有効: true
 パラメータ:
 ノードアフィニティタイプ:
 -スケジュール中は必須、実行中は無視
 ポッド違反ノードテイントを削除します:
 有効: true
種類: ConfigMap
メタデータ:
 注釈:
 meta .helm .sh / release -名前: descheduler
 meta .helm .sh / release -名前空間:デフォルト
 作成タイムスタンプ: "2022-08-02T03:06:57Z"
 ラベル:
 アプリ.kubernetes .io /インスタンス:デスケジューラ
 app .kubernetes .io / 管理元: Helm
 app .kubernetes .io /名前: descheduler
 アプリ.kubernetes .io /バージョン: 0.24 .0
 helm .sh /チャート: デスケジューラー- 0.24.0
 名前:デスケジューラ
 名前空間:デフォルト
 リソースバージョン: "894636"
 uid : 4ab2e628-9404-4e52 - bd88-615f5e096d90

構成:

LowNodeUtilization: cpu\memory\pod の水位を設定します。しきい値は使用率が低いことを示し、targetThresholds は使用率が高すぎることを示します。
RemoveDuplicates: 同じノードで実行されているポッドを 1 つだけ有効にする
RemovePodsViolatingInterPodAntiAffinity: アフィニティに違反するポッドを削除します
RemovePodsViolatingNodeAffinity: ノードアフィニティを満たさないポッドを削除する
RemovePodsViolatingNodeTaints: Node taints によって許容されない Pod を削除します

定期的にスケジュールのバランスをとるための CronJob も作成されます。

 apiバージョン:バッチ/ v1
種類: CronJob
メタデータ:
 注釈:
 meta .helm .sh / release -名前: descheduler
 meta .helm .sh / release -名前空間:デフォルト
 作成タイムスタンプ: "2022-08-02T03:06:57Z"
 世代: 1
 ラベル:
 アプリ.kubernetes .io /インスタンス:デスケジューラ
 app .kubernetes .io / 管理元: Helm
 app .kubernetes .io /名前: descheduler
 アプリ.kubernetes .io /バージョン: 0.24 .0
 helm .sh /チャート: デスケジューラー- 0.24.0
 名前:デスケジューラ
 名前空間:デフォルト
 リソースバージョン: "898221"
 uid : e209e498-71cb - 413f - 97a9-372aea5442bc
仕様:
 同時実行ポリシー:禁止
 失敗したジョブ履歴制限: 1
 ジョブテンプレート:
 メタデータ:
 作成タイムスタンプ: null
 仕様:
 テンプレート：
 メタデータ:
 注釈:
 チェックサム/設定: 5efec14c3638fa4028e25f3fa067758f13dcae442fe711439c7d0b2e9913d41e
 作成タイムスタンプ: null
 ラベル:
 アプリ.kubernetes .io /インスタンス:デスケジューラ
 app .kubernetes .io /名前: descheduler
 名前:デスケジューラ
 仕様:
 コンテナ:
 -引数:
 - --ポリシー設定ファイル
- /ポリシー- dir / policy.yaml
 - --v
 - 「3」
 指示：
 - / bin /デスケジューラ
 イメージ: registry .cn - hangzhou .aliyuncs .com / coolops / descheduler : v0 .24 .0
 imagePullPolicy : IfNotPresent
 ライブネスプローブ:
 失敗しきい値: 3
 httpGet :取得:
 パス: / healthz
 ポート: 10258
 スキーム: HTTPS
 初期遅延秒数: 3
 期間秒数: 10
 成功しきい値: 1
 タイムアウト秒数: 1
 名前:デスケジューラ
 リソース：
 リクエスト:
 CPU : 500m
 メモリ: 256 Mi
 セキュリティコンテキスト:
 権限昇格を許可: false
 機能:
 落とす：
 -全て
 特権： 偽
 readOnlyRootFilesystem : true
 実行時にルートとして実行: true
 終了メッセージパス: / dev /終了-ログ
 終了メッセージポリシー:ファイル
 ボリュームマウント:
 -mountPath : /ポリシー- dir
 名前:ポリシー-ボリューム
 dnsポリシー: ClusterFirst
 priorityClassName :システム-クラスター-クリティカル
 再起動ポリシー:なし
 schedulerName :デフォルト-スケジューラ
 セキュリティコンテキスト: { }
 サービス アカウント:スケジュール解除
 serviceAccountName :スケジューラ解除
 終了猶予期間秒数: 30
 巻数:
 -構成マップ:
 デフォルトモード: 420
 名前:デスケジューラ
 名前:ポリシー-ボリューム
 スケジュール: '*/2 * * * *'
 成功したジョブ履歴制限: 3
 一時停止: false
状態：
 lastScheduleTime : "2022-08-02T03:28:00Z"
 最終成功時間: "2022-08-02T03:28:03Z"