Millet Porridge

English version of https://corvo.myseu.cn

0%

Some Usage of Cron Jobs in Kubernetes

Posted on Edited on In Disqus:
When using Kubernetes, one requirement is using its scheduled tasks. For online projects, it's still necessary to test well before putting them into use. This post introduces my usage, and after hitting problems related to startDeadlineSeconds, I tried reading the source code to understand its execution strategy.

Kubernetes Cron Jobs

A cronjob is defined in the following form, excerpted from the official documentation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

My Requirements

Currently I use K8S within a PaaS platform. The requirements for scheduled tasks focus on the following aspects:

Functional requirements:

  1. Create scheduled tasks
  2. Edit scheduled tasks (pause the task while editing; editing mainly modifies the task schedule time and command; reopen the task after editing)
  3. Each time the program releases a new version, synchronously update the scheduled tasks (old tasks still run to completion)
  4. Delete scheduled tasks

Non-functional requirements:

  1. At the same moment, one scheduled task may run only one instance
  2. K8S is strictly forbidden from stopping a running scheduled task

This post will provide solutions for the requirements above. If readers’ requirements differ from mine, I suggest only using this blog as a reference — don’t copy it wholesale.

Requirement Handling

Creating and Deleting Scheduled Tasks

Fairly simple; not covered here.

Pausing and Starting Scheduled Tasks

Readers can experiment: if you use kubectl delete, a running scheduled task will be forcibly terminated — not meeting our requirement, so delete doesn’t qualify.

The official documentation provides the suspend parameter:

1
The .spec.suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false.

suspend can fairly well solve the task-pausing requirement: set suspend to true when modifying, and set it back to false after modification.

suspend also has a side effect: when you change it from true to false — i.e. reopening the scheduled task — missed tasks execute immediately (if no starting deadline is set); K8S will immediately schedule the previously missed tasks.

The starting deadline issue will be covered in my later source-reading blog; here only the suspend parameter is introduced.

Restricting to a Single Running Instance

The official documentation introduces Concurrency Policy; if you set it to Forbid, only one Job will execute at a time.

Summary

This article mainly gave a simple rundown of K8S scheduled tasks. But during use, the suspend parameter brought another problem; for that, I read the CronJob implementation code. The next blog will walk through the CronJob implementation together with the source code.

Related Posts