score/apps: accept topologySpreadConstraints as host anti-affinity - #696
Open
ChrisJr404 wants to merge 1 commit into
Open
score/apps: accept topologySpreadConstraints as host anti-affinity#696ChrisJr404 wants to merge 1 commit into
ChrisJr404 wants to merge 1 commit into
Conversation
The host podAntiAffinity check warned even when a Deployment or StatefulSet already spread its pods with topologySpreadConstraints. A constraint on kubernetes.io/hostname (or a zone/region key) keeps replicas off the same node just like anti-affinity does, so treat it as satisfying the check. The constraint has to target an approved topology key and carry a labelSelector that matches the pod's own labels, otherwise we can't tell it spreads this workload and keep warning. Fixes zegl#613
|
@ChrisJr404 is attempting to deploy a commit to the Gustav Westling's projects Team on Vercel. A member of the Team first needs to authorize it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stop the host podAntiAffinity check from warning when a workload already spreads its pods with topologySpreadConstraints, since a hostname/zone/region constraint keeps replicas off the same node the same way anti-affinity does.
This is the case from #613: a Deployment with a
kubernetes.io/hostnamespread constraint (maxSkew, DoNotSchedule) still got flagged for a missing anti-affinity rule, even though it was already spread across nodes. Anti-affinity forces one pod per node; a spread constraint gets you the same availability but lets pods share a node once the skew allows, so it seemed wrong to demand anti-affinity on top of it.I kept it conservative so nobody who was passing before starts failing. The check only counts a constraint if it uses one of the topology keys the anti-affinity check already approves (
kubernetes.io/hostname,topology.kubernetes.io/zone,topology.kubernetes.io/region, plus the deprecated failure-domain keys) and carries a labelSelector that matches the pods own template labels. No approved key, or a selector that does not match, and it keeps warning like before. The approved-key set is now shared between the two helpers instead of being duplicated.Added table cases in apps_test.go covering both Deployment and StatefulSet: spread on hostname (ok), spread on zone (ok), spread on an unapproved key (still warns), selector that does not match the pod (still warns), and a constraint with no labelSelector (still warns).
go test ./...passes.RELNOTE: The Deployment/StatefulSet host podAntiAffinity check now also accepts an equivalent topologySpreadConstraints as satisfying the check.
Fixes #613