Dhawan Shringi:
https://github.com/dgkanatsios/CKAD-exercises/issues/174
unnivkn:
The .spec.startingDeadlineSeconds field is optional. It stands for the deadline in seconds for starting the job if it misses its scheduled time for any reason. After the deadline, the cron job does not start the job. Jobs that do not meet their deadline in this way count as failed jobs.
unnivkn:
The activeDeadlineSeconds applies to the duration of the job, no matter how many Pods are created. Once a Job reaches activeDeadlineSeconds, all of its running Pods are terminated and the Job status will become type: Failed with reason: DeadlineExceeded.
unnivkn:
So the answer is : startingDeadlineSeconds
Dhawan Shringi:
Based on the docs:
For every CronJob, the CronJob Controller checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error
It is important to note that if the startingDeadlineSeconds field is set (not nil), the controller counts how many missed jobs occurred from the value of startingDeadlineSeconds until now rather than from the last scheduled time until now.
So, it should be activeDeadlineSeconds 
Dhawan Shringi:
The above post doesn’t talk much about startingDeadlineSeconds and based on the documentation, my understanding is that the cron job controller uses the parameter startingDeadlineSeconds to see if there where more than 100 misses in the last duration of startingDeadlineSeconds if not, it will allow the execution of cron job.
pikachunetes:
I think the question is a little ambiguous as it talks about the termination of the cronjob itself and not the job created by it. startingDeadlineSeconds and activeDeadlineSeconds both can terminate the job and not the whole cronjob.
but still, the former option looks more promising.
Dhawan Shringi:
It talks about startingDeadlineSeconds https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron-job-limitations|here, however it doesn’t say anywhere that the parameter can terminate a cronjob, not in the official documentation. Maybe we’ll have to implement it to be 100 percent sure and yes, it is certainly ambiguous question.
unnivkn:
Read here: Starting Deadline https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
Fernando Jimenez:
startingDeadlineSeconds makes the most sense in combination with Currency Policy Forbid. That’s why it is by default unset.
With a Current Policy Forbid, you are telling Kubernetes that you do not want more than one job running at a time. This is important if your job takes longer and overlaps with the next time the scheduled job should start. The startingDeadlineSeconds still allows a job to start past the schedule, if the previous job has finished. It also prevents the lockdown of more than 100 fails.
Fernando Jimenez:
Based on the original question, the actual answer should be activeDeadlineSeconds
pikachunetes:
Great explanation there!
@Fernando Jimenez, can you pls explain how does activeDeadlineSeconds fits right in the original question. That’s still a grey area for me.
“job should be terminated if it takes more than 17 seconds to start execution after its schedule”
Fernando Jimenez:
Let’s say you have a cronjob. That cronjob is nothing more than a job in an repeating schedule. Let’s say than you schedule it for one minute. That means every minute kubernetes is going to start a job and the job is going to start one or more pods to do the task(s). With that setup, there’s nothing that will guarantee that the pods are going to do finish within that period of time of one minute (between one started job and the next one). Which means that you might have multiple jobs running at the same time. However, if you want to guarantee that the job (the pods running) will not run for more than you want, then you setup activeDeadlineSeconds and Kuberentes will keep an eye and will not let it run more than that.
Fernando Jimenez:
I do agree that "start execution after its schedule" is the troubled part in the whole request.
A cronjob is going to try to make a job run continually until the job returns a completed (success). It will try and try with an added delay introduced each time and by default it will stop after six times. If what is asked is to prevent that from happening then the startingDeadlineSeconds might prevent from retrying. I might need to reconsider and recant my original affirmation that the answer is activeDeadlineSeconds. It seems that it makes more sense from that perspective.
pikachunetes:
Apologies for making the thread long @Fernando Jimenez
Acc. to the question we want to run a job every 60 seconds and want the job to fail _i_t takes more than 17 seconds to start execution after its schedule.
Let’s consider the job takes 20 seconds to execute,
So setting activeDeadlineSeconds=17 in the original question, Acc to me will not solve the purpose.
Rather setting startingDeadlineSeconds=17 will.
Pls, correct me if I am wrong.
pikachunetes:
So does it make startingDeadlineSeconds the correct answer or still I am missing something
Fernando Jimenez:
You are correct based that it appears to be referring to the cronjob and not to the work that the job has to do.
Fernando Jimenez:
Maybe it makes more sense to think like this:
If it is concerning with what the cronjob is doing, then startingDeadlineSeconds is the answer.
If it is concerning with what the Job is doing, then the activeDeadLineSeconds makes more sense.