From 044e1f9c8556c53b8475f09e5e3cf238c59bdaea Mon Sep 17 00:00:00 2001 From: ydFu Date: Thu, 18 Aug 2022 10:57:04 +0800 Subject: [PATCH] [zh] Update reference\scheduling\config.md Signed-off-by: ydFu --- .../zh-cn/docs/reference/scheduling/config.md | 212 ++++++++++-------- 1 file changed, 115 insertions(+), 97 deletions(-) diff --git a/content/zh-cn/docs/reference/scheduling/config.md b/content/zh-cn/docs/reference/scheduling/config.md index b79b23e2e9e..1c751d4b924 100644 --- a/content/zh-cn/docs/reference/scheduling/config.md +++ b/content/zh-cn/docs/reference/scheduling/config.md @@ -39,7 +39,9 @@ struct. 使用 KubeSchedulerConfiguration （[v1beta2](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta2/) 或者 [v1beta3](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/)） 结构体。 - + 最简单的配置如下： ```yaml @@ -49,10 +51,12 @@ clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig ``` - + ## 配置文件 {#profiles} - 你可以配置同一 `kube-scheduler` 实例使用[多个配置文件](#multiple-profiles)。 - + ### 扩展点 {#extensions-points} - 调度行为发生在一系列阶段中，这些阶段是通过以下扩展点公开的： - 2. `preFilter`：这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。 它们可以将 Pod 标记为不可调度。 4. `postFilter`：当无法为 Pod 找到可用节点时，按照这些插件的配置顺序调用他们。 - 如果任何 `postFilter` 插件将 Pod 标记为“可调度”，则不会调用其余插件。 + 如果任何 `postFilter` 插件将 Pod 标记为**可调度**，则不会调用其余插件。 5. `preScore`：这是一个信息扩展点，可用于预打分工作。 - 6. `score`：这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。 - 7. `reserve`：这是一个信息扩展点，当资源已经预留给 Pod 时，会通知插件。 这些插件还实现了 `Unreserve` 接口，在 `Reserve` 期间或之后出现故障时调用。 - + 8. `permit`：这些插件可以阻止或延迟 Pod 绑定。 - + 9. `preBind`：这些插件在 Pod 绑定节点之前执行。 - -10. `bind`：这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。绑定插件至少需要一个。 +10. `bind`：这个插件将 Pod 与节点绑定。`bind` 插件是按顺序调用的，只要有一个插件完成了绑定，其余插件都会跳过。`bind` 插件至少需要一个。 11. `postBind`：这是一个信息扩展点，在 Pod 绑定了节点之后调用。 12. `multiPoint`：这是一个仅配置字段，允许同时为所有适用的扩展点启用或禁用插件。 @@ -177,16 +187,18 @@ desired. 你可以在 `disabled` 数组中使用 `*` 禁用该扩展点的所有默认插件。 如果需要，这个字段也可以用来对插件重新顺序。 - + ### 调度插件 {#scheduling-plugins} - 下面默认启用的插件实现了一个或多个扩展点： - - `TaintToleration`：实现了[污点和容忍](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 - 实现的扩展点：`filter`，`prescore`，`score`。 - - `NodeName`：检查 Pod 指定的节点名称与当前节点是否匹配。 实现的扩展点：`filter`。 - - `NodePorts`：检查 Pod 请求的端口在节点上是否可用。 - 实现的扩展点：`preFilter`，`filter`。 + 实现的扩展点：`preFilter`、`filter`。 - - `PodTopologySpread`：实现了 [Pod 拓扑分布](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)。 - 实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。 - +- `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的{{< glossary_tooltip text="卷" term_id="volume" >}}。 + 实现的扩展点：`preFilter`、`filter`、`reserve`、`preBind` 和 `score`。 + {{< note >}} + -- `VolumeBinding`：检查节点是否有请求的卷，或是否可以绑定请求的卷。 - 实现的扩展点: `preFilter`、`filter`、`reserve`、`preBind` 和 `score`。 - {{< note >}} + --> 当 `VolumeCapacityPriority` 特性被启用时，`score` 扩展点也被启用。 它优先考虑可以满足所需卷大小的最小 PV。 {{< /note >}} @@ -288,7 +308,8 @@ extension points: - `VolumeRestrictions`：检查挂载到节点上的卷是否满足卷提供程序的限制。 实现的扩展点：`filter`。 - - `EBSLimits`：检查节点是否满足 AWS EBS 卷限制。 实现的扩展点：`filter`。 - - `GCEPDLimits`：检查该节点是否满足 GCP-PD 卷限制。 实现的扩展点：`filter`。 - - `InterPodAffinity`：实现 [Pod 间亲和性与反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)。 - 实现的扩展点：`preFilter`，`filter`，`preScore`，`score`。 - - `PrioritySort`：提供默认的基于优先级的排序。 实现的扩展点：`queueSort`。 - - `DefaultBinder`：提供默认的绑定机制。 实现的扩展点：`bind`。 - - `DefaultPreemption`：提供默认的抢占机制。 实现的扩展点：`postFilter`。 - -你也可以通过组件配置 API 启用以下插件（默认不启用）: +你也可以通过组件配置 API 启用以下插件（默认不启用）： -- `CinderLimits`：检查是否可以满足节点的 [OpenStack Cinder](https://docs.openstack.org/cinder/) -卷限制 +- `CinderLimits`：检查是否可以满足节点的 [OpenStack Cinder](https://docs.openstack.org/cinder/) 卷限制。 + 实现的扩展点：`filter`。 + +### 多配置文件 {#multiple-profiles} + 你可以配置 `kube-scheduler` 运行多个配置文件。 每个配置文件都有一个关联的调度器名称，并且可以在其扩展点中配置一组不同的插件。 - 对于那些希望根据特定配置文件来进行调度的 Pod，可以在 `.spec.schedulerName` 字段指定相应的调度器名称。 - -所有配置文件必须在 queueSort 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。 +所有配置文件必须在 `queueSort` 扩展点使用相同的插件，并具有相同的配置参数（如果适用）。 这是因为调度器只有一个保存 pending 状态 Pod 的队列。 - {{< /note >}} - ### 应用于多个扩展点的插件 {#multipoint} - 考虑一个插件，`MyPlugin`，它实现了 `preScore`、`score`、`preFilter` 和 `filter` 扩展点。 要为其所有可用的扩展点启用 `MyPlugin`，配置文件配置如下所示： @@ -500,7 +527,6 @@ profiles: This would equate to manually enabling `MyPlugin` for all of its extension points, like so: --> - 这相当于为所有扩展点手动启用 `MyPlugin`，如下所示： ```yaml @@ -528,7 +554,6 @@ One benefit of using `multiPoint` here is that if `MyPlugin` implements another extension point in the future, the `multiPoint` config will automatically enable it for the new extension. --> - 在这里使用 `multiPoint` 的一个好处是，如果 `MyPlugin` 将来实现另一个扩展点，`multiPoint` 配置将自动为新扩展启用它。 - 可以使用该扩展点的 `disabled` 字段将特定扩展点从 `MultiPoint` 扩展中排除。 这适用于禁用默认插件、非默认插件或使用通配符 (`'*'`) 来禁用所有插件。 禁用 `Score` 和 `PreScore` 的一个例子是： @@ -566,7 +590,6 @@ reconfiguration of the default values (such as ordering and Score weights). For example, consider two Score plugins `DefaultScore1` and `DefaultScore2`, each with a weight of `1`. They can be reordered with different weights like so: --> - 在 `v1beta3` 中，所有 [默认插件](#scheduling-plugins) 都通过 `MultiPoint` 在内部启用。 但是，仍然可以使用单独的扩展点来灵活地重新配置默认值（例如排序和分数权重）。 例如，考虑两个Score插件 `DefaultScore1` 和 `DefaultScore2` ，每个插件的权重为 `1` 。 @@ -591,33 +614,33 @@ This is because plugins set through specific extension points will always take p over `MultiPoint` plugins. So, this snippet essentially re-orders the two plugins without needing to specify both of them. --> - 在这个例子中，没有必要在 `MultiPoint` 中明确指定插件，因为它们是默认插件。 `Score` 中指定的唯一插件是 `DefaultScore2`。 这是因为通过特定扩展点设置的插件将始终优先于 `MultiPoint` 插件。 因此，此代码段实质上重新排序了这两个插件，而无需同时指定它们。 - 配置 `MultiPoint` 插件时优先级的一般层次结构如下： - 1. 特定的扩展点首先运行，它们的设置会覆盖其他地方的设置 - - 2. 通过 `MultiPoint` 手动配置的插件及其设置 - - 3. 默认插件及其默认设置 为了演示上述层次结构，以下示例基于这些插件： |插件|扩展点| @@ -667,7 +690,6 @@ take precedence. - 除了将大部分配置保存在一个位置之外，此示例还做了一些事情： * 启用自定义 `queueSort` 插件并禁用默认插件 - * 启用 `CustomPlugin1` 和 `CustomPlugin2`，这将首先为它们的所有扩展点运行 - * 禁用 `DefaultPlugin1`，但仅适用于 `filter` - * 重新排序 `DefaultPlugin2` 以在 `score` 中首先运行（甚至在自定义插件之前） - 虽然这是一个复杂的例子，但它展示了 `MultiPoint` 配置的灵活性以及它与配置扩展点的现有方法的无缝集成。 - ## 调度程序配置迁移 {#scheduler-configuration-migrations} {{< tabs name="tab_with_md" >}} {{% tab name="v1beta1 → v1beta2" %}} +