From 1d019a11bebb24f8d064ee4c300d7262703be3c0 Mon Sep 17 00:00:00 2001
From: Michael <cloudyonspring@126.com>
Date: Wed, 19 Oct 2022 08:11:13 +0800
Subject: [PATCH] [zh] sync topology-spread-constraints.md

---
 .../topology-spread-constraints.md            | 22 ++++++++++---------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md b/content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md
index 1eaaa32a79716..8d52ae9ecbb72 100644
--- a/content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md
+++ b/content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md
@@ -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)一节。