fix(chart): scope server Deployment selector to component=server#103
Merged
Conversation
The server Deployment selector was only {name, instance}, with no
component label — a superset that matches the frontproxy, redis and
dashboard pods too (they all carry name+instance). The Deployment
controller is unaffected (ReplicaSets disambiguate via
pod-template-hash), but anything reading the bare selector over-matches.
Concretely this breaks a Resource-metric HPA targeting this Deployment:
the HPA inherits the target's selector and averages CPU across all four
components. The near-idle frontproxy/redis/dashboard requests dilute the
average (~90% server-only -> ~68% blended), suppressing scale-up.
The Services already scope with component=server; only the Deployment
selector omitted it. The pod template already carries the label, so this
only tightens the selector.
Note: .spec.selector is immutable — rolling this out requires a one-time
delete/recreate of the existing Deployment.
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.
Problem
The server
Deployment's.spec.selectoris only{app.kubernetes.io/name, app.kubernetes.io/instance}— it omits thecomponentlabel. Since the frontproxy, redis and dashboard pods all carry the same name+instance labels, that selector is a superset matching every pod in the release.The Deployment controller itself is fine (its ReplicaSets disambiguate ownership via
pod-template-hash), but any consumer that reads the bare.spec.selectorover-matches. The concrete breakage:A
HorizontalPodAutoscalerwith aResource(CPU) metric targeting this Deployment inherits the target's selector verbatim and averages CPU across all four components. The near-idle frontproxy/redis/dashboard pods carry ~2600m of CPU requests at almost no usage, diluting the average:That keeps the computed utilisation pinned just under target and suppresses scale-up, so the HPA never reaches its max replicas under real server load.
Fix
Add
app.kubernetes.io/component: serverto the server Deployment selector. The Services (incl. headless) already scope withcomponent: server; only the Deployment selector omitted it. The pod template already carries the label, so this only tightens the selector — no other change.Rollout caveat
.spec.selectoris immutable. Applying this to an existing Deployment fails withfield is immutable; rolling it out requires a one-time delete + recreate of thes3proxy-pythonDeployment (e.g. ArgoCDReplace=trueorkubectl delete deployment s3proxy-python). Frontproxy queues/redispatches during the brief gap.Verify
helm templatenow renders the server Deployment selector withcomponent: server, matching the pod template labels;helm lintpasses.