Update scheduling/config.md
This commit is contained in:
@@ -22,7 +22,7 @@ file and passing its path as a command line argument.
|
||||
<!--
|
||||
A scheduling Profile allows you to configure the different stages of scheduling
|
||||
in the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}.
|
||||
Each stage is exposed in a extension point. Plugins provide scheduling behaviors
|
||||
Each stage is exposed in an extension point. Plugins provide scheduling behaviors
|
||||
by implementing one or more of these extension points.
|
||||
-->
|
||||
调度模板(Profile)允许你配置 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}
|
||||
@@ -31,17 +31,19 @@ by implementing one or more of these extension points.
|
||||
<!--
|
||||
You can specify scheduling profiles by running `kube-scheduler --config <filename>`,
|
||||
using the
|
||||
[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
|
||||
KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
|
||||
or [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/))
|
||||
struct.
|
||||
-->
|
||||
你可以通过运行 `kube-scheduler --config <filename>` 来设置调度模板,
|
||||
使用 [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/)) 结构体。
|
||||
|
||||
<!-- A minimal configuration looks as follows: -->
|
||||
最简单的配置如下:
|
||||
|
||||
```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`: These plugins provide an ordering function that is used to
|
||||
1. `queueSort`: These plugins provide an ordering function that is used to
|
||||
sort pending Pods in the scheduling queue. Exactly one queue sort plugin
|
||||
may be enabled at a time.
|
||||
-->
|
||||
1. `QueueSort`:这些插件对调度队列中的悬决的 Pod 排序。
|
||||
1. `queueSort`:这些插件对调度队列中的悬决的 Pod 排序。
|
||||
一次只能启用一个队列排序插件。
|
||||
<!--
|
||||
2. `PreFilter`: These plugins are used to pre-process or check information
|
||||
2. `preFilter`: These plugins are used to pre-process or check information
|
||||
about a Pod or the cluster before filtering. They can mark a pod as
|
||||
unschedulable.
|
||||
-->
|
||||
2. `PreFilter`:这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
|
||||
2. `preFilter`:这些插件用于在过滤之前预处理或检查 Pod 或集群的信息。
|
||||
它们可以将 Pod 标记为不可调度。
|
||||
<!--
|
||||
3. `Filter`: These plugins are the equivalent of Predicates in a scheduling
|
||||
3. `filter`: These plugins are the equivalent of Predicates in a scheduling
|
||||
Policy and are used to filter out nodes that can not run the Pod. Filters
|
||||
are called in the configured order. A pod is marked as unschedulable if no
|
||||
nodes pass all the filters.
|
||||
-->
|
||||
3. `Filter`:这些插件相当于调度策略中的断言(Predicates),用于过滤不能运行 Pod 的节点。
|
||||
3. `filter`:这些插件相当于调度策略中的断言(Predicates),用于过滤不能运行 Pod 的节点。
|
||||
过滤器的调用顺序是可配置的。
|
||||
如果没有一个节点通过所有过滤器的筛选,Pod 将会被标记为不可调度。
|
||||
<!--
|
||||
4. `PreScore`: This is an informational extension point that can be used
|
||||
4. `postFilter`: These plugins are called in their configured order when no
|
||||
feasible nodes were found for the pod. If any `postFilter` plugin marks the
|
||||
Pod _schedulable_, the remaining plugins are not called.
|
||||
-->
|
||||
4. `postFilter`:当无法为 Pod 找到可用节点时,按照这些插件的配置顺序调用他们。
|
||||
如果任何 `postFilter` 插件将 Pod 标记为“可调度”,则不会调用其余插件。
|
||||
<!--
|
||||
1. `preScore`: This is an informational extension point that can be used
|
||||
for doing pre-scoring work.
|
||||
-->
|
||||
4. `PreScore`:这是一个信息扩展点,可用于预打分工作。
|
||||
5. `preScore`:这是一个信息扩展点,可用于预打分工作。
|
||||
<!--
|
||||
5. `Score`: These plugins provide a score to each node that has passed the
|
||||
6. `score`: These plugins provide a score to each node that has passed the
|
||||
filtering phase. The scheduler will then select the node with the highest
|
||||
weighted scores sum.
|
||||
-->
|
||||
5. `Score`:这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
|
||||
6. `score`:这些插件给通过筛选阶段的节点打分。调度器会选择得分最高的节点。
|
||||
<!--
|
||||
6. `Reserve`: This is an informational extension point that notifies plugins
|
||||
7. `reserve`: This is an informational extension point that notifies plugins
|
||||
when resources have been reserved for a given Pod. Plugins also implement an
|
||||
`Unreserve` call that gets called in the case of failure during or after
|
||||
`Reserve`.
|
||||
-->
|
||||
6. `Reserve`:这是一个信息扩展点,当资源已经预留给 Pod 时,会通知插件。
|
||||
7. `reserve`:这是一个信息扩展点,当资源已经预留给 Pod 时,会通知插件。
|
||||
这些插件还实现了 `Unreserve` 接口,在 `Reserve` 期间或之后出现故障时调用。
|
||||
<!-- 7. `Permit`: These plugins can prevent or delay the binding of a Pod. -->
|
||||
7. `Permit`:这些插件可以阻止或延迟 Pod 绑定。
|
||||
<!-- 8. `PreBind`: These plugins perform any work required before a Pod is bound.-->
|
||||
8. `PreBind`:这些插件在 Pod 绑定节点之前执行。
|
||||
<!-- 8. `permit`: These plugins can prevent or delay the binding of a Pod. -->
|
||||
8. `permit`:这些插件可以阻止或延迟 Pod 绑定。
|
||||
<!-- 9. `preBind`: These plugins perform any work required before a Pod is bound.-->
|
||||
9. `preBind`:这些插件在 Pod 绑定节点之前执行。
|
||||
<!--
|
||||
9. `Bind`: The plugins bind a Pod to a Node. Bind plugins are called in order
|
||||
10. `bind`: The plugins bind a Pod to a Node. Bind plugins are called in order
|
||||
and once one has done the binding, the remaining plugins are skipped. At
|
||||
least one bind plugin is required.
|
||||
-->
|
||||
9. `Bind`:这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的,只要有一个插件完成了绑定,其余插件都会跳过。绑定插件至少需要一个。
|
||||
10. `bind`:这个插件将 Pod 与节点绑定。绑定插件是按顺序调用的,只要有一个插件完成了绑定,其余插件都会跳过。绑定插件至少需要一个。
|
||||
<!--
|
||||
10. `PostBind`: This is an informational extension point that is called after
|
||||
11. `postBind`: This is an informational extension point that is called after
|
||||
a Pod has been bound.
|
||||
-->
|
||||
10. `PostBind`:这是一个信息扩展点,在 Pod 绑定了节点之后调用。
|
||||
11. `postBind`:这是一个信息扩展点,在 Pod 绑定了节点之后调用。
|
||||
<!--
|
||||
12. `multiPoint`: This is a config-only field that allows plugins to be enabled
|
||||
or disabled for all of their applicable extension points simultaneously.
|
||||
-->
|
||||
12. `multiPoint`:这是一个仅配置字段,允许同时为所有适用的扩展点启用或禁用插件。
|
||||
|
||||
<!--
|
||||
For each extension point, you could disable specific [default plugins](#scheduling-plugins)
|
||||
@@ -141,13 +155,13 @@ or enable your own. For example:
|
||||
对每个扩展点,你可以禁用[默认插件](#scheduling-plugins)或者是启用自己的插件,例如:
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta1
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta2
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- plugins:
|
||||
score:
|
||||
disabled:
|
||||
- name: NodeResourcesLeastAllocated
|
||||
- name: PodTopologySpread
|
||||
enabled:
|
||||
- name: MyCustomPluginA
|
||||
weight: 2
|
||||
@@ -164,16 +178,7 @@ desired.
|
||||
如果需要,这个字段也可以用来对插件重新顺序。
|
||||
|
||||
<!-- ### Scheduling plugins -->
|
||||
### 调度插件 {#scheduling-plugin}
|
||||
|
||||
<!--
|
||||
1. `UnReserve`: This is an informational extension point that is called if
|
||||
a Pod is rejected after being reserved and put on hold by a `Permit` plugin.
|
||||
-->
|
||||
1. `UnReserve`:这是一个信息扩展点,如果一个 Pod 在预留后被拒绝,并且被 `Permit` 插件搁置,它就会被调用。
|
||||
|
||||
<!-- ## Scheduling plugins -->
|
||||
## 调度插件 {#scheduling-plugins}
|
||||
### 调度插件 {#scheduling-plugins}
|
||||
|
||||
<!--
|
||||
The following plugins, enabled by default, implement one or more of these
|
||||
@@ -181,200 +186,175 @@ extension points:
|
||||
-->
|
||||
下面默认启用的插件实现了一个或多个扩展点:
|
||||
|
||||
<!--
|
||||
- `SelectorSpread`: Favors spreading across nodes for Pods that belong to
|
||||
{{< glossary_tooltip text="Services" term_id="service" >}},
|
||||
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and
|
||||
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}.
|
||||
Extension points: `PreScore`, `Score`.
|
||||
-->
|
||||
- `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`: Favors nodes that already have the container images that the
|
||||
Pod runs.
|
||||
Extension points: `Score`.
|
||||
Extension points: `score`.
|
||||
-->
|
||||
- `ImageLocality`:选择已经存在 Pod 运行所需容器镜像的节点。
|
||||
|
||||
实现的扩展点:`Score`。
|
||||
实现的扩展点:`score`。
|
||||
<!--
|
||||
- `TaintToleration`: Implements
|
||||
[taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
Implements extension points: `Filter`, `Prescore`, `Score`.
|
||||
Implements extension points: `filter`, `prescore`, `score`.
|
||||
-->
|
||||
- `TaintToleration`:实现了[污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。
|
||||
|
||||
实现的扩展点:`Filter`,`Prescore`,`Score`。
|
||||
实现的扩展点:`filter`,`prescore`,`score`。
|
||||
<!--
|
||||
- `NodeName`: Checks if a Pod spec node name matches the current node.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `NodeName`:检查 Pod 指定的节点名称与当前节点是否匹配。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
实现的扩展点:`filter`。
|
||||
<!--
|
||||
- `NodePorts`: Checks if a node has free ports for the requested Pod ports.
|
||||
Extension points: `PreFilter`, `Filter`.
|
||||
Extension points: `preFilter`, `filter`.
|
||||
-->
|
||||
- `NodePorts`:检查 Pod 请求的端口在节点上是否可用。
|
||||
|
||||
实现的扩展点:`PreFilter`,`Filter`。
|
||||
<!--
|
||||
- `NodePreferAvoidPods`: Scores nodes according to the node
|
||||
{{< glossary_tooltip text=" " term_id="annotation" >}}
|
||||
`scheduler.alpha.kubernetes.io/preferAvoidPods`.
|
||||
Extension points: `Score`.
|
||||
-->
|
||||
- `NodePreferAvoidPods`:基于节点的 {{< glossary_tooltip text="注解" term_id="annotation" >}}
|
||||
`scheduler.alpha.kubernetes.io/preferAvoidPods` 打分。
|
||||
实现的扩展点:`preFilter`,`filter`。
|
||||
|
||||
实现的扩展点:`Score`。
|
||||
<!--
|
||||
- `NodeAffinity`: Implements
|
||||
[node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)
|
||||
and [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity).
|
||||
Extension points: `Filter`, `Score`.
|
||||
Extension points: `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`: Implements
|
||||
[Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
|
||||
Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`.
|
||||
Extension points: `preFilter`, `filter`, `preScore`, `score`.
|
||||
-->
|
||||
- `PodTopologySpread`:实现了 [Pod 拓扑分布](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)。
|
||||
|
||||
实现的扩展点:`PreFilter`,`Filter`,`PreScore`,`Score`。
|
||||
实现的扩展点:`preFilter`,`filter`,`preScore`,`score`。
|
||||
<!--
|
||||
- `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to
|
||||
true.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `NodeUnschedulable`:过滤 `.spec.unschedulable` 值为 true 的节点。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
实现的扩展点:`filter`。
|
||||
<!--
|
||||
- `NodeResourcesFit`: Checks if the node has all the resources that the Pod is
|
||||
requesting.
|
||||
Extension points: `PreFilter`, `Filter`.
|
||||
requesting. The score can use one of three strategies: `LeastAllocated`
|
||||
(default), `MostAllocated` and `RequestedToCapacityRatio`.
|
||||
Extension points: `preFilter`, `filter`, `score`.
|
||||
-->
|
||||
- `NodeResourcesFit`:检查节点是否拥有 Pod 请求的所有资源。
|
||||
得分可以使用以下三种策略之一:`LeastAllocated`(默认)、`MostAllocated`
|
||||
和`RequestedToCapacityRatio`。
|
||||
|
||||
实现的扩展点:`PreFilter`,`Filter`。
|
||||
实现的扩展点:`preFilter`,`filter`,`score`。
|
||||
<!--
|
||||
- `NodeResourcesBalancedAllocation`: Favors nodes that would obtain a more
|
||||
balanced resource usage if the Pod is scheduled there.
|
||||
Extension points: `Score`.
|
||||
Extension points: `score`.
|
||||
-->
|
||||
- `NodeResourcesBalancedAllocation`:调度 Pod 时,选择资源使用更为均衡的节点。
|
||||
|
||||
实现的扩展点:`Score`。
|
||||
<!--
|
||||
- `NodeResourcesLeastAllocated`: Favors nodes that have a low allocation of
|
||||
resources.
|
||||
Extension points: `Score`.
|
||||
-->
|
||||
- `NodeResourcesLeastAllocated`:选择资源分配较少的节点。
|
||||
实现的扩展点:`score`。
|
||||
|
||||
实现的扩展点:`Score`。
|
||||
<!--
|
||||
- `VolumeBinding`: Checks if the node has or if it can bind the requested
|
||||
{{< glossary_tooltip text="volumes" term_id="volume" >}}.
|
||||
Extension points: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`.
|
||||
Extension points: `preFilter`, `filter`, `reserve`, `preBind`, `score`.
|
||||
{{< note >}}
|
||||
`Score` extension point is enabled when `VolumeCapacityPriority` feature is
|
||||
`score` extension point is enabled when `VolumeCapacityPriority` feature is
|
||||
enabled. It prioritizes the smallest PVs that can fit the requested volume
|
||||
size.
|
||||
{{< /note >}}
|
||||
-->
|
||||
- `VolumeBinding`:检查节点是否有请求的卷,或是否可以绑定请求的卷。
|
||||
实现的扩展点: `PreFilter`、`Filter`、`Reserve`、`PreBind` 和 `Score`。
|
||||
实现的扩展点: `preFilter`、`filter`、`reserve`、`preBind` 和 `score`。
|
||||
{{< note >}}
|
||||
当 `VolumeCapacityPriority` 特性被启用时,`Score` 扩展点也被启用。
|
||||
当 `VolumeCapacityPriority` 特性被启用时,`score` 扩展点也被启用。
|
||||
它优先考虑可以满足所需卷大小的最小 PV。
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
- `VolumeRestrictions`: Checks that volumes mounted in the node satisfy
|
||||
restrictions that are specific to the volume provider.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `VolumeRestrictions`:检查挂载到节点上的卷是否满足卷提供程序的限制。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
实现的扩展点:`filter`。
|
||||
<!--
|
||||
- `VolumeZone`: Checks that volumes requested satisfy any zone requirements they
|
||||
might have.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `VolumeZone`:检查请求的卷是否在任何区域都满足。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
实现的扩展点:`filter`。
|
||||
<!--
|
||||
- `NodeVolumeLimits`: Checks that CSI volume limits can be satisfied for the
|
||||
node.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `NodeVolumeLimits`:检查该节点是否满足 CSI 卷限制。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
实现的扩展点:`filter`。
|
||||
<!--
|
||||
- `EBSLimits`: Checks that AWS EBS volume limits can be satisfied for the node.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `EBSLimits`:检查节点是否满足 AWS EBS 卷限制。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
实现的扩展点:`filter`。
|
||||
<!--
|
||||
- `GCEPDLimits`: Checks that GCP-PD volume limits can be satisfied for the node.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `GCEPDLimits`:检查该节点是否满足 GCP-PD 卷限制。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
实现的扩展点:`filter`。
|
||||
<!--
|
||||
- `AzureDiskLimits`: Checks that Azure disk volume limits can be satisfied for
|
||||
the node.
|
||||
Extension points: `Filter`.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `AzureDiskLimits`:检查该节点是否满足 Azure 卷限制。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
实现的扩展点:`filter`。
|
||||
<!--
|
||||
- `InterPodAffinity`: Implements
|
||||
[inter-Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity).
|
||||
Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`.
|
||||
Extension points: `preFilter`, `filter`, `preScore`, `score`.
|
||||
-->
|
||||
- `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`: Provides the default priority based sorting.
|
||||
Extension points: `QueueSort`.
|
||||
Extension points: `queueSort`.
|
||||
-->
|
||||
- `PrioritySort`:提供默认的基于优先级的排序。
|
||||
|
||||
实现的扩展点:`QueueSort`。
|
||||
实现的扩展点:`queueSort`。
|
||||
<!--
|
||||
- `DefaultBinder`: Provides the default binding mechanism.
|
||||
Extension points: `Bind`.
|
||||
Extension points: `bind`.
|
||||
-->
|
||||
- `DefaultBinder`:提供默认的绑定机制。
|
||||
|
||||
实现的扩展点:`Bind`。
|
||||
实现的扩展点:`bind`。
|
||||
<!--
|
||||
- `DefaultPreemption`: Provides the default preemption mechanism.
|
||||
Extension points: `PostFilter`.
|
||||
-->
|
||||
- `DefaultPreemption`:提供默认的抢占机制。
|
||||
|
||||
实现的扩展点:`PostFilter`。
|
||||
实现的扩展点:`postFilter`。
|
||||
|
||||
<!--
|
||||
You can also enable the following plugins, through the component config APIs,
|
||||
@@ -382,53 +362,29 @@ that are not enabled by default:
|
||||
-->
|
||||
你也可以通过组件配置 API 启用以下插件(默认不启用):
|
||||
|
||||
<!--
|
||||
- `NodeResourcesMostAllocated`: Favors nodes that have a high allocation of
|
||||
resources.
|
||||
Extension points: `Score`.
|
||||
<!--
|
||||
- `SelectorSpread`: Favors spreading across nodes for Pods that belong to
|
||||
{{< glossary_tooltip text="Services" term_id="service" >}},
|
||||
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and
|
||||
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}.
|
||||
Extension points: `preScore`, `score`.
|
||||
-->
|
||||
- `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`: Favor nodes according to a configured function of
|
||||
the allocated resources.
|
||||
Extension points: `Score`.
|
||||
实现的扩展点:`preScore`,`score`。
|
||||
|
||||
<!--
|
||||
-`CinderLimits`: Checks that [OpenStack Cinder](https://docs.openstack.org/cinder/)
|
||||
volume limits can be satisfied for the node.
|
||||
Extension points: `filter`.
|
||||
-->
|
||||
- `RequestedToCapacityRatio`:根据已分配资源的某函数设置选择节点。
|
||||
-`CinderLimits`:检查是否可以满足节点的 [OpenStack Cinder](https://docs.openstack.org/cinder/)
|
||||
卷限制
|
||||
|
||||
实现的扩展点:`Score`。
|
||||
<!--
|
||||
- `CinderVolume`: Checks that OpenStack Cinder volume limits can be satisfied
|
||||
for the node.
|
||||
Extension points: `Filter`.
|
||||
-->
|
||||
- `CinderVolume`:检查该节点是否满足 OpenStack Cinder 卷限制。
|
||||
|
||||
实现的扩展点:`Filter`。
|
||||
<!--
|
||||
- `NodeLabel`: Filters and / or scores a node according to configured
|
||||
{{< glossary_tooltip text="label(s)" term_id="label" >}}.
|
||||
Extension points: `Filter`, `Score`.
|
||||
-->
|
||||
- `NodeLabel`:根据配置的 {{< glossary_tooltip text="标签" term_id="label" >}}
|
||||
过滤节点和/或给节点打分。
|
||||
|
||||
实现的扩展点:`Filter`,`Score`。
|
||||
<!--
|
||||
- `ServiceAffinity`: Checks that Pods that belong to a
|
||||
{{< glossary_tooltip term_id="service" >}} fit in a set of nodes defined by
|
||||
configured labels. This plugin also favors spreading the Pods belonging to a
|
||||
Service across nodes.
|
||||
Extension points: `PreFilter`, `Filter`, `Score`.
|
||||
-->
|
||||
- `ServiceAffinity`:检查属于某个 {{< glossary_tooltip term_id="service" >}} 的 Pod
|
||||
与配置的标签所定义的节点集是否适配。
|
||||
这个插件还支持将属于某个 Service 的 Pod 分散到各个节点。
|
||||
|
||||
实现的扩展点:`PreFilter`,`Filter`,`Score`。
|
||||
|
||||
<!-- ### Multiple profiles -->
|
||||
### 多配置文件 {#multiple-profiles}
|
||||
|
||||
<!--
|
||||
@@ -447,7 +403,7 @@ disabled.
|
||||
使用下面的配置样例,调度器将运行两个配置文件:一个使用默认插件,另一个禁用所有打分插件。
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta1
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta2
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: default-scheduler
|
||||
@@ -496,23 +452,372 @@ Pod 的调度事件把 `.spec.schedulerName` 字段值作为 ReportingController
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
All profiles must use the same plugin in the QueueSort extension point and have
|
||||
All profiles must use the same plugin in the queueSort extension point and have
|
||||
the same configuration parameters (if applicable). This is because the scheduler
|
||||
only has one pending pods queue.
|
||||
-->
|
||||
所有配置文件必须在 QueueSort 扩展点使用相同的插件,并具有相同的配置参数(如果适用)。
|
||||
所有配置文件必须在 queueSort 扩展点使用相同的插件,并具有相同的配置参数(如果适用)。
|
||||
这是因为调度器只有一个保存 pending 状态 Pod 的队列。
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
<!--
|
||||
### Plugins that apply to multiple extension points {#multipoint}
|
||||
-->
|
||||
|
||||
### 应用于多个扩展点的插件 {#multipoint}
|
||||
|
||||
<!--
|
||||
Starting from `kubescheduler.config.k8s.io/v1beta3`, there is an additional field in the
|
||||
profile config, `multiPoint`, which allows for easily enabling or disabling a plugin
|
||||
across several extension points. The intent of `multiPoint` config is to simplify the
|
||||
configuration needed for users and administrators when using custom profiles.
|
||||
-->
|
||||
从 `kubescheduler.config.k8s.io/v1beta3` 开始,配置文件配置中有一个附加字段 `multiPoint`,它允许跨多个扩展点轻松启用或禁用插件。
|
||||
`multiPoint` 配置的目的是简化用户和管理员在使用自定义配置文件时所需的配置。
|
||||
|
||||
<!--
|
||||
Consider a plugin, `MyPlugin`, which implements the `preScore`, `score`, `preFilter`,
|
||||
and `filter` extension points. To enable `MyPlugin` for all its available extension
|
||||
points, the profile config looks like:
|
||||
-->
|
||||
|
||||
考虑一个插件,`MyPlugin`,它实现了 `preScore`、`score`、`preFilter` 和 `filter` 扩展点。
|
||||
要为其所有可用的扩展点启用 `MyPlugin`,配置文件配置如下所示:
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: multipoint-scheduler
|
||||
plugins:
|
||||
multiPoint:
|
||||
enabled:
|
||||
- name: MyPlugin
|
||||
```
|
||||
|
||||
<!--
|
||||
This would equate to manually enabling `MyPlugin` for all of its extension
|
||||
points, like so:
|
||||
-->
|
||||
|
||||
这相当于为所有扩展点手动启用`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
|
||||
```
|
||||
|
||||
<!--
|
||||
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` 配置将自动为新扩展启用它。
|
||||
|
||||
<!--
|
||||
Specific extension points can be excluded from `MultiPoint` expansion using
|
||||
the `disabled` field for that extension point. This works with disabling default
|
||||
plugins, non-default plugins, or with the wildcard (`'*'`) to disable all plugins.
|
||||
An example of this, disabling `Score` and `PreScore`, would be:
|
||||
-->
|
||||
|
||||
可以使用该扩展点的 `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: '*'
|
||||
```
|
||||
|
||||
<!--
|
||||
In `v1beta3`, all [default plugins](#scheduling-plugins) are enabled internally through `MultiPoint`.
|
||||
However, individual extension points are still available to allow flexible
|
||||
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` 。
|
||||
它们可以用不同的权重重新排序,如下所示:
|
||||
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta3
|
||||
kind: KubeSchedulerConfiguration
|
||||
profiles:
|
||||
- schedulerName: multipoint-scheduler
|
||||
plugins:
|
||||
score:
|
||||
enabled:
|
||||
- name: 'DefaultScore2'
|
||||
weight: 5
|
||||
```
|
||||
|
||||
<!--
|
||||
In this example, it's unnecessary to specify the plugins in `MultiPoint` explicitly
|
||||
because they are default plugins. And the only plugin specified in `Score` is `DefaultScore2`.
|
||||
This is because plugins set through specific extension points will always take precedence
|
||||
over `MultiPoint` plugins. So, this snippet essentially re-orders the two plugins
|
||||
without needing to specify both of them.
|
||||
-->
|
||||
|
||||
在这个例子中,没有必要在 `MultiPoint` 中明确指定插件,因为它们是默认插件。
|
||||
`Score` 中指定的唯一插件是 `DefaultScore2`。
|
||||
这是因为通过特定扩展点设置的插件将始终优先于 `MultiPoint` 插件。
|
||||
因此,此代码段实质上重新排序了这两个插件,而无需同时指定它们。
|
||||
|
||||
|
||||
<!--
|
||||
The general hierarchy for precedence when configuring `MultiPoint` plugins is as follows:
|
||||
-->
|
||||
配置 `MultiPoint` 插件时优先级的一般层次结构如下:
|
||||
|
||||
<!--
|
||||
1. Specific extension points run first, and their settings override whatever is set elsewhere
|
||||
-->
|
||||
1. 特定的扩展点首先运行,它们的设置会覆盖其他地方的设置
|
||||
|
||||
<!--2. Plugins manually configured through `MultiPoint` and their settings
|
||||
-->
|
||||
2. 通过 `MultiPoint` 手动配置的插件及其设置
|
||||
|
||||
<!--3. Default plugins and their default settings
|
||||
-->
|
||||
3. 默认插件及其默认设置
|
||||
|
||||
<!--
|
||||
To demonstrate the above hierarchy, the following example is based on these plugins:
|
||||
-->
|
||||
为了演示上述层次结构,以下示例基于这些插件:
|
||||
|插件|扩展点|
|
||||
|---|---|
|
||||
|`DefaultQueueSort`|`QueueSort`|
|
||||
|`CustomQueueSort`|`QueueSort`|
|
||||
|`DefaultPlugin1`|`Score`, `Filter`|
|
||||
|`DefaultPlugin2`|`Score`|
|
||||
|`CustomPlugin1`|`Score`, `Filter`|
|
||||
|`CustomPlugin2`|`Score`, `Filter`|
|
||||
|
||||
<!--
|
||||
A valid sample configuration for these plugins would be:
|
||||
-->
|
||||
这些插件的一个有效示例配置是:
|
||||
|
||||
```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'
|
||||
```
|
||||
|
||||
<!--
|
||||
Note that there is no error for re-declaring a `MultiPoint` plugin in a specific
|
||||
extension point. The re-declaration is ignored (and logged), as specific extension points
|
||||
take precedence.
|
||||
-->
|
||||
请注意,在特定扩展点中重新声明 `MultiPoint` 插件不会出错。
|
||||
重新声明被忽略(并记录),因为特定的扩展点优先。
|
||||
|
||||
<!--
|
||||
Besides keeping most of the config in one spot, this sample does a few things:
|
||||
-->
|
||||
|
||||
除了将大部分配置保存在一个位置之外,此示例还做了一些事情:
|
||||
|
||||
<!--
|
||||
* Enables the custom `queueSort` plugin and disables the default one
|
||||
* Enables `CustomPlugin1` and `CustomPlugin2`, which will run first for all of their extension points
|
||||
* Disables `DefaultPlugin1`, but only for `filter`
|
||||
* Reorders `DefaultPlugin2` to run first in `score` (even before the custom plugins)
|
||||
-->
|
||||
* 启用自定义 `queueSort` 插件并禁用默认插件
|
||||
|
||||
* 启用 `CustomPlugin1` 和 `CustomPlugin2`,这将首先为它们的所有扩展点运行
|
||||
|
||||
* 禁用 `DefaultPlugin1`,但仅适用于 `filter`
|
||||
|
||||
* 重新排序 `DefaultPlugin2` 以在 `score` 中首先运行(甚至在自定义插件之前)
|
||||
|
||||
<!--
|
||||
In versions of the config before `v1beta3`, without `multiPoint`, the above snippet would equate to this:
|
||||
-->
|
||||
在 `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
|
||||
```
|
||||
|
||||
<!--
|
||||
While this is a complicated example, it demonstrates the flexibility of `MultiPoint` config
|
||||
as well as its seamless integration with the existing methods for configuring extension points.
|
||||
-->
|
||||
|
||||
虽然这是一个复杂的例子,但它展示了 `MultiPoint` 配置的灵活性以及它与配置扩展点的现有方法的无缝集成。
|
||||
|
||||
<!--
|
||||
## Scheduler configuration migrations
|
||||
-->
|
||||
|
||||
## 调度程序配置迁移
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="v1beta1 → v1beta2" %}}
|
||||
<!--
|
||||
* With the v1beta2 configuration version, you can use a new score extension for the
|
||||
`NodeResourcesFit` plugin.
|
||||
The new extension combines the functionalities of the `NodeResourcesLeastAllocated`,
|
||||
`NodeResourcesMostAllocated` and `RequestedToCapacityRatio` plugins.
|
||||
For example, if you previously used the `NodeResourcesMostAllocated` plugin, you
|
||||
would instead use `NodeResourcesFit` (enabled by default) and add a `pluginConfig`
|
||||
with a `scoreStrategy` that is similar to:
|
||||
-->
|
||||
* 在 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
|
||||
```
|
||||
|
||||
<!--
|
||||
* The scheduler plugin `NodeLabel` is deprecated; instead, use the [`NodeAffinity`](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) plugin (enabled by default) to achieve similar behavior.
|
||||
-->
|
||||
* 调度器插件 `NodeLabel` 已弃用;
|
||||
相反,要使用 [`NodeAffinity`](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
|
||||
插件(默认启用)来实现类似的行为。
|
||||
|
||||
<!--
|
||||
* The scheduler plugin `ServiceAffinity` is deprecated; instead, use the [`InterPodAffinity`](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) plugin (enabled by default) to achieve similar behavior.
|
||||
-->
|
||||
* 调度程序插件 `ServiceAffinity` 已弃用;
|
||||
相反,使用 [`InterPodAffinity`](/zh/doc/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
|
||||
插件(默认启用)来实现类似的行为。
|
||||
|
||||
<!--
|
||||
* The scheduler plugin `NodePreferAvoidPods` is deprecated; instead, use [node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to achieve similar behavior.
|
||||
-->
|
||||
* 调度器插件 `NodePreferAvoidPods` 已弃用;
|
||||
相反,使用 [节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) 来实现类似的行为。
|
||||
|
||||
<!--
|
||||
* A plugin enabled in a v1beta2 configuration file takes precedence over the default configuration for that plugin.
|
||||
-->
|
||||
* 在 v1beta2 配置文件中启用的插件优先于该插件的默认配置。
|
||||
|
||||
<!--
|
||||
* Invalid `host` or `port` configured for scheduler healthz and metrics bind address will cause validation failure.
|
||||
-->
|
||||
* 调度器的健康检查和审计的绑定地址,所配置的 `host` 或 `port` 无效将导致验证失败。
|
||||
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab name="v1beta2 → v1beta3" %}}
|
||||
<!--
|
||||
* Three plugins' weight are increased by default:
|
||||
* `InterPodAffinity` from 1 to 2
|
||||
* `NodeAffinity` from 1 to 2
|
||||
* `TaintToleration` from 1 to 3
|
||||
-->
|
||||
* 默认增加三个插件的权重:
|
||||
* `InterPodAffinity` 从 1 到 2
|
||||
* `NodeAffinity` 从 1 到 2
|
||||
* `TaintToleration` 从 1 到 3
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
<!--
|
||||
* Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
* Read the [kube-scheduler reference](/docs/reference/command-line-tools-reference/kube-scheduler/)
|
||||
* Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
||||
* Read the [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference
|
||||
* Read the [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) reference
|
||||
* Read the [kube-scheduler configuration (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) reference
|
||||
-->
|
||||
* 阅读 [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/) 参考
|
||||
|
||||
Reference in New Issue
Block a user