Skip to content

fix: worker HPA replicas ownership + parameterized rollout strategy - #121

Open
anchapin wants to merge 1 commit into
developfrom
fix/worker-hpa-replicas-ownership
Open

fix: worker HPA replicas ownership + parameterized rollout strategy#121
anchapin wants to merge 1 commit into
developfrom
fix/worker-hpa-replicas-ownership

Conversation

@anchapin

Copy link
Copy Markdown
Collaborator

Summary

  • Worker deployment no longer hardcodes spec.replicas: 1 — the HPA owns scaling across helm upgrades (prevents the scale-to-1 cliff where every helm upgrade reset the deployment to 1 replica while maxReplicas was in the thousands).
  • Rollout strategy maxSurge/maxUnavailable parameterized; defaults replicate prior hardcoded 1/1.
  • PriorityClasses render unconditionally. The previous lookup guard omitted already-existing classes from the manifest, so helm upgrade deleted the cluster-scoped PriorityClass out from under running pods.

Verification

  • helm template renders all three value variants; live-cluster upgrade path exercised by the stacked PR branch.

- worker deployment: remove hardcoded spec.replicas so the HPA owns
  scaling across helm upgrades. Helm's three-way merge preserves fields
  absent from the manifest; a hardcoded value would reset the deployment
  to 1 replica on every upgrade (scale-to-1 cliff at high maxReplicas).
- worker rollout strategy: parameterize maxSurge/maxUnavailable with
  defaults replicating the previous hardcoded 1/1 behavior.
- PriorityClasses: render unconditionally instead of guarding on a
  cluster lookup. When the class already existed, the guard omitted it
  from the manifest, causing helm upgrade to delete the cluster-scoped
  PriorityClass out from under running pods.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant