2.8. Descheduler を使用した Pod のエビクト
スケジューラー は新規 Pod をホストするのに最適なノードを判別するために使用されますが 、Descheduler は実行中の Pod をエビクトするために使用され、Pod がより適したノードに再スケジュールされるようにできます。
descheduler はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。
Red Hat のテクノロジープレビュー機能のサポート範囲についての詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
2.8.1. Descheduler について
Descheduler を使用して Pod を特定のストラテジーに基づいてエビクトし、Pod がより適切なノードに再スケジュールされるようにできます。
以下のような状況では、実行中の Pod のスケジュールを解除することに利点があります。
- ノードの使用率が低くなっているか、使用率が高くなっている。
- テイントまたはラベルなどの、Pod およびノードアフィニティーの各種要件が変更され、当初のスケジュールの意思決定が特定のノードに適さなくなっている。
- ノードの障害により、Pod を移動する必要がある。
- 新規ノードがクラスターに追加されている。
- Pod が再起動された回数が多すぎる。
Descheduler はエビクトされた Pod の置き換えをスケジュールしません。スケジューラーは、エビクトされた Pod に対してこのタスクを自動的に実行します。
Descheduler がノードから Pod をエビクトすることを決定する際には、以下の一般的なメカニズムを使用します。
-
priorityClassName
がsystem-cluster-critical
またはsystem-node-critical
に設定されている Critical Pod はエビクトされることがありません。 - レプリケーションコントローラー、レプリカセット、デプロイメント、またはジョブの一部ではない静的な Pod、ミラーリングされた 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 を処理することでエビクトされます。
2.8.2. Descheduler ストラテジー
以下の Descheduler ストラテジーを利用できます。
- ノードの低い使用率
LowNodeUtilization
ストラテジーは、使用率の低いノードを検出し、可能な場合は他のノードから Pod をエビクトし、エビクトされた Pod の再作成がそれらの使用率の低いノードでスケジュールされるようにします。ノードの使用率の低さは、CPU、メモリーおよび Pod 数のいくつかの設定可能なしきい値パラメーターによって判別されます。ノードの使用率がすべてのパラメーター(CPU、メモリー、Pod の数)の設定済みのしきい値を下回る場合、ノードの使用率は低いとみなされます。
また、CPU、メモリー、Pod 数のターゲットしきい値を設定することもできます。ノードの使用量がいずれかのパラメーターに設定されたターゲットしきい値を上回る場合、ノードの Pod はエビクションについて考慮される可能性があります。
さらに、
NumberOfNodes
パラメーターを使用して、使用率の低いノードの数が設定された値を上回る場合にのみストラテジーをアクティブにするために設定できます。これは、いくつかのノードの使用率が頻繁に低くなったり、短期間低くなる可能性のある大規模なクラスターの場合に役立ちます。- 重複 Pod
RemoveDuplicates
ストラテジーでは、1 つの Pod のみが同じノードで実行されているレプリカセット、 レプリケーションコントローラー、デプロイメントまたはジョブに関連付けられます。追加の Pod がある場合、それらの重複 Pod はクラスターに Pod を効果的に分散できるようにエビクトされます。この状態は、Pod が別のノードに移動し、複数の Pod がそのノード上のレプリカセット、レプリケーションコントローラー、デプロイメント、またはジョブに関連付けられる際に生じる可能性があります。失敗したノードが再び準備可能になると、このストラテジーが重複 Pod をエビクトします。
- Pod 間の非アフィニティーの違反
RemovePodsViolatingInterPodAntiAffinity
ストラテジーは、Pod 間の非アフィニティー (inter-pod anti-affinity) に違反する Pod がノードから削除されるようにします。この状態は、同じノードですでに実行中の Pod に非アフィニティールールが作成されると発生する可能性があります。
- ノードアフィニティーの違反
RemovePodsViolatingNodeAffinity
ストラテジーにより、ノードアフィニティーを違反する Pod がノードから削除されるようにします。この状態は、ノードが Pod のアフィニティールールを満たさなくなる場合に生じる可能性があります。アフィニティールールを満たす別のノードが利用可能な場合、Pod はエビクトされます。
- ノードテイントの違反
RemovePodsViolatingNodeTaints
ストラテジーは、ノード上のNoSchedule
テイントを違反する Pod が削除されるようにします。これは、Pod がテイント
key=value:NoSchedule
を容認し、テイントされたノードで実行されている場合に生じる可能性があります。ノードのテイントが更新されるか、または削除される場合、テイントは Pod の容認によって満たされなくなり、Pod はエビクトされます。- 再起動の回数が多すぎる
RemovePodsHavingTooManyRestarts
ストラテジーは、再起動した回数が多すぎる Pod がノードから削除されるようにします。この状態は、Pod がこれを起動できないノードにスケジュールされている場合に生じる可能性があります。たとえば、ノードにネットワークの問題があり、ネットワーク化された永続ボリュームをマウントできない場合、Pod は別のノードでスケジュールされるようにエビクトされる必要があります。もう 1 つの例は、Pod がクラッシュループしている場合です。
このストラテジーには、
PodRestartThreshold
およびIncludingInitContainers
の 2 つの設定可能なパラメーターがあります。Pod が設定されたPodRestartThreshold
値を超えて再起動される場合、Pod はエビクトされます。IncludingInitContainers
パラメーターを使用して、Init コンテナーの再起動がPodRestartThreshold
値に計算されるかどうかを指定できます。
2.8.3. Descheduler のインストール
Descheduler はデフォルトで利用できません。Descheduler を有効にするには、Kube Descheduler Operator を OperatorHub からインストールする必要があります。Kube Descheduler Operator のインストール後に、エビクションストラテジーを設定できます。
前提条件
- クラスター管理者の権限。
- OpenShift Container Platform Web コンソールへのアクセス。
手順
- OpenShift Container Platform Web コンソールにログインします。
Kube Descheduler Operator に必要な namespace を作成します。
- Administration → Namespaces に移動し、Create Namespace をクリックします。
-
Name フィールドに
openshift-kube-descheduler-operator
を入力し、Create をクリックします。
Kube Descheduler Operator をインストールします。
- Operators → OperatorHub に移動します。
- Kube Descheduler Operator をフィルターボックスに入力します。
- Kube Descheduler Operator を選択し、Install をクリックします。
- Install Operator ページで、A specific namespace on the cluster を選択します。ドロップダウンメニューから openshift-kube-descheduler-operator を選択します。
- Update Channel および Approval Strategy の値を必要な値に調整します。
- Install をクリックします。
Descheduler インスタンスを作成します。
- Operators → Installed Operators ページから、 Kube Descheduler Operator をクリックします。
- Kube Descheduler タブを選択し、Create KubeDescheduler をクリックします。
- 必要に応じて設定を編集し、Create をクリックします。
Descheduler のストラテジーを設定できるようになりました。デフォルトで有効にされているストラテジーはありません。
2.8.4. Descheduler ストラテジーの設定
Descheduler が Pod のエビクトに使用するストラテジーを設定できます。
前提条件
- クラスター管理者の権限。
手順
KubeDescheduler
オブジェクトを編集します。$ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator
spec.strategies
セクションで 1 つ以上のストラテジーを指定します。apiVersion: operator.openshift.io/v1beta1 kind: KubeDescheduler metadata: name: cluster namespace: openshift-kube-descheduler-operator spec: deschedulingIntervalSeconds: 3600 strategies: - name: "LowNodeUtilization" 1 params: - name: "CPUThreshold" value: "10" - name: "MemoryThreshold" value: "20" - name: "PodsThreshold" value: "30" - name: "MemoryTargetThreshold" value: "40" - name: "CPUTargetThreshold" value: "50" - name: "PodsTargetThreshold" value: "60" - name: "NumberOfNodes" value: "3" - name: "RemoveDuplicates" 2 - name: "RemovePodsHavingTooManyRestarts" 3 params: - name: "PodRestartThreshold" value: "10" - name: "IncludingInitContainers" value: "false"
- 1
LowNodeUtilization
ストラテジーは、オプションで設定可能なCPUThreshold
およびMemoryThreshold
などの追加のパラメーターを提供します。- 2
RemoveDuplicates
、RemovePodsViolatingInterPodAntiAffinity
、RemovePodsViolatingNodeAffinity
、およびRemovePodsViolatingNodeTaints
ストラテジーには、設定する追加のパラメーターがありません。- 3
RemovePodsHavingTooManyRestarts
ストラテジーでは、PodRestartThreshold
パラメーターを設定する必要があります。また、オプションのIncludingInitContainers
パラメーターを指定します。
複数のストラテジーを有効にすることができ、ストラテジーを指定する順番は重要ではありません。
- 変更を適用するためにファイルを保存します。
2.8.5. 追加の Descheduler の設定
実行頻度など、Descheduler を追加で設定できます。
前提条件
- クラスター管理者の権限。
手順
KubeDescheduler
オブジェクトを編集します。$ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator
必要に応じて追加の設定を行います。
apiVersion: operator.openshift.io/v1beta1 kind: KubeDescheduler metadata: name: cluster namespace: openshift-kube-descheduler-operator spec: deschedulingIntervalSeconds: 3600 1 flags: - --dry-run 2 image: quay.io/openshift/origin-descheduler:4.5 3 ...
- 変更を適用するためにファイルを保存します。
2.8.6. Descheduler のアンインストール
Descheduler インスタンスを削除し、Kube Descheduler Operator をアンインストールして Descheduler をクラスターから削除できます。この手順では、KubeDescheduler
CRD および openshift-kube-descheduler-operator
namespace もクリーンアップします。
前提条件
- クラスター管理者の権限。
- OpenShift Container Platform Web コンソールへのアクセス。
手順
- OpenShift Container Platform Web コンソールにログインします。
Descheduler インスタンスを削除します。
- Operators → Installed Operators ページから、 Kube Descheduler Operator をクリックします。
- Kube Descheduler タブを選択します。
-
cluster クラスターの横にある Options メニュー
をクリックし、 Delete KubeDescheduler を選択します。
- 確認ダイアログで Delete をクリックします。
Kube Descheduler Operator をアンインストールします。
- Operators → Installed Operators に移動します。
-
Kube Descheduler Operator エントリーの横にある Options メニュー
をクリックし、Uninstall Operator を選択します。
- 確認ダイアログで、Uninstall をクリックします。
openshift-kube-descheduler-operator
namespace を削除します。- Administration → Namespaces に移動します。
-
openshift-kube-descheduler-operator
をフィルターボックスに入力します。 -
openshift-kube-descheduler-operator エントリーの横にある Options メニュー
をクリックし、Delete Namespace を選択します。
-
確認ダイアログで
openshift-kube-descheduler-operator
を入力し、Delete をクリックします。
KubeDescheduler
CRD を削除します。- Administration → Custom Resource Definitions に移動します。
-
KubeDescheduler
をフィルターボックスに入力します。 -
KubeDescheduler エントリーの横にある Options メニュー
をクリックし、Delete CustomResourceDefinition を選択します。
- 確認ダイアログで Delete をクリックします。