Repository navigation
feat: add optional autoscaler replicas and disruption budget - #276
Merged
Merged
Conversation
Collaborator
|
Hi @m-yosefpor, PR looks good, please rebase and update the version and changelog in Chart.yaml, thanks! |
Signed-off-by: Matt Yosefpor <matt.yosefpor@nebius.com>
m-yosefpor
force-pushed
the
autoscaler-replicas-pdb
branch
from
September 29, 2026 13:03
eb6769b to
0e50649
Compare
Contributor
Author
|
@hagaibarel done. Thanks. |
hagaibarel
requested changes
Sep 29, 2026
hagaibarel
left a comment
Collaborator
There was a problem hiding this comment.
Small nits. I haven't fully tested the suggestions, if the tests fail because of them we can leave these as-is
Signed-off-by: Matt Yosefpor <matt.yosefpor@nebius.com>
hagaibarel
approved these changes
Oct 1, 2026
Collaborator
|
Thanks for the PR! |
1 task
1 task
Merged
1 task
1 task
gavinmcfall
added a commit
to gavinmcfall/home-ops
that referenced
this pull request
Oct 19, 2026
coredns here is the cluster's only DNS — fullnameOverride: coredns, k8sAppLabelOverride: kube-dns, service.name: kube-dns, clusterIP 10.96.0.10. It has been running a single replica against the chart's default rollingUpdate.maxUnavailable=1, which terminates the one pod before its replacement is Ready. Every chart or image bump was therefore a cluster-wide DNS gap, however brief. Two replicas let one pod roll while the other keeps serving, and a PodDisruptionBudget with minAvailable: 1 stops a node drain or eviction from taking both at once. Both keys are supported by the chart currently pinned (1.47.1): its values.yaml carries replicaCount and a main-Deployment podDisruptionBudget. The "disruption budget" added in chart 1.48.2 (coredns/helm#276) is a separate autoscaler.podDisruptionBudget, not this one, so nothing here depends on that bump landing first. Verified by rendering the real values file against both 1.47.1 and 1.48.2: each produces replicas: 2 and one PodDisruptionBudget whose selector (app.kubernetes.io/instance, k8s-app, app.kubernetes.io/name) matches the Deployment's own selector. kustomize build confirms the generated coredns-helm-values ConfigMap carries both keys. The Deployment is pinned to control-plane nodes (requiredDuringScheduling node-role.kubernetes.io/control-plane Exists, plus the CriticalAddonsOnly and control-plane tolerations) and there are three of them, so the second replica schedules. This is a prerequisite for #2761 (chart 1.47.1 -> 1.48.2), which moves CoreDNS 1.14.6 -> 1.14.7 and makes the container run as the image's non-root user by default. Assisted-by: Claude Code (claude-opus-5) Agentically-Engineered: https://nerdz.cloud/agentic-engineering
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
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.
Why is this pull request needed and what does it do?
The chart currently does not expose a replica count or PodDisruptionBudget for the cluster-proportional-autoscaler.
This PR adds optional
autoscaler.replicaCountandautoscaler.podDisruptionBudgetsettings. Existing behavior is preserved: the replica count remains unset by default, and no autoscaler PDB is created.The PDB follows the autoscaler Deployment’s enablement conditions and selector, supports an explicit selector override, and respects autoscaler label configuration.
Multiple autoscaler replicas run independently without leader election. The documentation explains the potential for concurrent scaling updates. Maintainer feedback on supporting this opt-in configuration is welcome.
Includes documentation, a chart version bump to
1.47.2, and unit tests. All 45 unit tests and Helm lint pass. Multi-replica runtime behavior has not been tested.Which issues (if any) are related?
Related discussion: kubernetes-sigs/cluster-proportional-autoscaler#112
Checklist: