@@ -568,16 +568,15 @@ uses the "soft" `preferredDuringSchedulingIgnoredDuringExecution`.
568
568
569
569
<!--
570
570
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/)
572
572
where other Pods have been labeled with `security=S1`.
573
573
For instance, if we have a cluster with a designated zone, let's call it "Zone V,"
574
574
consisting of nodes labeled with `topology.kubernetes.io/zone=V`, the scheduler can
575
575
assign the Pod to any node within Zone V, as long as there is at least one Pod within
576
576
Zone V already labeled with `security=S1`. Conversely, if there are no Pods with `security=S1`
577
577
labels in Zone V, the scheduler will not assign the example Pod to any node in that zone.
578
578
-->
579
- 亲和性规则规定,只有节点属于特定的
580
- [区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
579
+ 亲和性规则规定,只有节点属于特定的[区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)
581
580
且该区域中的其他 Pod 已打上 `security=S1` 标签时,调度器才可以将示例 Pod 调度到此节点上。
582
581
例如,如果我们有一个具有指定区域(称之为 "Zone V")的集群,此区域由带有 `topology.kubernetes.io/zone=V`
583
582
标签的节点组成,那么只要 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
586
585
587
586
<!--
588
587
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/)
590
589
where other Pods have been labeled with `security=S2`.
591
590
For instance, if we have a cluster with a designated zone, let's call it "Zone R,"
592
591
consisting of nodes labeled with `topology.kubernetes.io/zone=R`, the scheduler should avoid
593
592
assigning the Pod to any node within Zone R, as long as there is at least one Pod within
594
593
Zone R already labeled with `security=S2`. Conversely, the anti-affinity rule does not impact
595
594
scheduling into Zone R if there are no Pods with `security=S2` labels.
596
595
-->
597
- 反亲和性规则规定,如果节点属于特定的
598
- [区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
596
+ 反亲和性规则规定,如果节点属于特定的[区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/)
599
597
且该区域中的其他 Pod 已打上 `security=S2` 标签,则调度器应尝试避免将 Pod 调度到此节点上。
600
598
例如,如果我们有一个具有指定区域(我们称之为 "Zone R")的集群,此区域由带有 `topology.kubernetes.io/zone=R`
601
599
标签的节点组成,只要 Zone R 内已经至少有一个 Pod 打了 `security=S2` 标签,
@@ -676,6 +674,177 @@ null `namespaceSelector` matches the namespace of the Pod where the rule is defi
676
674
注意,空的 `namespaceSelector`(`{}`)会匹配所有名字空间,而 null 或者空的
677
675
` namespaces` 列表以及 null 值 `namespaceSelector` 意味着“当前 Pod 的名字空间”。
678
676
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
+
679
848
<!--
680
849
# ### More practical use-cases
681
850
0 commit comments