[zh] sync topology-spread-constraints.md
parent
342456405d
commit
1d019a11be
|
@ -87,7 +87,7 @@ Pod 拓扑分布约束使你能够以声明的方式进行配置。
|
||||||
The Pod API includes a field, `spec.topologySpreadConstraints`. The usage of this field looks like
|
The Pod API includes a field, `spec.topologySpreadConstraints`. The usage of this field looks like
|
||||||
the following:
|
the following:
|
||||||
-->
|
-->
|
||||||
## `topologySpreadConstraints` 字段
|
## `topologySpreadConstraints` 字段 {#topologyspreadconstraints-field}
|
||||||
|
|
||||||
Pod API 包括一个 `spec.topologySpreadConstraints` 字段。这个字段的用法如下所示:
|
Pod API 包括一个 `spec.topologySpreadConstraints` 字段。这个字段的用法如下所示:
|
||||||
|
|
||||||
|
@ -126,7 +126,7 @@ You can define one or multiple `topologySpreadConstraints` entries to instruct t
|
||||||
kube-scheduler how to place each incoming Pod in relation to the existing Pods across
|
kube-scheduler how to place each incoming Pod in relation to the existing Pods across
|
||||||
your cluster. Those fields are:
|
your cluster. Those fields are:
|
||||||
-->
|
-->
|
||||||
### 分布约束定义
|
### 分布约束定义 {#spread-constraint-definition}
|
||||||
|
|
||||||
你可以定义一个或多个 `topologySpreadConstraints` 条目以指导 kube-scheduler
|
你可以定义一个或多个 `topologySpreadConstraints` 条目以指导 kube-scheduler
|
||||||
如何将每个新来的 Pod 与跨集群的现有 Pod 相关联。这些字段包括:
|
如何将每个新来的 Pod 与跨集群的现有 Pod 相关联。这些字段包括:
|
||||||
|
@ -328,13 +328,15 @@ For example, a node might have labels:
|
||||||
-->
|
-->
|
||||||
### 节点标签 {#node-labels}
|
### 节点标签 {#node-labels}
|
||||||
|
|
||||||
拓扑分布约束依赖于节点标签来标识每个{{< glossary_tooltip text="节点" term_id="node" >}}所在的拓扑域。例如,某节点可能具有标签:
|
拓扑分布约束依赖于节点标签来标识每个{{< glossary_tooltip text="节点" term_id="node" >}}所在的拓扑域。
|
||||||
|
例如,某节点可能具有标签:
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
region: us-east-1
|
region: us-east-1
|
||||||
zone: us-east-1a
|
zone: us-east-1a
|
||||||
```
|
```
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
<!--
|
<!--
|
||||||
For brevity, this example doesn't use the
|
For brevity, this example doesn't use the
|
||||||
[well-known](/docs/reference/labels-annotations-taints/) label keys
|
[well-known](/docs/reference/labels-annotations-taints/) label keys
|
||||||
|
@ -345,7 +347,6 @@ those registered label keys are nonetheless recommended rather than the private
|
||||||
You can't make a reliable assumption about the meaning of a private label key
|
You can't make a reliable assumption about the meaning of a private label key
|
||||||
between different contexts.
|
between different contexts.
|
||||||
-->
|
-->
|
||||||
{{< note >}}
|
|
||||||
为了简便,此示例未使用[众所周知](/zh-cn/docs/reference/labels-annotations-taints/)的标签键
|
为了简便,此示例未使用[众所周知](/zh-cn/docs/reference/labels-annotations-taints/)的标签键
|
||||||
`topology.kubernetes.io/zone` 和 `topology.kubernetes.io/region`。
|
`topology.kubernetes.io/zone` 和 `topology.kubernetes.io/region`。
|
||||||
但是,建议使用那些已注册的标签键,而不是此处使用的私有(不合格)标签键 `region` 和 `zone`。
|
但是,建议使用那些已注册的标签键,而不是此处使用的私有(不合格)标签键 `region` 和 `zone`。
|
||||||
|
@ -762,7 +763,7 @@ topology spread constraints are applied to a Pod if, and only if:
|
||||||
|
|
||||||
Default constraints can be set as part of the `PodTopologySpread` plugin
|
Default constraints can be set as part of the `PodTopologySpread` plugin
|
||||||
arguments in a [scheduling profile](/docs/reference/scheduling/config/#profiles).
|
arguments in a [scheduling profile](/docs/reference/scheduling/config/#profiles).
|
||||||
The constraints are specified with the same [API above](#api), except that
|
The constraints are specified with the same [API above](#topologyspreadconstraints-field), except that
|
||||||
`labelSelector` must be empty. The selectors are calculated from the Services,
|
`labelSelector` must be empty. The selectors are calculated from the Services,
|
||||||
ReplicaSets, StatefulSets or ReplicationControllers that the Pod belongs to.
|
ReplicaSets, StatefulSets or ReplicationControllers that the Pod belongs to.
|
||||||
|
|
||||||
|
@ -776,7 +777,7 @@ An example configuration might look like follows:
|
||||||
- Pod 隶属于某个 Service、ReplicaSet、StatefulSet 或 ReplicationController。
|
- Pod 隶属于某个 Service、ReplicaSet、StatefulSet 或 ReplicationController。
|
||||||
|
|
||||||
默认约束可以设置为[调度方案](/zh-cn/docs/reference/scheduling/config/#profiles)中
|
默认约束可以设置为[调度方案](/zh-cn/docs/reference/scheduling/config/#profiles)中
|
||||||
`PodTopologySpread` 插件参数的一部分。约束的设置采用[如前所述的 API](#api),
|
`PodTopologySpread` 插件参数的一部分。约束的设置采用[如前所述的 API](#topologyspreadconstraints-field),
|
||||||
只是 `labelSelector` 必须为空。
|
只是 `labelSelector` 必须为空。
|
||||||
选择算符是根据 Pod 所属的 Service、ReplicaSet、StatefulSet 或 ReplicationController 来设置的。
|
选择算符是根据 Pod 所属的 Service、ReplicaSet、StatefulSet 或 ReplicationController 来设置的。
|
||||||
|
|
||||||
|
@ -798,12 +799,12 @@ profiles:
|
||||||
defaultingType: List
|
defaultingType: List
|
||||||
```
|
```
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
<!--
|
<!--
|
||||||
The [`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
|
The [`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
|
||||||
is disabled by default. The Kubernetes project recommends using `PodTopologySpread`
|
is disabled by default. The Kubernetes project recommends using `PodTopologySpread`
|
||||||
to achieve similar behavior.
|
to achieve similar behavior.
|
||||||
-->
|
-->
|
||||||
{{< note >}}
|
|
||||||
默认配置下,[`SelectorSpread` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)是被禁用的。
|
默认配置下,[`SelectorSpread` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)是被禁用的。
|
||||||
Kubernetes 项目建议使用 `PodTopologySpread` 以执行类似行为。
|
Kubernetes 项目建议使用 `PodTopologySpread` 以执行类似行为。
|
||||||
{{< /note >}}
|
{{< /note >}}
|
||||||
|
@ -838,6 +839,7 @@ is disabled by default.
|
||||||
-->
|
-->
|
||||||
此外,原来用于提供等同行为的 `SelectorSpread` 插件默认被禁用。
|
此外,原来用于提供等同行为的 `SelectorSpread` 插件默认被禁用。
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
<!--
|
<!--
|
||||||
The `PodTopologySpread` plugin does not score the nodes that don't have
|
The `PodTopologySpread` plugin does not score the nodes that don't have
|
||||||
the topology keys specified in the spreading constraints. This might result
|
the topology keys specified in the spreading constraints. This might result
|
||||||
|
@ -848,7 +850,6 @@ If your nodes are not expected to have **both** `kubernetes.io/hostname` and
|
||||||
`topology.kubernetes.io/zone` labels set, define your own constraints
|
`topology.kubernetes.io/zone` labels set, define your own constraints
|
||||||
instead of using the Kubernetes defaults.
|
instead of using the Kubernetes defaults.
|
||||||
-->
|
-->
|
||||||
{{< note >}}
|
|
||||||
对于分布约束中所指定的拓扑键而言,`PodTopologySpread` 插件不会为不包含这些拓扑键的节点评分。
|
对于分布约束中所指定的拓扑键而言,`PodTopologySpread` 插件不会为不包含这些拓扑键的节点评分。
|
||||||
这可能导致在使用默认拓扑约束时,其行为与原来的 `SelectorSpread` 插件的默认行为不同。
|
这可能导致在使用默认拓扑约束时,其行为与原来的 `SelectorSpread` 插件的默认行为不同。
|
||||||
|
|
||||||
|
@ -898,6 +899,7 @@ or more scattered.
|
||||||
在 Kubernetes 中,Pod 间亲和性和反亲和性控制 Pod 彼此的调度方式(更密集或更分散)。
|
在 Kubernetes 中,Pod 间亲和性和反亲和性控制 Pod 彼此的调度方式(更密集或更分散)。
|
||||||
|
|
||||||
对于 `podAffinity`:吸引 Pod;你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。
|
对于 `podAffinity`:吸引 Pod;你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。
|
||||||
|
|
||||||
对于 `podAntiAffinity`:驱逐 Pod。如果将此设为 `requiredDuringSchedulingIgnoredDuringExecution` 模式,
|
对于 `podAntiAffinity`:驱逐 Pod。如果将此设为 `requiredDuringSchedulingIgnoredDuringExecution` 模式,
|
||||||
则只有单个 Pod 可以调度到单个拓扑域;如果你选择 `preferredDuringSchedulingIgnoredDuringExecution`,
|
则只有单个 Pod 可以调度到单个拓扑域;如果你选择 `preferredDuringSchedulingIgnoredDuringExecution`,
|
||||||
则你将丢失强制执行此约束的能力。
|
则你将丢失强制执行此约束的能力。
|
||||||
|
@ -967,5 +969,5 @@ section of the enhancement proposal about Pod topology spread constraints.
|
||||||
-->
|
-->
|
||||||
- 博客:[PodTopologySpread 介绍](/blog/2020/05/introducing-podtopologyspread/)详细解释了 `maxSkew`,
|
- 博客:[PodTopologySpread 介绍](/blog/2020/05/introducing-podtopologyspread/)详细解释了 `maxSkew`,
|
||||||
并给出了一些进阶的使用示例。
|
并给出了一些进阶的使用示例。
|
||||||
- 阅读针对 Pod 的 API 参考的
|
- 阅读针对 Pod 的 API
|
||||||
[调度](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling)一节。
|
参考的[调度](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling)一节。
|
||||||
|
|
Loading…
Reference in New Issue