Welcome to the Linux Foundation Forum!

Exercise 4.3 part 5-6: activeDeadlineSeconds is in the wrong spec

Options
TBBle
TBBle Posts: 13
edited January 2022 in LFD259 Class Forum

Undertaking the given exercise, I have the following in cronjob.yaml:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: sleepy
spec:
  schedule: "*/2 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          activeDeadlineSeconds: 10
          containers:
          - name: resting
            image: busybox
            command: ["/bin/sleep"]
            args: ["30"]
          restartPolicy: Never

When I create this CronJob, I do not see the described behaviour for the exercise:

Ensure that if the job continues for more than 10 seconds it is terminated.

Instead, I am seeing that each two minutes, a new Job is created (as expected) but after 10 seconds, the Pod for the Job is marked DeadlineExceeded, (and eventually Completed), but a new Pod is created by the Job, i.e. it's retrying rather than terminated.

This is actually visible in the example output during step 6, which shows in the second-last output, a Job over 2 minutes old which has not been cleaned up.


Huh. While I was writing this up, one of the Jobs finally failed, with Job has reached the specified backoff limit, after almost 12 minutes.

That matches the backoffLimit: 6 seen in the default Job earlier in the lesson, and I can see that in the Job docs, but it wasn't touched upon in the lesson.

I'd suggest maybe setting that to 1 or 0 in order to illustrate the point being made in a timely manner?


And now I'm in the docs, perhaps the problem is that activeDeadlineSeconds should be in the jobTemplate.spec, not the (PodSpec)jobTemplate.spec.template.spec, where it was added in Step 5.

It was in the Job's spec in Exercise 4.2 Step 11 as well, when the behaviour was correct.

Trying it that way, I now see the Jobs created by the CronJob are marked Failed and terminated after 10 seconds, per the exercise description.

And the failed Job is also deleted as soon as a newer job fails. I can see in the CronJob spec a default setting failedJobsHistoryLimit: 1, which explains this, and highlights that seeing two Jobs older than 10 seconds meant that the exercise was not working.

So what I ended up with to get the right result from Exercise 4.3 Steps 5-6, compared to the given example, is:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: sleepy
spec:
  schedule: "*/2 * * * *"
  jobTemplate:
    spec:
      activeDeadlineSeconds: 10 # <== This line has moved up two levels
      template:
        spec:
          containers:
          - name: resting
            image: busybox
            command: ["/bin/sleep"]
            args: ["30"]
          restartPolicy: Never

Categories

Upcoming Training