[zh] sync topology-spread-constraints.md
Michael
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 following:
|
||||
-->
|
||||
## `topologySpreadConstraints` 字段
|
||||
## `topologySpreadConstraints` 字段 {#topologyspreadconstraints-field}
|
||||
|
||||
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
|
||||
your cluster. Those fields are:
|
||||
-->
|
||||
### 分布约束定义
|
||||
### 分布约束定义 {#spread-constraint-definition}
|
||||
|
||||
你可以定义一个或多个 `topologySpreadConstraints` 条目以指导 kube-scheduler
|
||||
如何将每个新来的 Pod 与跨集群的现有 Pod 相关联。这些字段包括：
|
||||
|
|
@ -328,13 +328,15 @@ For example, a node might have labels:
|
|||
-->
|
||||
### 节点标签 {#node-labels}
|
||||
|
||||
拓扑分布约束依赖于节点标签来标识每个{{< glossary_tooltip text="节点" term_id="node" >}}所在的拓扑域。例如，某节点可能具有标签：
|
||||
拓扑分布约束依赖于节点标签来标识每个{{< glossary_tooltip text="节点" term_id="node" >}}所在的拓扑域。
|
||||
例如，某节点可能具有标签：
|
||||
|
||||
```yaml
|
||||
region: us-east-1
|
||||
zone: us-east-1a
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
For brevity, this example doesn't use the
|
||||
[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
|
||||
between different contexts.
|
||||
-->
|
||||
{{< note >}}
|
||||
为了简便，此示例未使用[众所周知](/zh-cn/docs/reference/labels-annotations-taints/)的标签键
|
||||
`topology.kubernetes.io/zone` 和 `topology.kubernetes.io/region`。
|
||||
但是，建议使用那些已注册的标签键，而不是此处使用的私有（不合格）标签键 `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
|
||||
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,
|
||||
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。
|
||||
|
||||
默认约束可以设置为[调度方案](/zh-cn/docs/reference/scheduling/config/#profiles)中
|
||||
`PodTopologySpread` 插件参数的一部分。约束的设置采用[如前所述的 API](#api)，
|
||||
`PodTopologySpread` 插件参数的一部分。约束的设置采用[如前所述的 API](#topologyspreadconstraints-field)，
|
||||
只是 `labelSelector` 必须为空。
|
||||
选择算符是根据 Pod 所属的 Service、ReplicaSet、StatefulSet 或 ReplicationController 来设置的。
|
||||
|
||||
|
|
@ -798,12 +799,12 @@ profiles:
|
|||
defaultingType: List
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The [`SelectorSpread` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
|
||||
is disabled by default. The Kubernetes project recommends using `PodTopologySpread`
|
||||
to achieve similar behavior.
|
||||
-->
|
||||
{{< note >}}
|
||||
默认配置下，[`SelectorSpread` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)是被禁用的。
|
||||
Kubernetes 项目建议使用 `PodTopologySpread` 以执行类似行为。
|
||||
{{< /note >}}
|
||||
|
|
@ -838,6 +839,7 @@ is disabled by default.
|
|||
-->
|
||||
此外，原来用于提供等同行为的 `SelectorSpread` 插件默认被禁用。
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
The `PodTopologySpread` plugin does not score the nodes that don't have
|
||||
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
|
||||
instead of using the Kubernetes defaults.
|
||||
-->
|
||||
{{< note >}}
|
||||
对于分布约束中所指定的拓扑键而言，`PodTopologySpread` 插件不会为不包含这些拓扑键的节点评分。
|
||||
这可能导致在使用默认拓扑约束时，其行为与原来的 `SelectorSpread` 插件的默认行为不同。
|
||||
|
||||
|
|
@ -898,6 +899,7 @@ or more scattered.
|
|||
在 Kubernetes 中，Pod 间亲和性和反亲和性控制 Pod 彼此的调度方式（更密集或更分散）。
|
||||
|
||||
对于 `podAffinity`：吸引 Pod；你可以尝试将任意数量的 Pod 集中到符合条件的拓扑域中。
|
||||
|
||||
对于 `podAntiAffinity`：驱逐 Pod。如果将此设为 `requiredDuringSchedulingIgnoredDuringExecution` 模式，
|
||||
则只有单个 Pod 可以调度到单个拓扑域；如果你选择 `preferredDuringSchedulingIgnoredDuringExecution`，
|
||||
则你将丢失强制执行此约束的能力。
|
||||
|
|
@ -967,5 +969,5 @@ section of the enhancement proposal about Pod topology spread constraints.
|
|||
-->
|
||||
- 博客：[PodTopologySpread 介绍](/blog/2020/05/introducing-podtopologyspread/)详细解释了 `maxSkew`，
|
||||
并给出了一些进阶的使用示例。
|
||||
- 阅读针对 Pod 的 API 参考的
|
||||
[调度](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling)一节。
|
||||
- 阅读针对 Pod 的 API
|
||||
参考的[调度](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling)一节。
|
||||
|
|
|
|||
Loading…
Reference in New Issue