MeteorOps | DevOps Dictionary | Kubernetes CronJob

Kubernetes CronJob

Kubernetes CronJob is a Kubernetes API object that creates Jobs on a schedule. In practical terms, it lets you run recurring tasks inside your cluster, such as database backups, report generation, cache cleanup, certificate checks, or batch imports.

What a Kubernetes CronJob does

A CronJob automates work that needs to run at specific times or intervals. It uses cron-style scheduling, similar to Linux cron, but runs the task as a Kubernetes Job.

Common examples include:

Running a nightly database backup at 02:00
Deleting expired records every hour
Syncing data from an external API every 15 minutes
Generating billing reports on the first day of each month
Checking and rotating credentials on a fixed schedule

How it works

A CronJob does not run containers directly. Instead, the Kubernetes CronJob controller creates a Job whenever the schedule matches. That Job then creates one or more Pods to perform the actual work.

The flow looks like this:

You define a CronJob with a schedule and a Job template.
Kubernetes checks the schedule.
When the schedule matches, Kubernetes creates a Job.
The Job creates a Pod.
The Pod runs the container command and exits.
Kubernetes records the Job as successful or failed.

Basic CronJob example

This example runs a container every day at 02:00 UTC:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-cleanup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: cleanup
              image: busybox:1.36
              command:
                - /bin/sh
                - -c
                - echo "Running cleanup job"

The schedule field uses standard cron format:

# ┌───────────── minute: 0-59
# │ ┌─────────── hour: 0-23
# │ │ ┌───────── day of month: 1-31
# │ │ │ ┌─────── month: 1-12
# │ │ │ │ ┌───── day of week: 0-6, Sunday to Saturday
# │ │ │ │ │
# * * * * *

Key fields in a CronJob

schedule: Defines when the CronJob runs, using cron syntax.
jobTemplate: Defines the Job that Kubernetes creates on each scheduled run.
concurrencyPolicy: Controls what happens if a previous Job is still running when the next one is due.
suspend: Temporarily pauses future runs without deleting the CronJob.
startingDeadlineSeconds: Sets how long Kubernetes can wait to start a missed run.
successfulJobsHistoryLimit: Controls how many completed Jobs Kubernetes keeps.
failedJobsHistoryLimit: Controls how many failed Jobs Kubernetes keeps for troubleshooting.
timeZone: Sets the time zone for the schedule, if supported by your Kubernetes version.

Concurrency behavior

The concurrencyPolicy field is important for production workloads. It controls overlapping runs:

Allow: Allows multiple Jobs to run at the same time. This is the default.
Forbid: Skips a new run if the previous one is still running.
Replace: Stops the currently running Job and starts a new one.

For example, use Forbid for a database backup job if two backups running at once could overload the database or corrupt output files.

CronJob vs Job vs Deployment

CronJob: Runs a Job on a schedule.
Job: Runs a task until it completes successfully or fails.
Deployment: Keeps long-running application Pods available, such as APIs or workers.

Use a CronJob for scheduled, finite work. Use a Job for one-time batch work. Use a Deployment for services that should stay running continuously.

Common use cases

Backups: Run scheduled backups for PostgreSQL, MySQL, Redis, or application data.
Maintenance: Remove old files, expired tokens, stale sessions, or temporary objects.
Batch processing: Import data, process queues, or generate reports on a schedule.
Monitoring checks: Run periodic checks that do not need a continuously running service.
Cloud operations: Trigger scripts that interact with AWS, GCP, Azure, or internal APIs.

Operational considerations

CronJobs are simple to create, but they still need production controls:

Set resource requests and limits: Prevent scheduled tasks from starving application workloads.
Use idempotent logic: A retried Job should not duplicate payments, emails, or destructive actions.
Control history limits: Too many retained Jobs can clutter the namespace.
Monitor failures: Alert on failed Jobs, repeated retries, and missed schedules.
Handle secrets safely: Use Kubernetes Secrets or an external secrets system instead of hardcoding credentials.
Choose the right concurrency policy: Avoid overlapping runs when the task modifies shared data.

Managing CronJobs as code

Teams usually define CronJobs in YAML and manage them through GitOps, Helm, Kustomize, or Terraform. If your team manages cluster objects through infrastructure as code, you can also deploy Kubernetes resources using Terraform.

Keep CronJob definitions versioned with the application or platform code. This makes schedule changes reviewable and easier to roll back.

When a CronJob is not enough

A Kubernetes CronJob works well for simple scheduled tasks. It is usually not the best fit for complex workflow orchestration.

Consider a workflow engine such as Apache Airflow when you need:

Task dependencies and DAGs
Retries per step
Backfills over historical data
Visibility into multi-step data pipelines
Scheduling logic that changes based on upstream results

For data platforms running on Kubernetes, teams often compare CronJobs with tools like Apache Airflow on Amazon EKS when scheduled work becomes more complex.

Upgrade and version notes

CronJob behavior can depend on your Kubernetes version, especially around controller behavior and fields such as timeZone. If you run many scheduled production tasks, include CronJobs in your test plan when preparing Kubernetes upgrades.

Simple real-world example

Suppose your SaaS product stores temporary export files in an object storage bucket. You can create a CronJob that runs every hour, lists files older than 24 hours, deletes them, and exits. The task does not need a long-running service, so a CronJob is a good fit.

In production, you would also add:

A service account with only the required permissions
Resource requests and limits
A Forbid concurrency policy if overlapping cleanup runs are risky
Logs that include how many files were scanned and deleted
An alert when the Job fails repeatedly

Summary

A Kubernetes CronJob schedules recurring work inside a cluster by creating Jobs at defined times. It is useful for backups, cleanup, reports, imports, and other finite tasks that run on a schedule. For reliable production use, set clear retry behavior, resource limits, concurrency rules, logging, and alerting.

DevOps Dictionary