搜索
支持控制台（Console）开发人员开始试用联系人

2.2. 配置默认调度程序以控制 pod 放置

download PDF

OpenShift Container Platform 的默认 pod 调度程序负责确定在集群的节点中放置新的 pod。它从 pod 读取数据，并尝试根据配置的策略寻找最适合的节点。它完全独立存在，作为单机或可插拔的解决方案。它不会修改 pod，只是为 pod 创建将 pod 与特定节点衔接起来的绑定。

调度程序的策略由一组 predicates 和 priorities 来定义。如需 predicates 和 priorities 的列表，请参阅修改调度程序策略。

默认调度程序对象示例

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 的节点：

过滤节点
根据指定的约束或要求过滤可用的节点。这可以通过名为predicates的过滤函数列表筛选每个节点来完成。
排列过滤后节点列表的优先顺序
实现方式是让每个节点通过一系列优先级函数，以为其分配从 0 到 10 的一个分数。0 代表不适合的节点，10 则代表最适合托管该 pod。调度程序配置还可以为每个优先级函数使用简单的权重（正数值）。每个优先级函数提供的节点分数乘以权重（大多数优先级的默认权重为 1），然后将每个节点从所有优先级获得的分数相加。管理员可以使用这个权重属性，为一些优先级赋予更高的重要性。
选择最适合的节点
节点按照分数排序，系统选择分数最高的节点来托管该 pod。如果多个节点的分数相同，则随机选择其中一个。

2.2.1.1. 了解调度程序策略

调度程序的策略由一组 predicates 和 priorities 来定义。

调度程序配置文件是一个 JSON 文件，必须命名为 policy.cfg，用于指定调度程序将要考量的 predicates 和 priorities。

如果没有调度程序策略文件，则使用默认的调度程序行为。

重要

调度程序配置文件中定义的 predicates 和 priorities 会完全覆盖默认的调度程序策略。如果需要任何默认的 predicates 和 priorities，必须在策略配置中明确指定对应的函数。

调度程序 ConfigMap 示例

apiVersion: v1
data:
  policy.cfg: |
    {
        "kind" : "Policy",
        "apiVersion" : "v1",
        "predicates" : [
                {"name" : "MaxGCEPDVolumeCount"},
                {"name" : "GeneralPredicates"},
                {"name" : "MaxAzureDiskVolumeCount"},
                {"name" : "MaxCSIVolumeCountPred"},
                {"name" : "CheckVolumeBinding"},
                {"name" : "MaxEBSVolumeCount"},
                {"name" : "PodFitsResources"},
                {"name" : "MatchInterPodAffinity"},
                {"name" : "CheckNodeUnschedulable"},
                {"name" : "NoDiskConflict"},
                {"name" : "NoVolumeZoneConflict"},
                {"name" : "MatchNodeSelector"},
                {"name" : "HostName"},
                {"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`

2.2.2. 创建调度程序策略文件

您可以通过创建 JSON 文件并使用所需的 predicates 和 priorities 来控制或更改默认的调度行为。然后，您可以通过 JSON 文件生成 ConfigMap，并将 cluster 调度程序对象指定为使用该 ConfigMap。

流程

配置调度程序策略：

  1. 使用所需的 predicates 和 priorities，创建一个名为 policy.cfg 的 JSON 文件。

    调度程序 JSON 文件示例

    {
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [ 1
        {"name" : "PodFitsHostPorts"},
        {"name" : "PodFitsResources"},
        {"name" : "NoDiskConflict"},
        {"name" : "NoVolumeZoneConflict"},
        {"name" : "MatchNodeSelector"},
        {"name" : "MaxEBSVolumeCount"},
        {"name" : "MaxAzureDiskVolumeCount"},
        {"name" : "checkServiceAffinity"},
        {"name" : "PodToleratesNodeNoExecuteTaints"},
        {"name" : "MaxGCEPDVolumeCount"},
        {"name" : "MatchInterPodAffinity"},
        {"name" : "PodToleratesNodeTaints"},
        {"name" : "HostName"}
        ],
"priorities" : [2
        {"name" : "LeastRequestedPriority", "weight" : 1},
        {"name" : "BalancedResourceAllocation", "weight" : 1},
        {"name" : "ServiceSpreadingPriority", "weight" : 1},
        {"name" : "EqualPriority", "weight" : 1}
        ]
}

    1
    根据需要添加 predicates。
    2
    根据需要添加 priorities。

  2. 根据调度程序 JSON 文件创建 ConfigMap： 

    $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name> 1
    1
    输入 ConfigMap 的名称。

    例如： 

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

configmap/scheduler-policy created
    apiVersion: v1
data:
  policy.cfg: |
    {
        "kind" : "Policy",
        "apiVersion" : "v1",
        "predicates" : [
                {"name" : "MaxGCEPDVolumeCount"},
                {"name" : "GeneralPredicates"},
                {"name" : "MaxAzureDiskVolumeCount"},
                {"name" : "MaxCSIVolumeCountPred"},
                {"name" : "CheckVolumeBinding"},
                {"name" : "MaxEBSVolumeCount"},
                {"name" : "PodFitsResources"},
                {"name" : "MatchInterPodAffinity"},
                {"name" : "CheckNodeUnschedulable"},
                {"name" : "NoDiskConflict"},
                {"name" : "NoVolumeZoneConflict"},
                {"name" : "MatchNodeSelector"},
                {"name" : "HostName"},
                {"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`

  3. 编辑调度程序 Operator 自定义资源以添加 ConfigMap： 

    $ oc patch Scheduler cluster --type='merge' -p '{"spec":{"policy":{"name":"<configmap-name>"}}}' --type=merge 1
    1
    指定 ConfigMap 的名称。

    例如： 

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

    在修改了调度程序配置资源后，等待 opensift-kube-apiserver pod 重新部署。这可能需要几分钟。只有重新部署 pod 后，新的调度程序才会生效。

  4. 通过查看 openshift-kube-scheduler 命名空间中调度程序 pod 的日志，来验证已配置调度程序策略。以下命令检查由调度程序注册的 predicates 和 priorities： 

    $ 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:{} MatchNodeSelector:{} GeneralPredicates:{} MaxCSIVolumeCountPred:{} CheckVolumeBinding:{} MaxEBSVolumeCount:{} PodFitsResources:{} MatchInterPodAffinity:{} HostName:{} PodToleratesNodeTaints:{}]' and priority functions 'map[InterPodAffinityPriority:{} LeastRequestedPriority:{} ServiceSpreadingPriority:{} ImageLocalityPriority:{} SelectorSpreadPriority:{} EqualPriority:{} BalancedResourceAllocation:{} NodePreferAvoidPodsPriority:{} NodeAffinityPriority:{} TaintTolerationPriority:{}]'

2.2.3. 修改调度程序策略

您可以通过在 openshift-config 项目中创建或编辑调度程序策略 ConfigMap 来更改调度行为。在 ConfigMap 中添加和移除 predicates 和 priorities，以创建调度程序策略。

流程

要修改当前的自定义调度，请使用以下方法之一：

  • 编辑调度程序策略 ConfigMap： 

    $ 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" : "PodFitsResources"},
                {"name" : "MatchInterPodAffinity"},
                {"name" : "CheckNodeUnschedulable"},
                {"name" : "NoDiskConflict"},
                {"name" : "NoVolumeZoneConflict"},
                {"name" : "MatchNodeSelector"},
                {"name" : "HostName"},
                {"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
    根据需要添加或移除 predicates。
    2
    根据需要，添加、移除或更改 predicates 的权重。

    调度程序需要几分钟时间来使用更新后的策略重启 pod。

  • 更改所用的 predicates 和 priorities：

    1. 移除调度程序策略 CongifMap： 

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

      例如： 

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

    2. 根据需要，编辑 policy.cfg 文件来添加和移除 policies 和 predicates。

      例如： 

      $ vi policy.cfg
      apiVersion: v1
data:
  policy.cfg: |
    {
    "kind" : "Policy",
    "apiVersion" : "v1",
    "predicates" : [
            {"name" : "PodFitsHostPorts"},
            {"name" : "PodFitsResources"},
            {"name" : "NoDiskConflict"},
            {"name" : "NoVolumeZoneConflict"},
            {"name" : "MatchNodeSelector"},
            {"name" : "MaxEBSVolumeCount"},
            {"name" : "MaxAzureDiskVolumeCount"},
            {"name" : "CheckVolumeBinding"},
            {"name" : "CheckServiceAffinity"},
            {"name" : "PodToleratesNodeNoExecuteTaints"},
            {"name" : "MaxGCEPDVolumeCount"},
            {"name" : "MatchInterPodAffinity"},
            {"name" : "PodToleratesNodeTaints"},
            {"name" : "HostName"}
            ],
    "priorities" : [
            {"name" : "LeastRequestedPriority", "weight" : 2},
            {"name" : "BalancedResourceAllocation", "weight" : 2},
            {"name" : "ServiceSpreadingPriority", "weight" : 2},
            {"name" : "EqualPriority", "weight" : 2}
            ]
    }

    3. 根据调度程序 JSON 文件重新创建调度程序策略 ConfigMap： 

      $ oc create configmap -n openshift-config --from-file=policy.cfg <configmap-name> 1
      1
      输入 ConfigMap 的名称。

      例如： 

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

configmap/scheduler-policy created

2.2.3.1. 了解调度程序 predicates

predicates 是用于过滤掉不合格节点的规则。

OpenShift Container Platform 中默认提供一些 predicates。其中的一些 predicates 可以通过提供特定参数来自定义。可以组合多个 predicates 来提供更多节点过滤。

2.2.3.1.1. 静态 predicates

此类 predicates 不接受任何来自于用户的配置参数或输入。它们通过其确切的名称在调度程序配置中指定。

2.2.3.1.1.1. 默认 predicates

默认的调度程序策略包括以下 predicates：

NoVolumeZoneConflict 检查区域中是否有 pod 请求的卷。 

{"name" : "NoVolumeZoneConflict"}

MaxEBSVolumeCount 检查可附加到 AWS 实例的最大卷数量。 

{"name" : "MaxEBSVolumeCount"}

MaxAzureDiskVolumeCount 检查 Azure 磁盘卷的最大数量。 

{"name" : "MaxAzureDiskVolumeCount"}

PodToleratesNodeTaints 检查 pod 是否可以容忍节点污点。 

{"name" : "PodToleratesNodeTaints"}

CheckNodeUnschedulable 检查 pod 是否能够调度到指定有 Unschedulable 的节点。 

{"name" : "CheckNodeUnschedulable"}

CheckVolumeBinding 根据 pod 请求的卷，评估 pod 是否同时适合绑定和未绑定 PVC。* 对于绑定的 PVC，该 predicate 检查给定节点是否满足对应 PV 的节点关联性。* 对于未绑定 PVC，该 predicate 会搜索可满足 PVC 要求的可用 PV，并且检查给定节点是否满足 PV 的节点关联性。

如果所有绑定 PVC 都有与节点兼容的 PV，且所有未绑定 PVC 都可与可用并兼容节点的 PV 匹配，该 predicate 会返回 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. 其他静态 predicates

OpenShift Container Platform 还支持下列 predicates：

注意

如果启用了 Taint Nodes By Condition 功能，则无法使用 CheckNode-* predicates。Taint Nodes By Condition 功能默认启用。

CheckNodeCondition 检查 pod 是否可以调度到报告磁盘不足、网络不可用或未就绪状况的节点。 

{"name" : "CheckNodeCondition"}

CheckNodeLabelPresence 检查节点上是否存在所有指定的标签，不论它们的值是什么。 

{"name" : "CheckNodeLabelPresence"}

checkServiceAffinity 检查 ServiceAffinity 标签是否对于节点上调度的 pod 而言一致。 

{"name" : "checkServiceAffinity"}

PodToleratesNodeNoExecuteTaints 检查 pod 容限是否容忍节点的 NoExecute 污点。 

{"name" : "PodToleratesNodeNoExecuteTaints"}
2.2.3.1.2. 常规 predicates

下列常规 predicates 检查是否通过非关键 predicates 和必要 predicates 的检查。非关键 predicates 是指只有非关键 pod 必须通过检查的 predicates，而必要 predicates 是指所有 pod 都必须通过检查的 predicates。

默认调度程序策略包含常规 predicates。

非关键常规 predicates

PodFitsResources 根据资源可用性（CPU、内存、GPU 等）来确定适合性。节点可以声明其资源容量，然后 pod 可以指定它们所需要的资源。适合性基于请求的资源，而非使用的资源。 

{"name" : "PodFitsResources"}
必要常规 predicates

PodFitsHostPorts 确定节点是否有空闲端口可用于请求的 pod 端口（不存在端口冲突）。 

{"name" : "PodFitsHostPorts"}

HostName 基于存在 Host 参数以及与主机名称匹配的字符串来确定适合性。 

{"name" : "HostName"}

MatchNodeSelector 基于 pod 中定义的节点选择器 (nodeSelector) 查询来确定适合性。 

{"name" : "MatchNodeSelector"}

2.2.3.2. 了解调度程序优先级

优先级是根据偏好对节点进行排序的规则。

可以指定一组自定义优先级来配置调度程序。OpenShift Container Platform 中默认提供一些优先级。也可通过提供某些参数来自定义其他优先级。可将多个优先级合并，并为每个优先级赋予不同的权重来影响优先顺序。

2.2.3.2.1. 静态优先级

静态优先级不使用用户提供的配置参数，但权重除外。权重必须指定，且不能为 0 或负数。

这些是在 openshift-config 项目中的调度程序策略 Configmap 中指定的。

2.2.3.2.1.1. 默认优先级

默认调度程序策略包括以下优先级。每个优先级函数的权重为 1，但 NodePreferAvoidPodsPriority 除外，它的权重是 10000。

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 通过迭代 weightedPodAffinityTerm 的元素并在节点满足对应的 PodAffinityTerm 时加上权重来计算总和。总和最高的节点是优先级最高的节点。 

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

LeastRequestedPriority 优先选择请求资源较少的节点。它计算节点上调度的 pod 所请求的内存和 CPU 百分比，并优先选择可用/剩余容量最高的节点。 

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

BalancedResourceAllocation 优先选择资源使用率均衡的节点。它以占容量比形式计算 CPU 和内存已使用量的差值，并基于两个指标相互接近的程度来优先选择节点。这应该始终与 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 项目的调度程序策略的 Configmap 中配置这些优先级，以添加可影响优先级的标记（label）。

优先级函数的类型由它们所使用的参数来标识。由于它们是可配置的，因此可以组合类型相同（但配置参数不同）的多个优先级，但前提是它们的用户定义名称不同。

有关使用这些优先级的详情，请参考“修改调度程序策略”。

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。请参考此红帽解决方案。

* 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
predicate 的名称。
2
predicate 的类型。
3
predicate 的标签。
4
优先级的名称。
5
优先级的类型。
6
优先级的标签。

在下方的所有示例配置中，predicates 和 priorities 函数的列表都已截断，仅包含与指定用例相关的内容。在实践中，完整/有意义的调度程序策略应当包含前文所述的大部分（若非全部）默认 predicates 和 priorities。

以下示例定义了三个拓扑级别，即 region（关联性）-> zone（关联性）-> rack（反关联性）： 

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

以下示例定义了三个拓扑级别，即 city（关联性）-> building（反关联性）-> room（反关联性）： 

{
"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": {
                "label": "region",
                "presence": true
           }
        }
     }
  ],
"priorities": [
    {
        "name":"ZonePreferred",
        "weight" : 1,
        "argument": {
            "labelPreference": {
                "label": "zone",
                "presence": true
                }
           }
       }
   ]
}

以下示例组合使用静态和可配置的 predicates 和 priorities： 

{
"kind": "Policy",
"apiVersion": "v1",
"predicates": [
    {
        "name": "RegionAffinity",
        "argument": {
            "serviceAffinity": {
                "label": "region"
           }
        }
     },
    {
        "name": "RequireRegion",
        "argument": {
            "labelsPresence": {
                "label": "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}
    ]
}
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.