[zh-cn] resync /concepts/scheduling-eviction/assign-pod-node.md

content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -18,13 +18,13 @@ weight: 20
 
 <!--
 You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it can only run on particular set of
-{{< glossary_tooltip text="Node(s)" term_id="node" >}}.
+{{< glossary_tooltip text="node(s)" term_id="node" >}}.
-There are several ways to do this, and the recommended approaches all use
+There are several ways to do this and the recommended approaches all use
 [label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
 Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
-(e.g. spread your pods across nodes so as not place the pod on a node with insufficient free resources, etc.)
+(for example, spreading your Pods across nodes so as not place Pods on a node with insufficient free resources).
 However, there are some circumstances where you may want to control which node
-the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate pods from two different
+the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate Pods from two different
 services that communicate a lot into the same availability zone.
 -->
 你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}}
@@ -172,6 +172,19 @@ define. Some of the benefits of affinity and anti-affinity include:
 * 你可以使用节点上（或其他拓扑域中）运行的其他 Pod 的标签来实施调度约束，
   而不是只能使用节点本身的标签。这个能力让你能够定义规则允许哪些 Pod 可以被放置在一起。
 
+<!--
+The affinity feature consists of two types of affinity:
+
+* *Node affinity* functions like the `nodeSelector` field but is more expressive and
+  allows you to specify soft rules. 
+* *Inter-pod affinity/anti-affinity* allows you to constrain Pods against labels
+  on other Pods.
+-->
+亲和性功能由两种类型的亲和性组成：
+
+* **节点亲和性**功能类似于 `nodeSelector` 字段，但它的表达能力更强，并且允许你指定软规则。
+* Pod 间亲和性/反亲和性允许你根据其他 Pod 的标签来约束 Pod。
+
 <!--
 ### Node affinity
 
@@ -222,15 +235,16 @@ For example, consider the following Pod spec:
 <!--
 In this example, the following rules apply:
 
-* The node *must* have a label with the key `kubernetes.io/os` and
+* The node *must* have a label with the key `topology.kubernetes.io/zone` and
-  the value `linux`.
+  the value of that label *must* be either `antarctica-east1` or `antarctica-west1`.
 * The node *preferably* has a label with the key `another-node-label-key` and
   the value `another-node-label-value`.
 -->
 在这一示例中，所应用的规则如下：
 
-* 节点必须包含键名为 `kubernetes.io/os` 的标签，并且其取值为 `linux`。
+* 节点**必须**包含一个键名为 `topology.kubernetes.io/zone` 的标签，
-* 节点 **最好** 具有键名为 `another-node-label-key` 且取值为
+  并且该标签的取值**必须**为 `antarctica-east1` 或 `antarctica-west1`。
+* 节点**最好**具有一个键名为 `another-node-label-key` 且取值为
   `another-node-label-value` 的标签。
 
 <!--
@@ -341,7 +355,7 @@ must have existing nodes with the `kubernetes.io/os=linux` label.
 
 <!--
 When configuring multiple [scheduling profiles](/docs/reference/scheduling/config/#multiple-profiles), you can associate
-a profile with a Node affinity, which is useful if a profile only applies to a specific set of nodes.
+a profile with a node affinity, which is useful if a profile only applies to a specific set of nodes.
 To do so, add an `addedAffinity` to the `args` field of the [`NodeAffinity` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
 in the [scheduler configuration](/docs/reference/scheduling/config/). For example:
 -->
@@ -410,7 +424,7 @@ Inter-pod affinity and anti-affinity allow you to constrain which nodes your
 Pods can be scheduled on based on the labels of **Pods** already running on that
 node, instead of the node labels.
 -->
-### pod 间亲和性与反亲和性  {#inter-pod-affinity-and-anti-affinity}
+### Pod 间亲和性与反亲和性  {#inter-pod-affinity-and-anti-affinity}
 
 Pod 间亲和性与反亲和性使你可以基于已经在节点上运行的 **Pod** 的标签来约束
 Pod 可以调度到的节点，而不是基于节点上的标签。
@@ -552,9 +566,9 @@ same zone currently running Pods with the `Security=S2` Pod label.
 
 <!--
 To get yourself more familiar with the examples of Pod affinity and anti-affinity,
-refer to the [design proposal](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md).
+refer to the [design proposal](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
 -->
-查阅[设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md)
+查阅[设计文档](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)
 以进一步熟悉 Pod 亲和性与反亲和性的示例。
 
 <!--
@@ -571,8 +585,7 @@ exceptions for performance and security reasons:
 有一些限制：
 
 <!--
-* For Pod affinity and anti-affinity, an empty `topologyKey` field is not allowed in both
+* For Pod affinity and anti-affinity, an empty `topologyKey` field is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
-  `requiredDuringSchedulingIgnoredDuringExecution`
   and `preferredDuringSchedulingIgnoredDuringExecution`.
 * For `requiredDuringSchedulingIgnoredDuringExecution` Pod anti-affinity rules,
   the admission controller `LimitPodHardAntiAffinityTopology` limits
@@ -634,6 +647,14 @@ Pod 间亲和性与反亲和性在与更高级别的集合（例如 ReplicaSet
 Deployment 等）一起使用时，它们可能更加有用。
 这些规则使得你可以配置一组工作负载，使其位于相同定义拓扑（例如，节点）中。
 
+<!--
+Take, for example, a three-node cluster running a web application with an
+in-memory cache like redis. You could use inter-pod affinity and anti-affinity
+to co-locate the web servers with the cache as much as possible.
+-->
+以一个三节点的集群为例，该集群运行一个带有 Redis 这种内存缓存的 Web 应用程序。
+你可以使用节点间的亲和性和反亲和性来尽可能地将 Web 服务器与缓存并置。
+
 <!--
 In the following example Deployment for the redis cache, the replicas get the label `app=store`. The
 `podAntiAffinity` rule tells the scheduler to avoid placing multiple replicas
@@ -803,16 +824,16 @@ The above Pod will only run on the node `kube-01`.
 
 <!--
 * Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
-* Read the design docs for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
+* Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
-  and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
+  and for [inter-pod affinity/anti-affinity](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md).
 * Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
   resource allocation decisions. 
 * Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/).
 * Learn how to use [affinity and anti-affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/).
 -->
 * 进一步阅读[污点与容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)文档。
-* 阅读[节点亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
+* 阅读[节点亲和性](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md)
-  和[Pod 间亲和性与反亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
+  和[Pod 间亲和性与反亲和性](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)
   的设计文档。
 * 了解[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。
 * 了解如何使用 [nodeSelector](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/)。