Skip to content

Commit 265bf31

Browse files
authored
Merge pull request #20889 from gavinfish/pod-topology
Polish zh version of pod-topology-spread-constraints.md
2 parents 7a4d1c5 + 1d32fd0 commit 265bf31

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

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

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -182,10 +182,10 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones,
182182
{{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}}
183183
184184
<!--
185-
`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:<any value>" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint.
185+
`topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:&lt;any value&gt;" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can’t satisfy the constraint.
186186
-->
187187
188-
`topologyKey: zone` 意味着均匀分布将只应用于存在标签对为 "zone:<any value>" 的节点上。`whenUnsatisfiable: DoNotSchedule` 告诉调度器,如果传入的 pod 不满足约束,则让它保持挂起状态。
188+
`topologyKey: zone` 意味着均匀分布将只应用于存在标签对为 "zone:&lt;any value&gt;" 的节点上。`whenUnsatisfiable: DoNotSchedule` 告诉调度器,如果传入的 pod 不满足约束,则让它保持挂起状态。
189189
190190
<!--
191191
If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB":
@@ -321,13 +321,17 @@ There are some implicit conventions worth noting here:
321321
- If the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined, nodes not matching them will be bypassed.
322322
-->
323323
324-
- 如果传入的 pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`,则将忽略不匹配的节点。
325-
326324
<!--
327325
Suppose you have a 5-node cluster ranging from zoneA to zoneC:
328326
-->
329327
330-
假设有一个从 zonea 到 zonec 的 5 节点集群:
328+
<!--
329+
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.
330+
-->
331+
332+
- 如果传入的 pod 定义了 `spec.nodeSelector` 或 `spec.affinity.nodeAffinity`,则将忽略不匹配的节点。
333+
334+
假设有一个从 zonea 到 zonec 的 5 节点集群:
331335
332336
```
333337
+---------------+---------------+-------+
@@ -339,11 +343,7 @@ There are some implicit conventions worth noting here:
339343
+-------+-------+-------+-------+-------+
340344
```
341345
342-
<!--
343-
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.
344-
-->
345-
346-
你知道 "zoneC" 必须被排除在外。在这种情况下,可以按如下方式编写 yaml,以便将 "mypod" 放置在 "zoneB" 上,而不是 "zoneC" 上。同样,`spec.nodeSelector` 也要一样处理。
346+
你知道 "zoneC" 必须被排除在外。在这种情况下,可以按如下方式编写 yaml,以便将 "mypod" 放置在 "zoneB" 上,而不是 "zoneC" 上。同样,`spec.nodeSelector` 也要一样处理。
347347
348348
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
349349

0 commit comments

Comments
 (0)