CP-43967: fix webhook pod anti-affinity selector - #882
Merged
Conversation
The webhook Deployment's hardcoded podAntiAffinity selected on a bare `app: webhook-server` label that no pod carries — pods are labeled `app.kubernetes.io/name: webhook-server` via cloudzero-agent.generateLabels. The rule matched zero pods and never spread the (default 3) webhook replicas across nodes, despite the template header advertising HA via anti-affinity. Correct the selector key to app.kubernetes.io/name so the existing soft (preferred, weight 100, kubernetes.io/hostname) rule actually spreads replicas, and format the $podAntiAffinity dict across multiple lines for readability. Behavior is unchanged for operators who override insightsController.server.affinity, which still takes precedence. - Add helm unit test asserting the selector matches the real pod label, the dead bare `app` key is gone, and the rule stays soft. - Regenerate tests/helm/template baselines (selector key flip across all topologies; no other rendered changes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
evan-cz
force-pushed
the
CP-43967-webhook-antiaffinity-selector
branch
from
June 30, 2026 21:20
97e6a3b to
3f60ee3
Compare
4 tasks
evan-cz
enabled auto-merge
June 30, 2026 21:30
amfelso
approved these changes
Jul 1, 2026
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
2 participants
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.
What
The webhook server Deployment hardcodes a soft
podAntiAffinityintended to spread replicas across nodes for high availability. Its selector matched on a bareapp: webhook-serverlabel that no webhook pod actually carries — pods are labeledapp.kubernetes.io/name: webhook-server(via the chart'sgenerateLabelshelper), and the chart never emits a bareapp:label anywhere.As a result the rule matched zero pods and was a silent no-op: the default 3 webhook replicas could all be scheduled onto a single node, despite the template advertising "High availability: Multiple replicas with anti-affinity for fault tolerance."
Fix
Correct the selector key to
app.kubernetes.io/name: webhook-serverso the existing soft rule (preferred, weight 100,topologyKey: kubernetes.io/hostname) actually spreads replicas across nodes. It remains a preferred constraint, so it never blocks scheduling on small or single-node clusters. Operator-supplied affinity viainsightsController.server.affinitycontinues to take precedence (the merge behavior is unchanged), and the template's HA claim is now accurate.The
$podAntiAffinitydict literal is also reformatted across multiple lines, matching the chart's existing style, for readability — no behavior change.Tests
appkey is gone, and the rule stays soft (weight 100 / hostname topology).helm lintclean.tests/helm/template/baselines — the only rendered change across all topologies is the selector key flip.