Skip to content

Revert "Update the description of TopologySpreadConstraints's matchLabelKeys to align with the design change" #50164

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 21, 2025
Merged

Revert "Update the description of TopologySpreadConstraints's matchLabelKeys to align with the design change" #50164

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 9 additions & 15 deletions content/en/docs/concepts/scheduling-eviction/topology-spread-constraints.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,24 +131,18 @@ your cluster. Those fields are:
See [Label Selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
for more details.

- **matchLabelKeys** is a list of pod label keys to select the group of pods over which
the spreading skew will be calculated. At a pod creation,
the kube-apiserver uses those keys to lookup values from the incoming pod labels,
and those key-value labels will be merged with any existing `labelSelector`.
The same key is forbidden to exist in both `matchLabelKeys` and `labelSelector`.
`matchLabelKeys` cannot be set when `labelSelector` isn't set.
Keys that don't exist in the pod labels will be ignored.
A null or empty list means only match against the `labelSelector`.

{{< caution >}}
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 >}}
- **matchLabelKeys** is a list of pod label keys to select the pods over which
spreading will be calculated. The keys are used to lookup values from the pod labels,
those key-value labels are ANDed with `labelSelector` to select the group of existing
pods over which spreading will be calculated for the incoming pod. The same key is
forbidden to exist in both `matchLabelKeys` and `labelSelector`. `matchLabelKeys` cannot
be set when `labelSelector` isn't set. Keys that don't exist in the pod labels will be
ignored. A null or empty list means only match against the `labelSelector`.

With `matchLabelKeys`, you don't need to update the `pod.spec` between different revisions.
The controller/operator just needs to set different values to the same label key for different
revisions. For example, if you are configuring a Deployment, you can use the label keyed with
revisions. The scheduler will assume the values automatically based on `matchLabelKeys`. For
example, if you are configuring a Deployment, you can use the label keyed with
[pod-template-hash](/docs/concepts/workloads/controllers/deployment/#pod-template-hash-label), which
is added automatically by the Deployment controller, to distinguish between different revisions
in a single Deployment.
Expand Down