From 291e7ab8733a3e1bc9db532b3fd17f3836a3339f Mon Sep 17 00:00:00 2001 From: HirazawaUi <695097494plus@gmail.com> Date: Fri, 15 Apr 2022 16:57:18 +0800 Subject: [PATCH] Update scheduling/config.md --- .../zh/docs/reference/scheduling/config.md | 615 +++++++++++++----- 1 file changed, 460 insertions(+), 155 deletions(-) diff --git a/content/zh/docs/reference/scheduling/config.md b/content/zh/docs/reference/scheduling/config.md index 99c9557e57..93a45419a0 100644 --- a/content/zh/docs/reference/scheduling/config.md +++ b/content/zh/docs/reference/scheduling/config.md @@ -22,7 +22,7 @@ file and passing its path as a command line argument. 调度模板（Profile）允许你配置 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} @@ -31,17 +31,19 @@ by implementing one or more of these extension points. 你可以通过运行 `kube-scheduler --config ` 来设置调度模板， -使用 [KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 结构体。 +使用 KubeSchedulerConfiguration （[v1beta2](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/) +或者 [v1beta3](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/)） 结构体。 最简单的配置如下： ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig @@ -77,62 +79,74 @@ extension points: 调度行为发生在一系列阶段中，这些阶段是通过以下扩展点公开的： -1. `QueueSort`：这些插件对调度队列中的悬决的 Pod 排序。 +1. `queueSort`：这些插件对调度队列中的悬决的 Pod 排序。 一次只能启用一个队列排序插件。 -2. `PreFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 +2. `preFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 它们可以将 Pod 标记为不可调度。 -3. `Filter`：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。 +3. `filter`：这些插件相当于调度策略中的断言（Predicates），用于过滤不能运行 Pod 的节点。 过滤器的调用顺序是可配置的。 如果没有一个节点通过所有过滤器的筛选，Pod 将会被标记为不可调度。 +4. `postFilter`：当无法为 Pod 找到可用节点时，按照这些插件的配置顺序调用他们。 + 如果任何 `postFilter` 插件将 Pod 标记为“可调度”，则不会调用其余插件。 + -4. `PreScore`：这是一个信息扩展点，可用于预打分工作。 +5. `preScore`：这是一个信息扩展点，可用于预打分工作。 -5. `Score`：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。 +6. `score`：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。 -6. `Reserve`：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。 +7. `reserve`：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。 这些插件还实现了 `Unreserve` 接口，在 `Reserve` 期间或之后出现故障时调用。 - -7. `Permit`：这些插件可以阻止或延迟 Pod 绑定。 - -8. `PreBind`：这些插件在 Pod 绑定节点之前执行。 + +8. `permit`：这些插件可以阻止或延迟 Pod 绑定。 + +9. `preBind`：这些插件在 Pod 绑定节点之前执行。 -9. `Bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。 +10. `bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。 -10. `PostBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。 +11. `postBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。 + +12. `multiPoint`：这是一个仅配置字段，允许同时为所有适用的扩展点启用或禁用插件。 -### 调度插件 {#scheduling-plugin} - - -1. `UnReserve`：这是一个信息扩展点，如果一个 Pod 在预留后被拒绝，并且被 `Permit` 插件搁置，它就会被调用。 - - -## 调度插件 {#scheduling-plugins} +### 调度插件 {#scheduling-plugins} 下面默认启用的插件实现了一个或多个扩展点： - -- `SelectorSpread`：对于属于 {{< glossary_tooltip text="Services" term_id="service" >}}、 - {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和 - {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod，偏好跨多个节点部署。 - - 实现的扩展点：`PreScore`，`Score`。 - `ImageLocality`：选择已经存在 Pod 运行所需容器镜像的节点。 - 实现的扩展点：`Score`。 + 实现的扩展点：`score`。 - `TaintToleration`：实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 - 实现的扩展点：`Filter`，`Prescore`，`Score`。 + 实现的扩展点：`filter`，`prescore`，`score`。 - `NodeName`：检查 Pod 指定的节点名称与当前节点是否匹配。 - 实现的扩展点：`Filter`。 + 实现的扩展点：`filter`。 - `NodePorts`：检查 Pod 请求的端口在节点上是否可用。 - 实现的扩展点：`PreFilter`，`Filter`。 - -- `NodePreferAvoidPods`：基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}} - `scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。 + 实现的扩展点：`preFilter`，`filter`。 - 实现的扩展点：`Score`。 - `NodeAffinity`：实现了[节点选择器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) 和[节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)。 - 实现的扩展点：`Filter`，`Score`. + 实现的扩展点：`filter`，`score`. - `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。 - 实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。 + 实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。 - `NodeUnschedulable`：过滤 `.spec.unschedulable` 值为 true 的节点。 - 实现的扩展点：`Filter`。 + 实现的扩展点：`filter`。 - `NodeResourcesFit`：检查节点是否拥有 Pod 请求的所有资源。 + 得分可以使用以下三种策略之一：`LeastAllocated`（默认）、`MostAllocated` + 和`RequestedToCapacityRatio`。 - 实现的扩展点：`PreFilter`，`Filter`。 + 实现的扩展点：`preFilter`，`filter`，`score`。 - `NodeResourcesBalancedAllocation`：调度 Pod 时，选择资源使用更为均衡的节点。 - 实现的扩展点：`Score`。 - -- `NodeResourcesLeastAllocated`：选择资源分配较少的节点。 + 实现的扩展点：`score`。 - 实现的扩展点：`Score`。 - `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的卷。 - 实现的扩展点: `PreFilter`、`Filter`、`Reserve`、`PreBind` 和 `Score`。 + 实现的扩展点: `preFilter`、`filter`、`reserve`、`preBind` 和 `score`。 {{< note >}} - 当 `VolumeCapacityPriority` 特性被启用时，`Score` 扩展点也被启用。 + 当 `VolumeCapacityPriority` 特性被启用时，`score` 扩展点也被启用。 它优先考虑可以满足所需卷大小的最小 PV。 {{< /note >}} - `VolumeRestrictions`：检查挂载到节点上的卷是否满足卷提供程序的限制。 - 实现的扩展点：`Filter`。 + 实现的扩展点：`filter`。 - `VolumeZone`：检查请求的卷是否在任何区域都满足。 - 实现的扩展点：`Filter`。 + 实现的扩展点：`filter`。 - `NodeVolumeLimits`：检查该节点是否满足 CSI 卷限制。 - 实现的扩展点：`Filter`。 + 实现的扩展点：`filter`。 - `EBSLimits`：检查节点是否满足 AWS EBS 卷限制。 - 实现的扩展点：`Filter`。 + 实现的扩展点：`filter`。 - `GCEPDLimits`：检查该节点是否满足 GCP-PD 卷限制。 - 实现的扩展点：`Filter`。 + 实现的扩展点：`filter`。 - `AzureDiskLimits`：检查该节点是否满足 Azure 卷限制。 - 实现的扩展点：`Filter`。 + 实现的扩展点：`filter`。 - `InterPodAffinity`：实现 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。 - 实现的扩展点：`PreFilter`，`Filter`，`PreScore`，`Score`。 + 实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。 - `PrioritySort`：提供默认的基于优先级的排序。 - 实现的扩展点：`QueueSort`。 + 实现的扩展点：`queueSort`。 - `DefaultBinder`：提供默认的绑定机制。 - 实现的扩展点：`Bind`。 + 实现的扩展点：`bind`。 - `DefaultPreemption`：提供默认的抢占机制。 - 实现的扩展点：`PostFilter`。 + 实现的扩展点：`postFilter`。 你也可以通过组件配置 API 启用以下插件（默认不启用）: - -- `NodeResourcesMostAllocated`：选择已分配资源多的节点。 +- `SelectorSpread`：偏向把属于 + {{< glossary_tooltip text="Services" term_id="service" >}}， + {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} 和 + {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} 的 Pod 跨节点分布。 - 实现的扩展点：`Score`。 - -- `RequestedToCapacityRatio`：根据已分配资源的某函数设置选择节点。 +-`CinderLimits`：检查是否可以满足节点的 [OpenStack Cinder](https://docs.openstack.org/cinder/) +卷限制 - 实现的扩展点：`Score`。 - -- `CinderVolume`：检查该节点是否满足 OpenStack Cinder 卷限制。 - 实现的扩展点：`Filter`。 - -- `NodeLabel`：根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}} - 过滤节点和/或给节点打分。 - - 实现的扩展点：`Filter`，`Score`。 - -- `ServiceAffinity`：检查属于某个 {{< glossary_tooltip term_id="service" >}} 的 Pod - 与配置的标签所定义的节点集是否适配。 - 这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。 - - 实现的扩展点：`PreFilter`，`Filter`，`Score`。 - - ### 多配置文件 {#multiple-profiles} -所有配置文件必须在 QueueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。 +所有配置文件必须在 queueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。 这是因为调度器只有一个保存 pending 状态 Pod 的队列。 {{< /note >}} + + +### 应用于多个扩展点的插件 {#multipoint} + + +从 `kubescheduler.config.k8s.io/v1beta3` 开始，配置文件配置中有一个附加字段 `multiPoint`，它允许跨多个扩展点轻松启用或禁用插件。 +`multiPoint` 配置的目的是简化用户和管理员在使用自定义配置文件时所需的配置。 + + + +考虑一个插件，`MyPlugin`，它实现了 `preScore`、`score`、`preFilter` 和 `filter` 扩展点。 +要为其所有可用的扩展点启用 `MyPlugin`，配置文件配置如下所示： + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: MyPlugin +``` + + + +这相当于为所有扩展点手动启用`MyPlugin`，如下所示： + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: non-multipoint-scheduler + plugins: + preScore: + enabled: + - name: MyPlugin + score: + enabled: + - name: MyPlugin + preFilter: + enabled: + - name: MyPlugin + filter: + enabled: + - name: MyPlugin +``` + + + +在这里使用 `multiPoint` 的一个好处是，如果 `MyPlugin` 将来实现另一个扩展点，`multiPoint` 配置将自动为新扩展启用它。 + + + +可以使用该扩展点的 `disabled` 字段将特定扩展点从 `MultiPoint` 扩展中排除。 +这适用于禁用默认插件、非默认插件或使用通配符 (`'*'`) 来禁用所有插件。 +禁用 `Score` 和 `PreScore` 的一个例子是： + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: non-multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: 'MyPlugin' + preScore: + disabled: + - name: '*' + score: + disabled: + - name: '*' +``` + + + +在 `v1beta3` 中，所有 [默认插件](#scheduling-plugins) 都通过 `MultiPoint` 在内部启用。 +但是，仍然可以使用单独的扩展点来灵活地重新配置默认值（例如排序和分数权重）。 +例如，考虑两个Score插件 `DefaultScore1` 和 `DefaultScore2` ，每个插件的权重为 `1` 。 +它们可以用不同的权重重新排序，如下所示： + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + score: + enabled: + - name: 'DefaultScore2' + weight: 5 +``` + + + +在这个例子中，没有必要在 `MultiPoint` 中明确指定插件，因为它们是默认插件。 +`Score` 中指定的唯一插件是 `DefaultScore2`。 +这是因为通过特定扩展点设置的插件将始终优先于 `MultiPoint` 插件。 +因此，此代码段实质上重新排序了这两个插件，而无需同时指定它们。 + + + +配置 `MultiPoint` 插件时优先级的一般层次结构如下： + + +1. 特定的扩展点首先运行，它们的设置会覆盖其他地方的设置 + + +2. 通过 `MultiPoint` 手动配置的插件及其设置 + + +3. 默认插件及其默认设置 + + +为了演示上述层次结构，以下示例基于这些插件： +|插件|扩展点| +|---|---| +|`DefaultQueueSort`|`QueueSort`| +|`CustomQueueSort`|`QueueSort`| +|`DefaultPlugin1`|`Score`, `Filter`| +|`DefaultPlugin2`|`Score`| +|`CustomPlugin1`|`Score`, `Filter`| +|`CustomPlugin2`|`Score`, `Filter`| + + +这些插件的一个有效示例配置是： + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + multiPoint: + enabled: + - name: 'CustomQueueSort' + - name: 'CustomPlugin1' + weight: 3 + - name: 'CustomPlugin2' + disabled: + - name: 'DefaultQueueSort' + filter: + disabled: + - name: 'DefaultPlugin1' + score: + enabled: + - name: 'DefaultPlugin2' +``` + + +请注意，在特定扩展点中重新声明 `MultiPoint` 插件不会出错。 +重新声明被忽略（并记录），因为特定的扩展点优先。 + + + +除了将大部分配置保存在一个位置之外，此示例还做了一些事情： + + +* 启用自定义 `queueSort` 插件并禁用默认插件 + +* 启用 `CustomPlugin1` 和 `CustomPlugin2`，这将首先为它们的所有扩展点运行 + +* 禁用 `DefaultPlugin1`，但仅适用于 `filter` + +* 重新排序 `DefaultPlugin2` 以在 `score` 中首先运行（甚至在自定义插件之前） + + +在 `v1beta3` 之前的配置版本中，没有 `multiPoint`，上面的代码片段等同于： + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta2 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: multipoint-scheduler + plugins: + + # Disable the default QueueSort plugin + queueSort: + enabled: + - name: 'CustomQueueSort' + disabled: + - name: 'DefaultQueueSort' + + # Enable custom Filter plugins + filter: + enabled: + - name: 'CustomPlugin1' + - name: 'CustomPlugin2' + - name: 'DefaultPlugin2' + disabled: + - name: 'DefaultPlugin1' + + # Enable and reorder custom score plugins + score: + enabled: + - name: 'DefaultPlugin2' + weight: 1 + - name: 'DefaultPlugin1' + weight: 3 +``` + + + +虽然这是一个复杂的例子，但它展示了 `MultiPoint` 配置的灵活性以及它与配置扩展点的现有方法的无缝集成。 + + + +## 调度程序配置迁移 +{{< tabs name="tab_with_md" >}} +{{% tab name="v1beta1 → v1beta2" %}} + +* 在 v1beta2 配置版本中，你可以为 `NodeResourcesFit` 插件使用新的 score 扩展。 + 新的扩展结合了 `NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated` 和 `RequestedToCapacityRatio` 插件的功能。 + 例如，如果你之前使用了 `NodeResourcesMostAllocated` 插件， + 则可以改用 `NodeResourcesFit`（默认启用）并添加一个 `pluginConfig` 和 `scoreStrategy`，类似于： + + ```yaml + apiVersion: kubescheduler.config.k8s.io/v1beta2 + kind: KubeSchedulerConfiguration + profiles: + - pluginConfig: + - args: + scoringStrategy: + resources: + - name: cpu + weight: 1 + type: MostAllocated + name: NodeResourcesFit + ``` + + +* 调度器插件 `NodeLabel` 已弃用； + 相反，要使用 [`NodeAffinity`](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) + 插件（默认启用）来实现类似的行为。 + + +* 调度程序插件 `ServiceAffinity` 已弃用； + 相反，使用 [`InterPodAffinity`](/zh/doc/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) + 插件（默认启用）来实现类似的行为。 + + +* 调度器插件 `NodePreferAvoidPods` 已弃用； + 相反，使用 [节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) 来实现类似的行为。 + + +* 在 v1beta2 配置文件中启用的插件优先于该插件的默认配置。 + + +* 调度器的健康检查和审计的绑定地址，所配置的 `host` 或 `port` 无效将导致验证失败。 + +{{% /tab %}} + +{{% tab name="v1beta2 → v1beta3" %}} + +* 默认增加三个插件的权重： + * `InterPodAffinity` 从 1 到 2 + * `NodeAffinity` 从 1 到 2 + * `TaintToleration` 从 1 到 3 +{{% /tab %}} +{{< /tabs >}} + ## {{% heading "whatsnext" %}} * 阅读 [kube-scheduler 参考](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) * 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) -* 阅读 [kube-scheduler 配置 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) 参考 - +* 阅读 [kube-scheduler 配置 (v1beta2)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/) 参考 +* 阅读 [kube-scheduler 配置 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) 参考