ReplicaSet Consolidation-Aware Scale-In Strategy

[nathangeology]

Enhancement Description

• enhancement description: Add a consolidation-aware pod deletion heuristic to the ReplicaSet controller that prefers removing pods from nodes with fewer active pods during scale-down, enabling node autoscalers to reclaim nodes with less disruption.
• Kubernetes Enhancement Proposal: KEP-5982: ReplicaSet Consolidation-Aware Scale-In Strategy #6019
• Discussion Link: Presented at sig-apps meeting 2026-04-13. See also kubernetes#107598 (Jan 2022 sig-apps discussion) and kubernetes#123541 (wg-serving feedback to related proposal).
• PRs by stage and milestone:
  • Alpha - v1.37
    • KEP (k/enhancements) update PR(s): KEP-5982: ReplicaSet Consolidation-Aware Scale-In Strategy #6019
    • Code (k/k) update PR(s):
    • Docs (k/website) update PR(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

/sig apps

[k8s-ci-robot]

@nathangeology: You must be a member of the kubernetes/milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility.

Details

In response to this:

Summary

This issue tracks the KEP for adding a consolidation-aware scale-in heuristic to the ReplicaSet controller's pod deletion algorithm.

When the ConsolidatingScaleDown feature gate is enabled, the ReplicaSet controller prefers deleting pods on nodes with fewer total active pods during scale-down, enabling workload consolidation onto fewer nodes. It also respects do-not-disrupt signals so that pods on protected nodes are deprioritized for deletion.

Motivation

The current ReplicaSet scale-down algorithm prefers deleting pods on nodes with more colocated replicas (a spreading heuristic). While this promotes even distribution, it actively works against node consolidation. Node autoscalers (Karpenter, cluster-autoscaler) can only reclaim nodes when workloads consolidate during scale-down, but the spreading heuristic distributes deletions evenly, leaving every node partially occupied.

KEP-2255 (PodDeletionCost) provides a mechanism via annotations, but requires an external controller to continuously update annotations before scale-down events — operationally complex and API-server intensive.

Key Design Points

• Feature gate: ConsolidatingScaleDown (kube-controller-manager)
• Owning SIG: sig-apps
• Target milestone: v1.37 (alpha)
• Generic do-not-disrupt annotation to avoid coupling with any specific node autoscaler
• Complementary to KEP-2255 (PodDeletionCost) — both mechanisms coexist, with PodDeletionCost taking precedence in the existing sort order
• Zero overhead when disabled — conditional node informer initialization

Related

• KEP-2255: PodDeletionCost
• PROPOSAL configurable down-scaling behaviour in ReplicaSets & Deployments kubernetes#107598
• PROPOSAL - extend 'scale' subresource API to support pod-deletion-cost kubernetes#123541

KEP

KEP directory: keps/sig-apps/NNNN-replicaset-consolidation-scale-in/

/sig apps
/stage alpha
/milestone v1.37

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[BenTheElder]

There's a standard issue template for KEPs with required metadata, can you update the issue body to reflect the template?

You can view https://github.com/kubernetes/enhancements/issues => "Enhancement tracking issue"

Removed "KEP:" from title, by default all issues here are KEPs and the issue number is the KEP identifier.

To file a KEP you will need more than the issue, the summary/motivation/design etc should be in a PR following the standard enhancement proposal format where it will be reviewed, not in the KEP issue.

https://github.com/kubernetes/enhancements/blob/master/README.md has the process.

Thanks.

[nathangeology]

Updated the format of the issue and linked it to a placeholder KEP. I'll work up and share something more useful for discussion next week.