From 14bd4e5e3ab7fec13f3a3218617f65b45d01f908 Mon Sep 17 00:00:00 2001 From: mochizuki875 Date: Fri, 31 Jan 2025 05:05:28 +0000 Subject: [PATCH 1/4] Add deprecation notices related to matchLabelKeys/mismatchLabelKeys --- .../en/docs/concepts/scheduling-eviction/assign-pod-node.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index 5a6d18baf6..88d9a7360d 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -377,6 +377,8 @@ when satisfying the Pod (anti)affinity. The keys are used to look up values from the pod labels; those key-value labels are combined (using `AND`) with the match restrictions defined using the `labelSelector` field. The combined filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation. +It's not recommended to use `matchLabelKeys` with labels that might be updated +because the update of the label isn't reflected onto the merged `LabelSelector`. A common use case is to use `matchLabelKeys` with `pod-template-hash` (set on Pods managed as part of a Deployment, where the value is unique for each revision). @@ -424,6 +426,8 @@ When you want to disable it, you have to disable it explicitly via the Kubernetes includes an optional `mismatchLabelKeys` field for Pod affinity or anti-affinity. The field specifies keys for the labels that should **not** match with the incoming Pod's labels, when satisfying the Pod (anti)affinity. +It's not recommended to use `mismatchLabelKeys` with labels that might be updated +because the update of the label isn't reflected onto the merged `LabelSelector`. 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. In other words, you want to avoid running Pods from two different tenants on the same topology domain at the same time. From 8f470ed74079a5200d6826956d851678d47879eb Mon Sep 17 00:00:00 2001 From: mochizuki875 Date: Fri, 31 Jan 2025 08:48:53 +0000 Subject: [PATCH 2/4] fix1 --- .../concepts/scheduling-eviction/assign-pod-node.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index 88d9a7360d..e7be145321 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -377,8 +377,11 @@ when satisfying the Pod (anti)affinity. The keys are used to look up values from the pod labels; those key-value labels are combined (using `AND`) with the match restrictions defined using the `labelSelector` field. The combined filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation. + +{{< warning >}} It's not recommended to use `matchLabelKeys` with labels that might be updated -because the update of the label isn't reflected onto the merged `LabelSelector`. +because the update of the label isn't reflected onto the merged `labelSelector`. +{{< /warning >}} A common use case is to use `matchLabelKeys` with `pod-template-hash` (set on Pods managed as part of a Deployment, where the value is unique for each revision). @@ -426,8 +429,11 @@ When you want to disable it, you have to disable it explicitly via the Kubernetes includes an optional `mismatchLabelKeys` field for Pod affinity or anti-affinity. The field specifies keys for the labels that should **not** match with the incoming Pod's labels, when satisfying the Pod (anti)affinity. -It's not recommended to use `mismatchLabelKeys` with labels that might be updated -because the update of the label isn't reflected onto the merged `LabelSelector`. + +{{< warning >}} +It's not recommended to use `matchLabelKeys` with labels that might be updated +because the update of the label isn't reflected onto the merged `labelSelector`. +{{< /warning >}} 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. In other words, you want to avoid running Pods from two different tenants on the same topology domain at the same time. From 4e3a60a68fe1d0aae90a8837b2192292fdb7fdc2 Mon Sep 17 00:00:00 2001 From: mochizuki875 Date: Fri, 31 Jan 2025 12:44:02 +0000 Subject: [PATCH 3/4] fix2 --- .../docs/concepts/scheduling-eviction/assign-pod-node.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index e7be145321..be874fcea6 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -378,10 +378,10 @@ The keys are used to look up values from the pod labels; those key-value labels (using `AND`) with the match restrictions defined using the `labelSelector` field. The combined filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation. -{{< warning >}} +{{< caution >}} It's not recommended to use `matchLabelKeys` with labels that might be updated because the update of the label isn't reflected onto the merged `labelSelector`. -{{< /warning >}} +{{< /caution >}} A common use case is to use `matchLabelKeys` with `pod-template-hash` (set on Pods managed as part of a Deployment, where the value is unique for each revision). @@ -430,10 +430,10 @@ Kubernetes includes an optional `mismatchLabelKeys` field for Pod affinity or anti-affinity. The field specifies keys for the labels that should **not** match with the incoming Pod's labels, when satisfying the Pod (anti)affinity. -{{< warning >}} +{{< caution >}} It's not recommended to use `matchLabelKeys` with labels that might be updated because the update of the label isn't reflected onto the merged `labelSelector`. -{{< /warning >}} +{{< /caution >}} 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. In other words, you want to avoid running Pods from two different tenants on the same topology domain at the same time. From aad1b7c987a37a7831a309e6b11d4afc35506634 Mon Sep 17 00:00:00 2001 From: mochizuki875 Date: Sat, 1 Feb 2025 17:22:38 +0000 Subject: [PATCH 4/4] fix3 --- .../concepts/scheduling-eviction/assign-pod-node.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index be874fcea6..7b1fe7203b 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -379,8 +379,9 @@ The keys are used to look up values from the pod labels; those key-value labels filtering selects the set of existing pods that will be taken into Pod (anti)affinity calculation. {{< caution >}} -It's not recommended to use `matchLabelKeys` with labels that might be updated -because the update of the label isn't reflected onto the merged `labelSelector`. +It's not recommended to use `matchLabelKeys` with labels that might be updated directly on pods. +Even if you edit the pod's label that is specified at `matchLabelKeys` **directly**, (that is, not via a deployment), +kube-apiserver doesn't reflect the label update onto the merged `labelSelector`. {{< /caution >}} A common use case is to use `matchLabelKeys` with `pod-template-hash` (set on Pods @@ -431,8 +432,9 @@ or anti-affinity. The field specifies keys for the labels that should **not** ma when satisfying the Pod (anti)affinity. {{< caution >}} -It's not recommended to use `matchLabelKeys` with labels that might be updated -because the update of the label isn't reflected onto the merged `labelSelector`. +It's not recommended to use `mismatchLabelKeys` with labels that might be updated directly on pods. +Even if you edit the pod's label that is specified at `mismatchLabelKeys` **directly**, (that is, not via a deployment), +kube-apiserver doesn't reflect the label update onto the merged `labelSelector`. {{< /caution >}} 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.