From 446d46587984d470ab2ea1caa0c3cea7eff926c2 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Mon, 2 Sep 2024 10:40:36 +0800 Subject: [PATCH] Clean up 2024-08-16-matchlabelkeys-podaffinity.md --- .../2024-08-16-matchlabelkeys-podaffinity.md | 60 +++++++++---------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/content/en/blog/_posts/2024-08-16-matchlabelkeys-podaffinity.md b/content/en/blog/_posts/2024-08-16-matchlabelkeys-podaffinity.md index 6873debbdf..37e74e66d0 100644 --- a/content/en/blog/_posts/2024-08-16-matchlabelkeys-podaffinity.md +++ b/content/en/blog/_posts/2024-08-16-matchlabelkeys-podaffinity.md @@ -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. +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. 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 @@ -43,11 +43,11 @@ metadata: values: - database topologyKey: topology.kubernetes.io/zone - matchLabelKeys: + matchLabelKeys: - pod-template-hash ``` -The above matchLabelKeys will be translated in Pods like: +The above `matchLabelKeys` will be translated in Pods like: ```yaml kind: Pod @@ -68,26 +68,26 @@ metadata: - key: pod-template-hash # Added from matchLabelKeys; Only Pods from the same replicaset will match this affinity. operator: In values: - - xyz + - xyz topologyKey: topology.kubernetes.io/zone - matchLabelKeys: + matchLabelKeys: - 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. +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. -`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, +`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. ```yaml @@ -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 @@ -140,17 +140,17 @@ spec: - key: tenant operator: NotIn values: - - service-a + - service-a topologyKey: node-pool ``` -## Getting involved +## Getting involved 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! -## 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) -- [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)