Kubernetes has rapidly become the de-facto standard for the management of containerized infrastructures. Within the varied workload resources available in Kubernetes for controlling and managing pods and containers, the most common are:

  • Deployments
  • ReplicaSets
  • StatefulSets

These are used to both create systems and control desired behavior of the different parts. Even though these resources have different purposes and functionalities, they all share alike the operative of maintaining systems up in case of failure, through container status assessment, restarting, or rescheduling the relevant parts if necessary.

However, we also count with other workload resources:

  • Job
  • Cronjobs
  • Work queues

In this blog post, we are going to focus on Cronjobs: their functionality and the customization options available.

Do you want to talk to us now?

What is cron?

Crons are a common Linux/UNIX utility used to schedule jobs (generally scripts or commands) to run periodically at fixed times, dates, or intervals. They are useful for periodic and recurring tasks such as polling, sending emails, collecting statistics or database backups.

What is a job in Kubernetes?

A Job creates a Pod, which it will track to ensure it terminates successfully. If the Pod failed, the Job will continue creating Pods until the Pod(s) terminate successfully.

Within the YAML file, a specified number of successful completions is designated. The Job will track the successful terminations until the designated number of Pods is complete, after which the Job will be complete.

 

What is CronJob in Kubernetes?

A CronJob is a task that ensures that a Job is created at specific times, dates, or intervals. They offer the possibility of :

Containerizing crons:
This ensures improved reliability over the execution of crons. With crons executed serverlessly, if a relevant server falls, the CronJobs continue to be executed
Customization options:
You can heavily customize the task at hand, assuring flexibility of the inherent task. In the following section, together with an example, we will assess the manifest for a CronJob resource.

Here is a job example:

As for all other resources you will need to specify these values:

  • ApiVersion: version used by your cluster
  • Kind: CronJob
  • Metadata:
  • Name: ${desired name for CronJob}
  • Namespace: ${namespace where you will host CronJob}
  • Spec: within this necessary block, some values are necessary and some are optional:
Necessary:
  • Schedule: specifies the date, times, or intervals at which to execute the Job. (For more info on transcription to cron expression, you will find there are multiple links, such as crontab
  • JobTemplate: You create the template for the Job that the CronJob will create.
Optional:
  • StartingDeadlineSeconds: Deadline (seconds) for starting a Job after it misses its scheduled time.
    That is, given a Job fails its scheduled time and the deadline is surpassed, the Job will be terminated and a new one executed. The failed Job will be marked as a Missed Schedule.

    Fact: The CronJob controller keeps count of a CronJob’s missed schedules. When a CronJob has more than 100 missed schedules, it will no longer be scheduled.
    Default=No deadline

  • ConcurrencyPolicy: Specifies how concurrently running Jobs are treated. Only one of the following options can be selected
  • Allow: Allow concurrently running Jobs
  • Forbid: Does not allow concurrently running Jobs. That is, if a Job is scheduled, but the previous one is still running, it will be skipped.
  • Replace: Does not allow concurrently running Jobs. That is, if a Job is scheduled, but the previous one is still running, the new Job will substitute the old Job.
    Default=Allow
  • Suspend: Suspends all subsequent CronJob executions. (Will not apply to Jobs that have already begun).
  • SuccessfulJobsHistoryLimit: Stipulates how many successfully completed Jobs are kept. (Assigning a value of 0 indicates no successfully completed Jobs are kept)
    Default=3
  • FailedJobsHistoryLimit: Stipulates how many failed Jobs are kept. (Assigning a value of 0 indicates no failed Jobs are kept)Default=1

All in all, CronJobs are a good fit for periodic tasks. They ensure a Job is executed, allows higher flexibility to define the task at hand, and natively comes with inbuilt traceability.