Scheduling Workloads with CronJobs

1. From Jobs to CronJobs: The Core Concept

A Kubernetes CronJob automates the creation of Job objects on a repeating schedule. The relationship is straightforward:

• You define a Job template that specifies the task to be done (the container, command, etc.).
• You provide a schedule in the standard cron format.
• The CronJob controller takes over, creating a new Job from your template each time the schedule is met.

This hierarchical model is a fundamental pattern in Kubernetes.

Conceptually, this is the cloud-native equivalent of the classic cron utility in Linux or a scheduled pipeline in Azure DevOps. To get a quick overview, let's start with a short video.

2. Anatomy of a CronJob Manifest

A CronJob manifest has two main parts: the schedule and the job template. Let's look at an example and break it down.

Here is the manifest from the documentation. Let's save it as hello-cronjob.yaml:

# hello-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

Let's dissect the spec:

• schedule: This is the heart of the CronJob. It's a string in standard cron format that defines when the job should run.
• jobTemplate: This is the template for the Jobs that will be created. Notice that jobTemplate.spec is exactly the same as the spec of a Job object you created in the last lesson. You can define completions, parallelism, backoffLimit, and even ttlSecondsAfterFinished here, just like before.

The Cron Schedule Syntax

The schedule field follows a standard format that might be familiar from your scripting experience.

The format is five space-separated fields:
MINUTES HOURS DAY-OF-MONTH MONTH DAY-OF-WEEK

Here are some examples:

• * * * * *: Run every minute.
• 0 * * * *: Run at the start of every hour.
• 0 2 * * *: Run every day at 2:00 AM.
• 0 0 * * 0: Run every Sunday at midnight.

For a detailed reference on the syntax and some helpful shortcuts, the official documentation is the best source. There are also great online tools to help you build and verify your cron expressions.

3. Creating and Observing a CronJob

Now, let's put our hello-cronjob.yaml manifest into action and see how Kubernetes manages it.

1. Apply the manifest:

   kubectl apply -f hello-cronjob.yaml
   

2. Get the CronJob status:

   kubectl get cronjob hello
   

   You will see your CronJob, its schedule, and a LAST SCHEDULE column that will initially be <none>.

   NAME    SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
   hello   * * * * *   False     0        <none>          15s
   

3. Watch for Jobs to be created:
   Since our schedule is * * * * *, a new Job should be created every minute. Use --watch to see it happen in real-time.

   kubectl get jobs --watch
   

   After a minute, you will see a new Job appear, named after the CronJob with a unique suffix (e.g., hello-27733698). You'll see it run to completion.

4. Check the Pods and Logs:
   You can see the Pods created by each Job. They will have a status of Completed.

   # Get pods created by the Job (replace with your Job name)
   pods=$(kubectl get pods --selector=job-name=hello-27733698 -o jsonpath='{.items[*].metadata.name}')
   
   # Check the logs
   kubectl logs $pods
   

   The output will show the date and the "Hello" message, confirming the task ran.

5. Clean up:
   When you're done, delete the CronJob. This will also delete any Jobs it created.

   kubectl delete cronjob hello
   

4. Production-Ready Configurations

For real-world use as a Platform Engineer, you need to control how CronJobs behave under various conditions. These settings are all configured in the spec.

Let's watch a video that demonstrates these key configurations in a practical scenario.

To summarize the key configurations from the video and the documentation:

• concurrencyPolicy: Defines what happens if it's time to start a new job but a previous one is still running.
  • Allow (default): Lets concurrent jobs run.
  • Forbid: Skips the new run if the old one hasn't finished. Useful for tasks that shouldn't overlap.
  • Replace: Cancels the currently running job and starts the new one.
• startingDeadlineSeconds: If a job misses its schedule (e.g., the cluster was down), this field sets a deadline in seconds after the scheduled time for the job to still be started. If the deadline passes, the run is skipped.
• successfulJobsHistoryLimit & failedJobsHistoryLimit: These fields control how many completed and failed Job objects are kept. This is crucial for managing resources and preventing etcd from filling up with old objects. Defaults are 3 and 1, respectively. Setting them to 0 means no history is kept.
• suspend: Setting spec.suspend: true will temporarily stop the CronJob from creating new jobs, which is useful for maintenance windows without deleting the entire resource.
• timeZone: You can specify a time zone (e.g., "America/New_York") for your schedule. If not set, the Kubernetes controller manager's local time zone is used, which can be unpredictable. Always specify a timezone for production workloads.

Finally, it's vital to remember that CronJob executions are approximate. Network issues or controller load can cause a job to be created twice or not at all. Therefore, the tasks you run in a CronJob should be idempotent, meaning running them multiple times has the same effect as running them once.

Conclusion

You have now mastered CronJobs, a critical resource for automating recurring tasks in Kubernetes. By combining a Job template with a schedule, you can reliably manage everything from backups and maintenance to report generation.

Key Takeaways:

• A CronJob is simply a Job template that is instantiated on a repeating schedule.
• The cron schedule format (* * * * *) is highly flexible. Use tools like crontab.guru to validate it.
• For production, always configure concurrencyPolicy, history limits (successfulJobsHistoryLimit, failedJobsHistoryLimit), and timeZone.
• You can temporarily disable a CronJob by setting suspend: true.
• Ensure the underlying task is idempotent to handle the possibility of duplicate or missed runs gracefully.

Next Up:
We have now covered the primary workload types for running applications in Kubernetes: stateless (Deployments), stateful (StatefulSets, conceptual), one-off (Jobs), and scheduled (CronJobs). We'll now shift our focus to a critical area for any production system: security and access control. In the next lesson, we will explore how Kubernetes handles identity for both human users and applications, starting with User Accounts and ServiceAccounts.