2.2. デフォルトスケジューラーの設定による Pod 配置の制御

OpenShift Container Platform のデフォルトの Pod スケジューラーは、クラスター内のノードにおける新規 Pod の配置場所を判別します。スケジューラーは Pod からのデータを読み取り、設定されるポリシーに基づいて適切なノードを見つけようとします。これは完全に独立した機能であり、スタンドアロン/プラグ可能ソリューションです。Pod を変更することはなく、Pod を特定ノードに関連付ける Pod のバインディングのみを作成します。

述語と優先順位を選択することで、スケジューラーのポリシーを定義できます。述語と優先順位の一覧は、「スケジューラーポリシーの変更」を参照してください。

デフォルトスケジューラーオブジェクトのサンプル

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  creationTimestamp: 2019-05-20T15:39:01Z
  generation: 1
  name: cluster
  resourceVersion: "1491"
  selfLink: /apis/config.openshift.io/v1/schedulers/cluster
  uid: 6435dd99-7b15-11e9-bd48-0aec821b8e34
spec:
  policy: 1
    name: scheduler-policy
  defaultNodeSelector: type=user-node,region=east 2

1
カスタムスケジューラーポリシーファイルの名前を指定できます。
2
オプションで、Pod の配置を特定のノードに制限するためにデフォルトノードセレクターを指定します。

2.2.1. デフォルトスケジューリングについて

既存の汎用スケジューラーはプラットフォームで提供されるデフォルトのスケジューラー エンジン であり、Pod をホストするノードを 3 つの手順で選択します。

ノードのフィルター
利用可能なノードは、指定される制約や要件に基づいてフィルターされます。フィルターは、各ノードで 述語 というフィルター関数の一覧を使用して実行されます。
フィルターされたノード一覧の優先順位付け
優先順位付けは、各ノードに一連の優先度関数を実行することによって行われます。この関数は 0 -10 までのスコアをノードに割り当て、0 は不適切であることを示し、10 は Pod のホストに適していることを示します。スケジューラー設定は、それぞれの優先度関数について単純な 重み (正の数値) を取ることができます。各優先度関数で指定されるノードのスコアは重み (ほとんどの優先度のデフォルトの重みは 1) で乗算され、すべての優先度で指定されるそれぞれのノードのスコアを追加して組み合わされます。この重み属性は、一部の優先度により重きを置くようにするなどの目的で管理者によって使用されます。
最適ノードの選択
ノードの並び替えはそれらのスコアに基づいて行われ、最高のスコアを持つノードが Pod をホストするように選択されます。複数のノードに同じ高スコアが付けられている場合、それらのいずれかがランダムに選択されます。

2.2.1.1. スケジューラーポリシーについて

述語と優先順位を選択することで、スケジューラーのポリシーを定義します。

スケジューラー設定ファイルは JSON ファイルであり、policy.cfgという名前にする必要があります。これは、スケジューラーが反映する述語と優先順位を指定します。

スケジューラーポリシーがない場合、デフォルトのスケジューラーの動作が使用されます。

重要

スケジューラー設定ファイルで定義される述語および優先度は、デフォルトのスケジューラーポリシーを完全に上書きします。デフォルトの述語および優先順位のいずれかが必要な場合、ポリシーの設定でその関数を明示的に指定する必要があります。

スケジューラー設定マップの例

apiVersion: v1
data:
  policy.cfg: |
    {
        "kind" : "Policy",
        "apiVersion" : "v1",
        "predicates" : [
                {"name" : "MaxGCEPDVolumeCount"},
                {"name" : "GeneralPredicates"}, 1
                {"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}
                ]
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2019-09-17T08:42:33Z"
  name: scheduler-policy
  namespace: openshift-config
  resourceVersion: "59500"
  selfLink: /api/v1/namespaces/openshift-config/configmaps/scheduler-policy
  uid: 17ee8865-d927-11e9-b213-02d1e1709840`

1
GeneralPredicates 述語は PodFitsResourcesHostNamePodFitsHostPorts、および MatchNodeSelector 述語を表します。同じ述語を複数回設定することは許可されていないため、GeneralPredicates 述語を、表現される 4 つの述語と共に使用することはできません。

2.2.2. スケジューラーポリシーファイルの作成

デフォルトのスケジューリング動作を変更するには、必要な述語および優先順位を使用して JSON ファイルを作成します。次に、JSON ファイルから設定マップを生成し、設定マップを使用するように cluster スケジューラーオブジェクトを指定します。

手順

スケジューラーポリシーを設定するには、以下を実行します。

  1. 必要な述語と優先順位を使って policy.cfg という名前の JSON ファイルを作成します。

    スケジューラー JSON ファイルのサンプル

    {
    "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}
            ]
    }

    1
    必要に応じて述語を追加します。
    2
    必要に応じて優先順位を追加します。
  2. スケジューラー 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. スケジューラー Operator カスタムリソースを編集して設定マップを追加します。

    $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"<configmap-name>"}}}' --type=merge 1
    1
    設定マップの名前を指定します。

    以下は例になります。

    $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"scheduler-policy"}}}' --type=merge

    Scheduler 設定リソースに変更を加えた後に、openshift-kube-apiserver Pod の再デプロイを待機します。これには数分の時間がかかる場合があります。Pod が再デプロイされるまで、新規スケジューラーは有効になりません。

  4. openshift-kube-scheduler namespace のスケジューラー Pod のログを表示して、スケジューラーポリシーが設定されていることを確認します。以下のコマンドは、スケジューラーによって登録される述語と優先順位をチェックします。

    $ oc logs <scheduler-pod> | grep predicates

    以下は例になります。

    $ oc logs openshift-kube-scheduler-ip-10-0-141-29.ec2.internal | grep predicates

    出力例

    Creating scheduler with fit predicates 'map[MaxGCEPDVolumeCount:{} MaxAzureDiskVolumeCount:{} CheckNodeUnschedulable:{} NoDiskConflict:{} NoVolumeZoneConflict:{} GeneralPredicates:{} MaxCSIVolumeCountPred:{} CheckVolumeBinding:{} MaxEBSVolumeCount:{} MatchInterPodAffinity:{} PodToleratesNodeTaints:{}]' and priority functions 'map[InterPodAffinityPriority:{} LeastRequestedPriority:{} ServiceSpreadingPriority:{} ImageLocalityPriority:{} SelectorSpreadPriority:{} EqualPriority:{} BalancedResourceAllocation:{} NodePreferAvoidPodsPriority:{} NodeAffinityPriority:{} TaintTolerationPriority:{}]'

2.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

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

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

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

2.2.3.1.1. 静的な述語

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

2.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

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

{"name" : "MatchInterPodAffinity"}
2.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"}
2.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"}

2.2.3.2. スケジューラーの優先順位について

優先順位は、設定に応じてノードにランクを付けるルールです。

優先度のカスタムセットは、スケジューラーを設定するために指定できます。OpenShift Container Platform ではデフォルトでいくつかの優先度があります。他の優先度は、特定のパラメーターを指定してカスタマイズできます。優先順位に影響を与えるために、複数の優先度を組み合わせ、異なる重みをそれぞれのノードに指定することができます。

2.2.3.2.1. 静的優先度

静的優先度は、重みを除き、ユーザーからいずれの設定パラメーターも取りません。重みは指定する必要があり、0 または負の値にすることはできません。

これらは openshift-config プロジェクトのスケジューラーポリシー設定マップに指定されます。

2.2.3.2.1.1. デフォルトの優先度

デフォルトのスケジューラーポリシーには、以下の優先度が含まれています。それぞれの優先度関数は、重み 10000 を持つ NodePreferAvoidPodsPriority 以外は重み 1 を持ちます。

NodeAffinityPriority の優先度は、ノードアフィニティーのスケジュールの優先度に応じてノードに優先順位を付けます。

{"name" : "NodeAffinityPriority", "weight" : 1}

TaintTolerationPriority の優先度は、Pod についての 容認不可能な テイント数の少ないノードを優先します。容認不可能なテイントとはキー PreferNoSchedule のあるテイントのことです。

{"name" : "TaintTolerationPriority", "weight" : 1}

ImageLocalityPriority の優先度は、Pod コンテナーのイメージをすでに要求しているノードを優先します。

{"name" : "ImageLocalityPriority", "weight" : 1}

SelectorSpreadPriority は、Pod に一致するサービス、レプリケーションコントローラー (RC)、レプリケーションセット (RS)、およびステートフルなセットを検索し、次にそれらのセレクターに一致する既存の Pod を検索します。スケジューラーは、一致する既存の Pod が少ないノードを優先します。次に、Pod のスケジュール時にそれらのセレクターに一致する Pod 数の最も少ないノードで Pod をスケジュールします。

{"name" : "SelectorSpreadPriority", "weight" : 1}

InterPodAffinityPriority の優先度は、ノードの対応する PodAffinityTerm が満たされている場合に weightedPodAffinityTerm の要素を使った繰り返し処理や 重み の合計への追加によって合計を計算します。合計値の最も高いノードが最も優先されます。

{"name" : "InterPodAffinityPriority", "weight" : 1}

LeastRequestedPriority の優先度は、要求されたリソースの少ないノードを優先します。これは、ノードでスケジュールされる Pod によって要求されるメモリーおよび CPU のパーセンテージを計算し、利用可能な/残りの容量の値の最も高いノードを優先します。

{"name" : "LeastRequestedPriority", "weight" : 1}

BalancedResourceAllocation の優先度は、均衡が図られたリソース使用率に基づいてノードを優先します。これは、容量の一部として消費済み CPU とメモリー間の差異を計算し、2 つのメトリクスがどの程度相互に近似しているかに基づいてノードの優先度を決定します。これは常に LeastRequestedPriority と併用する必要があります。

{"name" : "BalancedResourceAllocation", "weight" : 1}

NodePreferAvoidPodsPriority の優先度は、レプリケーションコントローラー以外のコントローラーによって所有される Pod を無視します。

{"name" : "NodePreferAvoidPodsPriority", "weight" : 10000}
2.2.3.2.1.2. 他の静的優先度

OpenShift Container Platform は以下の優先度もサポートしています。

EqualPriority の優先度は、優先度の設定が指定されていない場合に、すべてのノードに等しい重み 1 を指定します。この優先順位はテスト環境にのみ使用することを推奨します。

{"name" : "EqualPriority", "weight" : 1}

MostRequestedPriority の優先度は、要求されたリソースの最も多いノードを優先します。これは、ノードスケジュールされる Pod で要求されるメモリーおよび CPU のパーセンテージを計算し、容量に対して要求される部分の平均の最大値に基づいて優先度を決定します。

{"name" : "MostRequestedPriority", "weight" : 1}

ServiceSpreadingPriority の優先度は、同じマシンに置かれる同じサービスに属する Pod 数を最小限にすることにより Pod を分散します。

{"name" : "ServiceSpreadingPriority", "weight" : 1}
2.2.3.2.2. 設定可能な優先順位

これらの優先順位を openshift-config プロジェクトのスケジューラーポリシー設定マップに設定し、優先順位に影響を与えるラベルを追加できます。

優先度関数のタイプは、それらが取る引数によって識別されます。これらは設定可能なため、ユーザー定義の名前が異なる場合に、同じタイプの (ただし設定パラメーターは異なる) 設定可能な複数の優先度を組み合わせることができます。

優先順位の使用方法については、スケジューラーポリシーの変更についての箇所を参照してください。

ServiceAntiAffinity の優先度はラベルを取り、ラベルの値に基づいてノードのグループ全体に同じサービスに属する Pod を適正に分散します。これは、指定されたラベルの同じ値を持つすべてのノードに同じスコアを付与します。また Pod が最も集中していないグループ内のノードにより高いスコアを付与します。

{
"kind": "Policy",
"apiVersion": "v1",

"priorities":[
    {
        "name":"<name>", 1
        "weight" : 1 2
        "argument":{
            "serviceAntiAffinity":{
                "label": "<label>" 3
                }
           }
       }
   ]
}
1
優先度の名前を指定します。
2
重みを指定します。ゼロ以外の正の値を指定します。
3
一致するラベルを指定します。

以下は例になります。

{
"kind": "Policy",
"apiVersion": "v1",
"priorities": [
    {
        "name":"RackSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "rack"
                }
           }
       }
   ]
}
注記

カスタムラベルに基づいて ServiceAntiAffinity パラメーターを使用しても Pod を予想通りに展開できない場合があります。Red Hat ソリューション を参照してください。

labelPreference パラメーターは指定されたラベルに基づいて優先順位を指定します。ラベルがノードにある場合、そのノードに優先度が指定されます。ラベルが指定されていない場合は、優先度はラベルを持たないノードに指定されます。labelPreference パラメーターのある複数の優先度が設定されている場合、すべての優先度に同じ重みが付けられている必要があります。

{
"kind": "Policy",
"apiVersion": "v1",
"priorities":[
    {
        "name":"<name>", 1
        "weight" : 1 2
        "argument":{
            "labelPreference":{
                "label": "<label>", 3
                "presence": true 4
                }
            }
        }
    ]
}
1
優先度の名前を指定します。
2
重みを指定します。ゼロ以外の正の値を指定します。
3
一致するラベルを指定します。
4
ラベルが必要であるかを、true または false のいずれかで指定します。

2.2.4. ポリシー設定のサンプル

以下の設定は、スケジューラーポリシーファイルを使って指定される場合のデフォルトのスケジューラー設定を示しています。

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionZoneAffinity", 1
        "argument": {
            "serviceAffinity": {  2
              "labels": ["region, zone"]  3
           }
        }
     }
  ],
"priorities": [
    {
        "name":"RackSpread", 4
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {  5
                "label": "rack"  6
                }
           }
       }
   ]
}
1
述語の名前です。
2
述語のタイプです。
3
述語のラベルです。
4
優先順位の名前です。
5
優先順位のタイプです。
6
優先順位のラベルです。

以下の設定例のいずれの場合も、述語と優先度関数の一覧は、指定された使用例に関連するもののみを含むように切り捨てられます。実際には、完全な/分かりやすいスケジューラーポリシーには、上記のデフォルトの述語および優先度のほとんど (すべてではなくても) が含まれるはずです。

以下の例は、region (affinity) → zone (affinity) → rack (anti-affinity) の 3 つのトポロジーレベルを定義します。

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionZoneAffinity",
        "argument": {
            "serviceAffinity": {
              "labels": ["region, zone"]
           }
        }
     }
  ],
"priorities": [
    {
        "name":"RackSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "rack"
                }
           }
       }
   ]
}

以下の例は、city (affinity) → building (anti-affinity) → room (anti-affinity) の 3 つのとポロジーレベルを定義します。

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "CityAffinity",
        "argument": {
            "serviceAffinity": {
              "label": "city"
           }
        }
     }
  ],
"priorities": [
    {
        "name":"BuildingSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "building"
                }
           }
       },
    {
        "name":"RoomSpread",
        "weight" : 1,
        "argument": {
            "serviceAntiAffinity": {
                "label": "room"
                }
           }
       }
   ]
}

以下の例では、「region」ラベルが定義されたノードのみを使用し、「zone」ラベルが定義されたノードを優先するポリシーを定義します。

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RequireRegion",
        "argument": {
            "labelPreference": {
                "labels": ["region"],
                "presence": true
           }
        }
     }
  ],
"priorities": [
    {
        "name":"ZonePreferred",
        "weight" : 1,
        "argument": {
            "labelPreference": {
                "label": "zone",
                "presence": true
                }
           }
       }
   ]
}

以下の例では、静的および設定可能な述語および優先順位を組み合わせています。

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionAffinity",
        "argument": {
            "serviceAffinity": {
                "labels": ["region"]
           }
        }
     },
    {
        "name": "RequireRegion",
        "argument": {
            "labelsPresence": {
                "labels": ["region"],
                "presence": true
           }
        }
     },
    {
        "name": "BuildingNodesAvoid",
        "argument": {
            "labelsPresence": {
                "label": "building",
                "presence": false
           }
        }
     },
     {"name" : "PodFitsPorts"},
     {"name" : "MatchNodeSelector"}
     ],
"priorities": [
    {
        "name": "ZoneSpread",
        "weight" : 2,
        "argument": {
            "serviceAntiAffinity":{
                "label": "zone"
                }
           }
       },
    {
        "name":"ZonePreferred",
        "weight" : 1,
        "argument": {
            "labelPreference":{
                "label": "zone",
                "presence": true
                }
           }
       },
    {"name" : "ServiceSpreadingPriority", "weight" : 1}
    ]
}