Skip to content

Commit 79863d4

Browse files
authored
Merge pull request #44340 from windsonsea/podnode
[zh] Add translation to assign-pod-node.md
2 parents 7dfe935 + 9c8db92 commit 79863d4

File tree

1 file changed

+175
-6
lines changed

1 file changed

+175
-6
lines changed

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

Lines changed: 175 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -568,16 +568,15 @@ uses the "soft" `preferredDuringSchedulingIgnoredDuringExecution`.
568568

569569
<!--
570570
The affinity rule specifies that the scheduler is allowed to place the example Pod
571-
on a node only if that node belongs to a specific [zone](/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
571+
on a node only if that node belongs to a specific [zone](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
572572
where other Pods have been labeled with `security=S1`.
573573
For instance, if we have a cluster with a designated zone, let's call it "Zone V,"
574574
consisting of nodes labeled with `topology.kubernetes.io/zone=V`, the scheduler can
575575
assign the Pod to any node within Zone V, as long as there is at least one Pod within
576576
Zone V already labeled with `security=S1`. Conversely, if there are no Pods with `security=S1`
577577
labels in Zone V, the scheduler will not assign the example Pod to any node in that zone.
578578
-->
579-
亲和性规则规定,只有节点属于特定的
580-
[区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
579+
亲和性规则规定,只有节点属于特定的[区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)
581580
且该区域中的其他 Pod 已打上 `security=S1` 标签时,调度器才可以将示例 Pod 调度到此节点上。
582581
例如,如果我们有一个具有指定区域(称之为 "Zone V")的集群,此区域由带有 `topology.kubernetes.io/zone=V`
583582
标签的节点组成,那么只要 Zone V 内已经至少有一个 Pod 打了 `security=S1` 标签,
@@ -586,16 +585,15 @@ labels in Zone V, the scheduler will not assign the example Pod to any node in t
586585

587586
<!--
588587
The anti-affinity rule specifies that the scheduler should try to avoid scheduling the Pod
589-
on a node if that node belongs to a specific [zone](/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
588+
on a node if that node belongs to a specific [zone](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
590589
where other Pods have been labeled with `security=S2`.
591590
For instance, if we have a cluster with a designated zone, let's call it "Zone R,"
592591
consisting of nodes labeled with `topology.kubernetes.io/zone=R`, the scheduler should avoid
593592
assigning the Pod to any node within Zone R, as long as there is at least one Pod within
594593
Zone R already labeled with `security=S2`. Conversely, the anti-affinity rule does not impact
595594
scheduling into Zone R if there are no Pods with `security=S2` labels.
596595
-->
597-
反亲和性规则规定,如果节点属于特定的
598-
[区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
596+
反亲和性规则规定,如果节点属于特定的[区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)
599597
且该区域中的其他 Pod 已打上 `security=S2` 标签,则调度器应尝试避免将 Pod 调度到此节点上。
600598
例如,如果我们有一个具有指定区域(我们称之为 "Zone R")的集群,此区域由带有 `topology.kubernetes.io/zone=R`
601599
标签的节点组成,只要 Zone R 内已经至少有一个 Pod 打了 `security=S2` 标签,
@@ -676,6 +674,177 @@ null `namespaceSelector` matches the namespace of the Pod where the rule is defi
676674
注意,空的 `namespaceSelector`(`{}`)会匹配所有名字空间,而 null 或者空的
677675
`namespaces` 列表以及 null 值 `namespaceSelector` 意味着“当前 Pod 的名字空间”。
678676

677+
#### matchLabelKeys
678+
679+
{{< feature-state for_k8s_version="v1.29" state="alpha" >}}
680+
681+
{{< note >}}
682+
<!-- UPDATE THIS WHEN PROMOTING TO BETA -->
683+
<!--
684+
The `matchLabelKeys` field is a alpha-level field and is disabled by default in
685+
Kubernetes {{< skew currentVersion >}}.
686+
When you want to use it, you have to enable it via the
687+
`MatchLabelKeysInPodAffinity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
688+
-->
689+
`matchLabelKeys` 字段是一个 Alpha 级别的字段,在 Kubernetes {{< skew currentVersion >}} 中默认被禁用。
690+
当你想要使用此字段时,你必须通过 `MatchLabelKeysInPodAffinity`
691+
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)启用它。
692+
{{< /note >}}
693+
694+
<!--
695+
Kubernetes includes an optional `matchLabelKeys` field for Pod affinity
696+
or anti-affinity. The field specifies keys for the labels that should match with the incoming Pod's labels,
697+
when satisfying the Pod (anti)affinity.
698+
699+
The keys are used to look up values from the pod labels; those key-value labels are combined
700+
(using `AND`) with the match restrictions defined using the `labelSelector` field. The combined
701+
filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation.
702+
-->
703+
Kubernetes 在 Pod 亲和性或反亲和性中包含一个可选的 `matchLabelKeys` 字段。
704+
此字段指定了应与传入 Pod 的标签匹配的标签键,以满足 Pod 的(反)亲和性。
705+
706+
这些键用于从 Pod 的标签中查找值;这些键值标签与使用 `labelSelector` 字段定义的匹配限制组合(使用 `AND` 操作)。
707+
这种组合的过滤机制选择将用于 Pod(反)亲和性计算的现有 Pod 集合。
708+
709+
<!--
710+
A common use case is to use `matchLabelKeys` with `pod-template-hash` (set on Pods
711+
managed as part of a Deployment, where the value is unique for each revision).
712+
Using `pod-template-hash` in `matchLabelKeys` allows you to target the Pods that belong
713+
to the same revision as the incoming Pod, so that a rolling upgrade won't break affinity.
714+
-->
715+
一个常见的用例是在 `matchLabelKeys` 中使用 `pod-template-hash`
716+
(设置在作为 Deployment 的一部分进行管理的 Pod 上,其中每个版本的值是唯一的)。
717+
在 `matchLabelKeys` 中使用 `pod-template-hash` 允许你定位与传入 Pod 相同版本的 Pod,
718+
确保滚动升级不会破坏亲和性。
719+
720+
<!--
721+
# Only Pods from a given rollout are taken into consideration when calculating pod affinity.
722+
# If you update the Deployment, the replacement Pods follow their own affinity rules
723+
# (if there are any defined in the new Pod template)
724+
-->
725+
```yaml
726+
apiVersion: apps/v1
727+
kind: Deployment
728+
metadata:
729+
name: application-server
730+
...
731+
spec:
732+
template:
733+
affinity:
734+
podAffinity:
735+
requiredDuringSchedulingIgnoredDuringExecution:
736+
- labelSelector:
737+
matchExpressions:
738+
- key: app
739+
operator: In
740+
values:
741+
- database
742+
topologyKey: topology.kubernetes.io/zone
743+
# 只有在计算 Pod 亲和性时,才考虑指定上线的 Pod。
744+
# 如果你更新 Deployment,替代的 Pod 将遵循它们自己的亲和性规则
745+
# (如果在新的 Pod 模板中定义了任何规则)。
746+
matchLabelKeys:
747+
- pod-template-hash
748+
```
749+
750+
#### mismatchLabelKeys
751+
752+
{{< feature-state for_k8s_version="v1.29" state="alpha" >}}
753+
754+
{{< note >}}
755+
<!-- UPDATE THIS WHEN PROMOTING TO BETA -->
756+
<!--
757+
The `mismatchLabelKeys` field is a alpha-level field and is disabled by default in
758+
Kubernetes {{< skew currentVersion >}}.
759+
When you want to use it, you have to enable it via the
760+
`MatchLabelKeysInPodAffinity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
761+
-->
762+
`mismatchLabelKeys` 字段是一个 Alpha 级别的字段,在 Kubernetes {{< skew currentVersion >}} 中默认被禁用。
763+
当你想要使用此字段时,你必须通过 `MatchLabelKeysInPodAffinity`
764+
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)启用它。
765+
{{< /note >}}
766+
767+
<!--
768+
Kubernetes includes an optional `mismatchLabelKeys` field for Pod affinity
769+
or anti-affinity. The field specifies keys for the labels that should **not** match with the incoming Pod's labels,
770+
when satisfying the Pod (anti)affinity.
771+
772+
One example use case is to ensure Pods go to the topology domain (node, zone, etc) where only Pods from the same tenant or team are scheduled in.
773+
In other words, you want to avoid running Pods from two different tenants on the same topology domain at the same time.
774+
-->
775+
Kubernetes 为 Pod 亲和性或反亲和性提供了一个可选的 `mismatchLabelKeys` 字段。
776+
此字段指定了在满足 Pod(反)亲和性时,**不** 应与传入 Pod 的标签匹配的键。
777+
778+
一个示例用例是确保 Pod 进入指定的拓扑域(节点、区域等),在此拓扑域中只调度来自同一租户或团队的 Pod。
779+
换句话说,你想要避免在同一拓扑域中同时运行来自两个不同租户的 Pod。
780+
781+
<!--
782+
```yaml
783+
apiVersion: v1
784+
kind: Pod
785+
metadata:
786+
labels:
787+
# Assume that all relevant Pods have a "tenant" label set
788+
tenant: tenant-a
789+
...
790+
spec:
791+
affinity:
792+
podAffinity:
793+
requiredDuringSchedulingIgnoredDuringExecution:
794+
# ensure that pods associated with this tenant land on the correct node pool
795+
- matchLabelKeys:
796+
- tenant
797+
topologyKey: node-pool
798+
podAntiAffinity:
799+
requiredDuringSchedulingIgnoredDuringExecution:
800+
# ensure that pods associated with this tenant can't schedule to nodes used for another tenant
801+
- mismatchLabelKeys:
802+
- tenant # whatever the value of the "tenant" label for this Pod, prevent
803+
# scheduling to nodes in any pool where any Pod from a different
804+
# tenant is running.
805+
labelSelector:
806+
# We have to have the labelSelector which selects only Pods with the tenant label,
807+
# otherwise this Pod would hate Pods from daemonsets as well, for example,
808+
# which aren't supposed to have the tenant label.
809+
matchExpressions:
810+
- key: tenant
811+
operator: Exists
812+
topologyKey: node-pool
813+
```
814+
-->
815+
```yaml
816+
apiVersion: v1
817+
kind: Pod
818+
metadata:
819+
labels:
820+
# 假设所有相关的 Pod 都设置了 “tenant” 标签
821+
tenant: tenant-a
822+
...
823+
spec:
824+
affinity:
825+
podAffinity:
826+
requiredDuringSchedulingIgnoredDuringExecution:
827+
# 确保与此租户关联的 Pod 落在正确的节点池上
828+
- matchLabelKeys:
829+
- tenant
830+
topologyKey: node-pool
831+
podAntiAffinity:
832+
requiredDuringSchedulingIgnoredDuringExecution:
833+
# 确保与此租户关联的 Pod 不能调度到用于其他租户的节点上
834+
- mismatchLabelKeys:
835+
- tenant # 无论此 Pod 的 “tenant” 标签的值是什么,
836+
# 如果节点池中有来自别的租户的任何 Pod 在运行,
837+
# 都会阻碍此 Pod 被调度到这些节点池中的节点上
838+
labelSelector:
839+
# 我们必须有一个 labelSelector,只选择具有 “tenant” 标签的 Pod,
840+
# 否则此 Pod 也会与来自 DaemonSet 的 Pod 发生冲突,
841+
# 而这些 Pod 不应该具有 “tenant” 标签
842+
matchExpressions:
843+
- key: tenant
844+
operator: Exists
845+
topologyKey: node-pool
846+
```
847+
679848
<!--
680849
#### More practical use-cases
681850

0 commit comments

Comments
 (0)