Merge pull request #32558 from tengqm/zh-resync-topology

[zh] Resync pod topology spread constraints page

content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -75,7 +75,7 @@ node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB
 <!--
 Then the cluster is logically viewed as below:
 -->
-然后从逻辑上看集群如下：
+那么，从逻辑上看集群如下：
 
 {{<mermaid>}}
 graph TB
@@ -96,11 +96,9 @@ graph TB
 {{< /mermaid >}}
 
 <!--
-
 Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
 -->
-你可以复用在大多数集群上自动创建和填充的
+你可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/labels-annotations-taints/)，
-[常用标签](/zh/docs/reference/labels-annotations-taints/)，
 而不是手动添加标签。
 
 <!--
@@ -169,6 +167,12 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
   拓扑域中 Pod 的数量。
   有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
 
+<!--
+When a Pod defines more than one `topologySpreadConstraint`, those constraints are ANDed: The kube-scheduler looks for a node for the incoming Pod that satisfies all the constraints.
+-->
+当 Pod 定义了不止一个 `topologySpreadConstraint`，这些约束之间是逻辑与的关系。
+kube-scheduler 会为新的 Pod 寻找一个能够满足所有约束的节点。
+
 <!--
 You can read more about this field by running `kubectl explain Pod.spec.topologySpreadConstraints`.
 -->
@@ -353,7 +357,6 @@ graph BT
     class zoneA,zoneB cluster;
 {{< /mermaid >}}
 
-
 <!--
 If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing.
 -->
@@ -374,15 +377,16 @@ The scheduler will skip the non-matching nodes from the skew calculations if the
 -->
 ### 节点亲和性与节点选择器的相互作用   {#interaction-with-node-affinity-and-node-selectors}
 
-如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，调度器将从倾斜计算中跳过不匹配的节点。
+如果 Pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`，
+调度器将在偏差计算中跳过不匹配的节点。
 
 <!--
+### Example: TopologySpreadConstraints with NodeAffinity
+
 Suppose you have a 5-node cluster ranging from zoneA to zoneC:
-
-    and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
-
-    {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
 -->
+### 示例：TopologySpreadConstraints 与 NodeAffinity
+
 假设你有一个跨越 zoneA 到 zoneC 的 5 节点集群：
 
 {{<mermaid>}}
@@ -417,7 +421,11 @@ The scheduler will skip the non-matching nodes from the skew calculations if the
 class zoneC cluster;
 {{< /mermaid >}}
 
-    而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 yaml，
+
+<!--
+and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
+-->
+而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 YAML，
 以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector`
 也要一样处理。
 
@@ -503,7 +511,7 @@ An example configuration might look like follows:
 配置的示例可能看起来像下面这个样子：
 
 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 
 profiles:
@@ -565,20 +573,24 @@ is disabled.
 -->
 此外，原来用于提供等同行为的 `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
+in a different default behavior compared to the legacy `SelectorSpread` plugin when
+using the default topology constraints.
+-->
+对于分布约束中所指定的拓扑键而言，`PodTopologySpread` 插件不会为不包含这些主键的节点评分。
+这可能导致在使用默认拓扑约束时，其行为与原来的 `SelectorSpread` 插件的默认行为不同，
+
 <!--
 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.
-
-The `PodTopologySpread` plugin does not score the nodes that don't have
-the topology keys specified in the spreading constraints.
 -->
-{{< note >}}
 如果你的节点不会 **同时** 设置 `kubernetes.io/hostname` 和
 `topology.kubernetes.io/zone` 标签，你应该定义自己的约束而不是使用
 Kubernetes 的默认约束。
-
-插件 `PodTopologySpread` 不会为未设置分布约束中所给拓扑键的节点评分。
 {{< /note >}}
 
 <!--
@@ -586,11 +598,11 @@ If you don't want to use the default Pod spreading constraints for your cluster,
 you can disable those defaults by setting `defaultingType` to `List` and leaving
 empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:
 -->
-如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List` 和
+如果你不想为集群使用默认的 Pod 分布约束，你可以通过设置 `defaultingType` 参数为 `List`
-将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。
+并将 `PodTopologySpread` 插件配置中的 `defaultConstraints` 参数置空来禁用默认 Pod 分布约束。
 
 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 
 profiles:
@@ -627,12 +639,6 @@ cost-saving. This can also help on rolling update workloads and scaling out
 replicas smoothly. See
 [Motivation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)
 for more details.
-
-
-The "EvenPodsSpread" feature provides flexible options to distribute Pods evenly across different
-topology domains - to achieve high availability or cost-saving. This can also help on rolling update
-workloads and scaling out replicas smoothly.
-See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation) for more details.
 -->
 要实现更细粒度的控制，你可以设置拓扑分布约束来将 Pod 分布到不同的拓扑域下，
 从而实现高可用性或节省成本。这也有助于工作负载的滚动更新和平稳地扩展副本规模。
@@ -642,13 +648,19 @@ See [Motivation](https://github.com/kubernetes/enhancements/blob/master/keps/sig
 <!--
 ## Known Limitations
 
-- Scaling down a Deployment may result in imbalanced Pods distribution.
+- There's no guarantee that the constraints remain satisfied when Pods are removed. For example, scaling down a Deployment may result in imbalanced Pods distribution.
+You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to rebalance the Pods distribution.
+
 - Pods matched on tainted nodes are respected. See [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)
 -->
 ## 已知局限性
 
-- Deployment 缩容操作可能导致 Pod 分布不平衡。
+- 当 Pod 被移除时，无法保证约束仍被满足。例如，缩减某 Deployment 的规模时，
-- 具有污点的节点上的 Pods 也会被统计。
+  Pod 的分布可能不再均衡。
+  你可以使用 [Descheduler](https://github.com/kubernetes-sigs/descheduler)
+  来重新实现 Pod 分布的均衡。
+
+- 具有污点的节点上匹配的 Pods 也会被统计。
   参考 [Issue 80921](https://github.com/kubernetes/kubernetes/issues/80921)。
 
 ## {{% heading "whatsnext" %}}