kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Clean up 2024-08-16-matchlabelkeys-podaffinity.md

pull/47753/head
windsonsea 2024-09-02 10:40:36 +08:00
parent 0aeb9c50a1
commit 446d465879
1 changed files with 30 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
content/en/blog/_posts/2024-08-16-matchlabelkeys-podaffinity.md
View File

@ -7,25 +7,25 @@ author: >
Kensei Nakada (Tetrate) Kensei Nakada (Tetrate)
--- ---
Kubernetes 1.29 introduced new fields `MatchLabelKeys` and `MismatchLabelKeys` in PodAffinity and PodAntiAffinity. Kubernetes 1.29 introduced new fields `matchLabelKeys` and `mismatchLabelKeys` in `podAffinity` and `podAntiAffinity`.
In Kubernetes 1.31, this feature moves to beta and the corresponding feature gate (`MatchLabelKeysInPodAffinity`) gets enabled by default. In Kubernetes 1.31, this feature moves to beta and the corresponding feature gate (`MatchLabelKeysInPodAffinity`) gets enabled by default.
## `MatchLabelKeys` - Enhanced scheduling for versatile rolling updates ## `matchLabelKeys` - Enhanced scheduling for versatile rolling updates
During a workload's (e.g., Deployment) rolling update, a cluster may have Pods from multiple versions at the same time. During a workload's (e.g., Deployment) rolling update, a cluster may have Pods from multiple versions at the same time.
However, the scheduler cannot distinguish between old and new versions based on the `LabelSelector` specified in PodAffinity or PodAntiAffinity. As a result, it will co-locate or disperse Pods regardless of their versions. However, the scheduler cannot distinguish between old and new versions based on the `labelSelector` specified in `podAffinity` or `podAntiAffinity`. As a result, it will co-locate or disperse Pods regardless of their versions.
This can lead to sub-optimal scheduling outcome, for example: This can lead to sub-optimal scheduling outcome, for example:
- New version Pods are co-located with old version Pods (PodAffinity), which will eventually be removed after rolling updates. - New version Pods are co-located with old version Pods (`podAffinity`), which will eventually be removed after rolling updates.
- Old version Pods are distributed across all available topologies, preventing new version Pods from finding nodes due to PodAntiAffinity. - Old version Pods are distributed across all available topologies, preventing new version Pods from finding nodes due to `podAntiAffinity`.
`MatchLabelKeys` is a set of Pod label keys and addresses this problem. `matchLabelKeys` is a set of Pod label keys and addresses this problem.
The scheduler looks up the values of these keys from the new Pod's labels and combines them with `LabelSelector` The scheduler looks up the values of these keys from the new Pod's labels and combines them with `labelSelector`
so that PodAffinity matches Pods that have the same key-value in labels. so that podAffinity matches Pods that have the same key-value in labels.
By using label [pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label) in `MatchLabelKeys`, By using label [pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label) in `matchLabelKeys`,
you can ensure that only Pods of the same version are evaluated for PodAffinity or PodAntiAffinity. you can ensure that only Pods of the same version are evaluated for `podAffinity` or `podAntiAffinity`.
```yaml ```yaml
apiVersion: apps/v1 apiVersion: apps/v1
@ -43,11 +43,11 @@ metadata:
values: values:
- database - database
topologyKey: topology.kubernetes.io/zone topologyKey: topology.kubernetes.io/zone
matchLabelKeys: matchLabelKeys:
- pod-template-hash - pod-template-hash
``` ```
The above matchLabelKeys will be translated in Pods like: The above `matchLabelKeys` will be translated in Pods like:
```yaml ```yaml
kind: Pod kind: Pod
@ -68,26 +68,26 @@ metadata:
- key: pod-template-hash # Added from matchLabelKeys; Only Pods from the same replicaset will match this affinity. - key: pod-template-hash # Added from matchLabelKeys; Only Pods from the same replicaset will match this affinity.
operator: In operator: In
values: values:
- xyz - xyz
topologyKey: topology.kubernetes.io/zone topologyKey: topology.kubernetes.io/zone
matchLabelKeys: matchLabelKeys:
- pod-template-hash - pod-template-hash
``` ```
## `MismatchLabelKeys` - Service isolation ## `mismatchLabelKeys` - Service isolation
`MismatchLabelKeys` is a set of Pod label keys, like `MatchLabelKeys`, `mismatchLabelKeys` is a set of Pod label keys, like `matchLabelKeys`,
which looks up the values of these keys from the new Pod's labels, and merge them with `LabelSelector` as `key notin (value)` which looks up the values of these keys from the new Pod's labels, and merge them with `labelSelector` as `key notin (value)`
so that PodAffinity does _not_ match Pods that have the same key-value in labels. so that `podAffinity` does _not_ match Pods that have the same key-value in labels.
Suppose all Pods for each tenant get `tenant` label via a controller or a manifest management tool like Helm. Suppose all Pods for each tenant get `tenant` label via a controller or a manifest management tool like Helm.
Although the value of `tenant` label is unknown when composing each workload's manifest, Although the value of `tenant` label is unknown when composing each workload's manifest,
the cluster admin wants to achieve exclusive 1:1 tenant to domain placement for a tenant isolation. the cluster admin wants to achieve exclusive 1:1 tenant to domain placement for a tenant isolation.
`MismatchLabelKeys` works for this usecase; `mismatchLabelKeys` works for this usecase;
By applying the following affinity globally using a mutating webhook, By applying the following affinity globally using a mutating webhook,
the cluster admin can ensure that the Pods from the same tenant will land on the same domain exclusively, the cluster admin can ensure that the Pods from the same tenant will land on the same domain exclusively,
meaning Pods from other tenants won't land on the same domain. meaning Pods from other tenants won't land on the same domain.
```yaml ```yaml
@ -108,7 +108,7 @@ affinity:
topologyKey: node-pool topologyKey: node-pool
``` ```
The above matchLabelKeys and mismatchLabelKeys will be translated to like: The above `matchLabelKeys` and `mismatchLabelKeys` will be translated to like:
```yaml ```yaml
kind: Pod kind: Pod
@ -140,17 +140,17 @@ spec:
- key: tenant - key: tenant
operator: NotIn operator: NotIn
values: values:
- service-a - service-a
topologyKey: node-pool topologyKey: node-pool
``` ```
## Getting involved ## Getting involved
These features are managed by Kubernetes [SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling). These features are managed by Kubernetes [SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling).
Please join us and share your feedback. We look forward to hearing from you! Please join us and share your feedback. We look forward to hearing from you!
## How can I learn more? ## How can I learn more?
- [The official document of PodAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) - [The official document of podAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)
- [KEP-3633: Introduce MatchLabelKeys and MismatchLabelKeys to PodAffinity and PodAntiAffinity](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3633-matchlabelkeys-to-podaffinity/README.md#story-2) - [KEP-3633: Introduce matchLabelKeys and mismatchLabelKeys to podAffinity and podAntiAffinity](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/3633-matchlabelkeys-to-podaffinity/README.md#story-2)