[feature request] 根据label选择器控制缩容顺序

[ccimber]

当前我们在使用cloneset的场景中，存在两种情况：

1. 原地升级，通过同一CloneSet进行更新
2. 非原地升级，通过两个CloneSet进行更新
   当原地升级中断后进行非原地升级，可能会出现如下场景：

C1,C2=CloneSet1,Cloneset2
rA,rB,rC=版本A,版本B,版本C
# 总实例共10个
# 第一次原地升级至3个时中断
C1: rA=>7,rB=>3

# 第二次非原地升级
# Case1，期望先保留B，更新至2个时的状态期望为
C1: rA=>5,rB=>3
	partition=5
C2: rC=>2

# Case2，期望先保留A，更新至3个时的状态期望为
C1: rA=>7,rB=>1
	partition=7
C2: rC=>2

期望能同时覆盖Case1和Case2以支持不同业务场景下的业务行为。
PS: 当前会给不同的版本Pod打上不同的label revision以进行版本的描述
PSS: 如果觉得合理，我们愿意提交这个PR。 ; )

[ABNER-1]

Hello @ccimber .
I understand that if there is a controller that assigns different "deletion-cost" labels to the corresponding versions based on the corresponding requirements, this demand can be realized.

Compared to implementing this feature in the cloneset controller, this solution seems more concise. What do you think are the advantages of this feature?

[ccimber]

Hi @ABNER-1 .
Thank you for the feedback from the community. I would like to further elaborate on the rationale behind this feature request.

Our original proposal stems from the natural alignment between update strategies and scaling strategies in workload management. Since updateStrategy is already a mandatory specification during rolling updates, it would be logically consistent to extend scaleStrategy with similar flexibility for scale-down operations - particularly given that CloneSet already implements a basic scaleStrategy mechanism.

While CloneSet's current scaleStrategy implementation (limited to podsToDelete) provides strict control, it doesn't address more sophisticated scaling scenarios requiring custom prioritization. Our request focuses on expanding scaleStrategy's semantics to enable:

1. Ordered scaling preferences through annotation-based weighting
2. Custom prioritization logic beyond simple deletion marking

We recognize the alternative solution of introducing a separate controller for deletion-cost annotation management. However, this approach would:

• Introduce disproportionate complexity for a single use case
• Create additional maintenance overhead for platform control planes
• Fragment scaling configuration across multiple components

By enhancing the existing scaleStrategy paradigm instead, we can:
① Maintain architectural consistency with Kubernetes' design philosophy
② Reduce cognitive load for operators
③ Avoid redundant controller proliferation

This extension would provide a cohesive strategy framework while preserving backward compatibility, offering a more Kubernetes-native solution to scaling prioritization challenges.