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

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

@ -7,25 +7,25 @@ author: >
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.
## `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.
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:
- 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.
- 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`.
`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`
so that PodAffinity matches Pods that have the same key-value in labels.
`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`
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`,
you can ensure that only Pods of the same version are evaluated for PodAffinity or PodAntiAffinity.
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`.
```yaml
apiVersion: apps/v1
@ -47,7 +47,7 @@ metadata:
- pod-template-hash
```
The above matchLabelKeys will be translated in Pods like:
The above `matchLabelKeys` will be translated in Pods like:
```yaml
kind: Pod
@ -74,18 +74,18 @@ metadata:
- pod-template-hash
```
## `MismatchLabelKeys` - Service isolation
## `mismatchLabelKeys` - Service isolation
`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)`
so that PodAffinity does _not_ match Pods that have the same key-value in labels.
`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)`
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.
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.
`MismatchLabelKeys` works for this usecase;
`mismatchLabelKeys` works for this usecase;
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,
meaning Pods from other tenants won't land on the same domain.
@ -108,7 +108,7 @@ affinity:
topologyKey: node-pool
```
The above matchLabelKeys and mismatchLabelKeys will be translated to like:
The above `matchLabelKeys` and `mismatchLabelKeys` will be translated to like:
```yaml
kind: Pod
@ -152,5 +152,5 @@ Please join us and share your feedback. We look forward to hearing from you!
## How can I learn more?
- [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)
- [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)