3.2.3. スケジューラーポリシーの変更

openshift-config プロジェクトでスケジューラーポリシーの設定マップを作成または編集して、スケジューリング動作を変更します。scheduler policy を作成するには、述語と優先順位の追加および削除を設定マップに対して実行します。

手順

現在のカスタムスケジュールを変更するには、以下のいずれかの方法を使用します。

  • スケジューラーポリシーの設定マップを編集します。

    $ oc edit configmap <configmap-name>  -n openshift-config

    以下に例を示します。

    $ oc edit configmap scheduler-policy -n openshift-config

    出力例

    apiVersion: v1
    data:
      policy.cfg: |
        {
            "kind" : "Policy",
            "apiVersion" : "v1",
            "predicates" : [ 1
                    {"name" : "MaxGCEPDVolumeCount"},
                    {"name" : "GeneralPredicates"},
                    {"name" : "MaxAzureDiskVolumeCount"},
                    {"name" : "MaxCSIVolumeCountPred"},
                    {"name" : "CheckVolumeBinding"},
                    {"name" : "MaxEBSVolumeCount"},
                    {"name" : "MatchInterPodAffinity"},
                    {"name" : "CheckNodeUnschedulable"},
                    {"name" : "NoDiskConflict"},
                    {"name" : "NoVolumeZoneConflict"},
                    {"name" : "PodToleratesNodeTaints"}
                    ],
            "priorities" : [ 2
                    {"name" : "LeastRequestedPriority", "weight" : 1},
                    {"name" : "BalancedResourceAllocation", "weight" : 1},
                    {"name" : "ServiceSpreadingPriority", "weight" : 1},
                    {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
                    {"name" : "NodeAffinityPriority", "weight" : 1},
                    {"name" : "TaintTolerationPriority", "weight" : 1},
                    {"name" : "ImageLocalityPriority", "weight" : 1},
                    {"name" : "SelectorSpreadPriority", "weight" : 1},
                    {"name" : "InterPodAffinityPriority", "weight" : 1},
                    {"name" : "EqualPriority", "weight" : 1}
                    ]
        }
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-09-17T17:44:19Z"
      name: scheduler-policy
      namespace: openshift-config
      resourceVersion: "15370"
      selfLink: /api/v1/namespaces/openshift-config/configmaps/scheduler-policy

    1
    必要に応じて述語を追加または削除します。
    2
    必要に応じて述語の重みを追加、削除、または変更します。

    スケジューラーが更新されたポリシーで Pod を再起動するまでに数分の時間がかかる場合があります。

  • 使用されるポリシーと述語を変更します。

    1. スケジューラーポリシーの設定マップを削除します。

      $ oc delete configmap -n openshift-config <name>

      以下に例を示します。

      $ oc delete configmap -n openshift-config  scheduler-policy
    2. policy.cfg ファイルを編集し、必要に応じてポリシーおよび述語を追加し、削除します。

      以下に例を示します。

      $ vi policy.cfg

      出力例

      apiVersion: v1
      data:
        policy.cfg: |
          {
          "kind" : "Policy",
          "apiVersion" : "v1",
          "predicates" : [
                  {"name" : "MaxGCEPDVolumeCount"},
                  {"name" : "GeneralPredicates"},
                  {"name" : "MaxAzureDiskVolumeCount"},
                  {"name" : "MaxCSIVolumeCountPred"},
                  {"name" : "CheckVolumeBinding"},
                  {"name" : "MaxEBSVolumeCount"},
                  {"name" : "MatchInterPodAffinity"},
                  {"name" : "CheckNodeUnschedulable"},
                  {"name" : "NoDiskConflict"},
                  {"name" : "NoVolumeZoneConflict"},
                  {"name" : "PodToleratesNodeTaints"}
                  ],
          "priorities" : [
                  {"name" : "LeastRequestedPriority", "weight" : 1},
                  {"name" : "BalancedResourceAllocation", "weight" : 1},
                  {"name" : "ServiceSpreadingPriority", "weight" : 1},
                  {"name" : "NodePreferAvoidPodsPriority", "weight" : 1},
                  {"name" : "NodeAffinityPriority", "weight" : 1},
                  {"name" : "TaintTolerationPriority", "weight" : 1},
                  {"name" : "ImageLocalityPriority", "weight" : 1},
                  {"name" : "SelectorSpreadPriority", "weight" : 1},
                  {"name" : "InterPodAffinityPriority", "weight" : 1},
                  {"name" : "EqualPriority", "weight" : 1}
                  ]
          }

    3. スケジューラー JSON ファイルに基づいてスケジューラーポリシーの設定マップを再作成します。

      $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name> 1
      1
      設定マップの名前を入力します。

      以下に例を示します。

      $ oc create configmap -n openshift-config --from-file=policy.cfg scheduler-policy

      出力例

      configmap/scheduler-policy created

3.2.3.1. スケジューラーの述語について

述語は、不適切なノードをフィルターに掛けるルールです。

OpenShift Container Platform には、デフォルトでいくつかの述語が提供されています。これらの述語の一部は、特定のパラメーターを指定してカスタマイズできます。複数の述語を組み合わせてノードの追加フィルターを指定できます。

3.2.3.1.1. 静的な述語

これらの述語はユーザーから設定パラメーターまたは入力を取りません。これらはそれぞれの正確な名前を使用してスケジューラー設定に指定されます。

3.2.3.1.1.1. デフォルトの述語

デフォルトのスケジューラーポリシーには以下の述語が含まれます。

NoVolumeZoneConflict 述語は Pod が要求するボリュームがゾーンで利用可能であることを確認します。

{"name" : "NoVolumeZoneConflict"}

MaxEBSVolumeCount 述語は、AWS インスタンスに割り当てることのできるボリュームの最大数を確認します。

{"name" : "MaxEBSVolumeCount"}

MaxAzureDiskVolumeCount 述語は Azure ディスクボリュームの最大数をチェックします。

{"name" : "MaxAzureDiskVolumeCount"}

PodToleratesNodeTaints 述語は Pod がノードテイントを許容できるかどうかをチェックします。

{"name" : "PodToleratesNodeTaints"}

CheckNodeUnschedulable 述語は、Pod を Unschedulable 仕様でノード上にスケジュールできるかどうかをチェックします。

{"name" : "CheckNodeUnschedulable"}

CheckVolumeBinding 述語は、バインドされた PVC とバインドされていない PVC の両方について Pod が要求するボリュームに基づいて Pod が適切かどうかを評価します。

  • バインドされる PVC の場合、述語は対応する PV のノードアフィニティーが指定ノードで満たされていることをチェックします。
  • バインドされない PVC の場合、述語は PVC 要件を満たし、PV ノードのアフィニティーが指定ノードで満たされる利用可能な PV を検索します。

述語は、すべてのバインドされる PVC にノードと互換性のある PV がある場合や、すべてのバインドされていない PVC が利用可能なノードと互換性のある PV に一致する場合に true を返します。

{"name" : "CheckVolumeBinding"}

NoDiskConflict 述語は Pod が要求するボリュームが利用可能であるかどうかを確認します。

{"name" : "NoDiskConflict"}

MaxGCEPDVolumeCount 述語は、Google Compute Engine (GCE) 永続ディスク (PD) の最大数を確認します。

{"name" : "MaxGCEPDVolumeCount"}

MaxCSIVolumeCountPred 述語は、ノードに割り当てられる Container Storage Interface (CSI) ボリュームの数と、その数が設定した制限を超えるかどうかを判別します。

{"name" : "MaxCSIVolumeCountPred"}

MatchInterPodAffinity 述語は、Pod のアフィニティー/非アフィニティールールが Pod を許可するかどうかを確認します。

{"name" : "MatchInterPodAffinity"}
3.2.3.1.1.2. 他の静的な述語

OpenShift Container Platform は以下の述語もサポートしています。

注記

CheckNode-* 述語は、Taint Nodes By Condition 機能が有効にされている場合は使用できません。Taint Nodes By Condition 機能はデフォルトで有効にされています。

CheckNodeCondition 述語は、out of disk (ディスク不足)network unavailable (ネットワークが使用不可)、または not ready (準備できていない) 状態を報告するノードで Pod をスケジュールできるかどうかを確認します。

{"name" : "CheckNodeCondition"}

CheckNodeLabelPresence 述語は、すべての指定されたラベルがノードに存在するかどうかを確認します (その値が何であるかを問わない)。

{"name" : "CheckNodeLabelPresence"}

checkServiceAffinity 述語は、ServiceAffinity ラベルがノードでスケジュールされる Pod について同種のものであることを確認します。

{"name" : "checkServiceAffinity"}

PodToleratesNodeNoExecuteTaints 述語は、Pod がノードの NoExecute テイントを容認できるかどうかを確認します。

{"name" : "PodToleratesNodeNoExecuteTaints"}
3.2.3.1.2. 汎用的な述語

以下の汎用的な述語は、非クリティカル述語とクリティカル述語が渡されるかどうかを確認します。非クリティカル述語は、非 Critical Pod のみが渡す必要のある述語であり、クリティカル述語はすべての Pod が渡す必要のある述語です。

デフォルトのスケジューラーポリシーにはこの汎用的な述語が含まれます

汎用的な非クリティカル述語

PodFitsResources 述語は、リソースの可用性 (CPU、メモリー、GPU など) に基づいて適切な候補を判別します。ノードはそれらのリソース容量を宣言し、Pod は要求するリソースを指定できます。使用されるリソースではなく、要求されるリソースに基づいて適切な候補が判別されます。

{"name" : "PodFitsResources"}
汎用的なクリティカル述語

PodFitsHostPorts 述語は、ノードに要求される Pod ポートの空きポートがある (ポートの競合がない) かどうかを判別します。

{"name" : "PodFitsHostPorts"}

HostName 述語は、ホストパラメーターの有無と文字列のホスト名との一致に基づいて適切なノードを判別します。

{"name" : "HostName"}

MatchNodeSelector 述語は、Pod で定義されるノードセレクター (nodeSelector) のクエリーに基づいて適したノードを判別します。

{"name" : "MatchNodeSelector"}