Provide support for scale-to-zero in Kubernetes Workload scaler and integrate pod condition status

[tacf]

Proposal

Kubernetes Workload Scaler currently has limitations with downscaling, that prevent using it to as a rollout mecanism to switch a workload with a totally diferent one (check use-case)

The proposal here is to

1. Allow the use of '0' value for parameter value
2. Look at not only pod phase but also pod condition status. Currently the scaler activates with pods in running state, but it means that there may be downtime for this particular use case since Running != Ready

Use-Case

The actual use that we were trying to leverage was migration to Argo Rollouts. Currently there is no easy way to do this (even documentation recommends running both workloads in parallel and only then deleting the Deployment and work with the Rollout only). The Argo Rollout suggestion may work well within smaller companies, but at scale the whole procces may lead to a big operational overhead.

Since we use Keda and there is already a scaler that based itself into looking inside the cluster, it would be a perfect solution for these sorts of migrations, as everything is self contained (within the cluster. No external API or metrics required)

Is this a feature you are interested in implementing yourself?

Maybe

Anything else?

Discussion reference: #4393

[tomkerkhove]

Fair request and good idea!

[JorTurFer]

Hi,

1. Allow the use of '0' value for parameter value

I don't get the goal you are trying to reach. This would disable the autoscaling as value is the target value, and this can be done with the pause annotation.

2. Look at not only pod phase but also pod condition status. Currently the scaler activates with pods in running state, but it means that there may be downtime for this particular use case since Running != Ready

This makes sense totally, Running doesn't mean Ready, maybe adding an extra field to limit the pod statuses to a subset of the possible options we could improve the process, making it smarter

I have checked the discussion and I guess that just adding the extra field for selecting the phase for being included could solve your use case, am I right?

[tomkerkhove]

1. Allow the use of '0' value for parameter value

I don't get the goal you are trying to reach. This would disable the autoscaling as value is the target value, and this can be done with the pause annotation.

The goal is to support scale-to-zero similar to other scalers, no?

[tacf]

@JorTurFer it's exactly what @tomkerkhove said. Setting the target to zero would allow one deployment to start scaling down to zero while another is scaling up. It's a sort of rolling update between workloads.

[JorTurFer]

The goal is to support scale-to-zero similar to other scalers, no?

Kubernetes Workload already supports scaling to zero, If you set for example value: 1 and the monitored workload has 0 instances, your scaled workload will scale to 0

[tacf]

But in that case is the other way around.

What i'm suggestin is:

• Launch a new Workload
• The new workload has it's own scaler with it's own specs
• Set the current workload with a kubernetes-workload scaler looking into the new workload in order to scale-to-zero as the new workload starts running.