Suspending CronJob will break CronJobs with startingDeadlineSeconds about kube-downscaler

[graillus]

I did some tests on 2 different GKE clusters (kubernetes 1.15):

• On the first cluster, I created 2 CronJobs, scheduled every minute, one with startingDeadlineSeconds set to 60, the other to 0.
• On the other cluster, running slighlty modified version of the kube-downscaler (without the set spec.startingDeadlineSeconds to 0 on resume), same CronJobs.
• Annotated all these CronJobs to make them enter a downtime period for 10 minutes.

Observations after downtime:

• Only CronJob running with patched downscaler and with original startingDeadlineSeconds different from 0 resumed as expected.
• Setting the startingDeadlineSeconds to 0 seems to give no chance to CronJobs to schedule new jobs after resume.

Looks like setting the startingDeadlineSeconds to 0 is never a good idea :/

[hjacobs]

Related: zalando-incubator/kubernetes-on-aws#3150

[graillus]

Why is the CronJob's spec.startingDeadlineSeconds reset to 0 in the first place ? I guess there is a valid reason behind this, but why not leaving the original value ?

[hjacobs]

@graillus I have the same question.

[hjacobs]

The fix was released in https://github.com/hjacobs/kube-downscaler/releases/tag/20.4.4