Skip to content

feat: add optional autoscaler replicas and disruption budget - #276

Merged
hagaibarel merged 2 commits into
coredns:masterfrom
m-yosefpor:autoscaler-replicas-pdb
Oct 1, 2026
Merged

hagaibarel merged 2 commits into
coredns:masterfrom
m-yosefpor:autoscaler-replicas-pdb

Conversation

@m-yosefpor

Copy link
Copy Markdown
Contributor

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.replicaCount and autoscaler.podDisruptionBudget settings. 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:

  • I have bumped the chart version according to versioning.
  • I have updated the chart changelog with all the changes that come with this pull request according to changelog.
  • Any new values are backwards compatible and/or have sensible default.
  • I have signed off all my commits as required by DCO.

@hagaibarel

Copy link
Copy Markdown
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
m-yosefpor force-pushed the autoscaler-replicas-pdb branch from eb6769b to 0e50649 Compare September 29, 2026 13:03
@m-yosefpor

Copy link
Copy Markdown
Contributor Author

@hagaibarel done. Thanks.

@hagaibarel hagaibarel left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nits. I haven't fully tested the suggestions, if the tests fail because of them we can leave these as-is

Comment thread charts/coredns/templates/deployment-autoscaler.yaml
Comment thread charts/coredns/values.yaml
Signed-off-by: Matt Yosefpor <matt.yosefpor@nebius.com>
@hagaibarel
hagaibarel merged commit 807de5f into coredns:master Oct 1, 2026
2 checks passed
@hagaibarel

Copy link
Copy Markdown
Collaborator

Thanks for the PR!

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
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.

2 participants