[feature request] support cloneset update policy not to delete pvc during recreate update

[FillZpp]

What would you like to be added:
support cloneset update policy not to delete pvc during recreate update

Why is this needed:
sometimes we need to keep existing pvc during update

[FillZpp]

/cc @furykerry

[furykerry]

is an advanced statefulset a better fit here ?

[FillZpp]

it may not be a stateful application and without any index orders. For example the pvc only stores cache data which means the pod and pvc can be migrated to somewhere else, but it will be better if we can keep the cache during update.

[furykerry]

advanced statefulset support unorderedUpdate, so the index order does not affect much.

[FillZpp]

not only update, we may want to delete any specific pods of the workload and don't want to use the ordinals skip, which is too complicated to manage through lifecycle.

in fact, we don't care about the ordinal at all, on the contrary, it will bring us a lot of trouble in management.

[FillZpp]

since clonset supports pvc template and we do support keep and reuse the pvc during pod recreation, I think it's reasonable to have a policy for update?

[FillZpp]

I'm evaluating the feasibility and cost of using kruise in some scenarios :)

[furykerry]

not only update, we may want to delete any specific pods of the workload and don't want to use the ordinals skip, which is too complicated to manage through lifecycle.

i am not against to implement keep the pvc during recreate, actually we can extend the behavior of disablePVCreuse to enable keeping the pvc. However the compatibility must be considered, maybe a feature gate is required to change the default behavior of disablePVCreuse

[FillZpp]

yea, that makes sense.

since the disablePVCreuse is in scale strategy, I thought if we can add a policy field in update policy instead of changing the existing behavior. Like we have two MaxUnavailable fields in scale and update strategies.

adding a feature-gate which is valid for all CloneSets is another option.

maybe the former one is more flexible?

[furykerry]

disablePVCreuse in update policy sounds good to me. but we can discuss it in the community call, since existing disablePVCreuse in scale policy already sounds a misnomer to me (it can also control the eviction case).