Build Kubernetes CronJobs

Kubernetes CronJob Builder is a skill for designing and writing Kubernetes CronJob manifests, covering cron scheduling, resource management, security contexts, and failure handling for scheduled workloads. Its structural conventions: always pin apiVersion: batch/v1, name jobs in DNS-1123 subdomain format, set schedule with an explicit timezone, configure concurrencyPolicy to prevent overlapping runs, and set successfulJobsHistoryLimit/failedJobsHistoryLimit to bound retained job history. For resources and reliability it always sets container resource requests/limits, uses restartPolicy: OnFailure or Never (never Always), caps runaway jobs with activeDeadlineSeconds, and controls retries with backoffLimit.

Use it when authoring a new CronJob for a recurring batch task - backups, database maintenance, file processing, or periodic cleanup - and needing a security- and reliability-hardened baseline rather than a bare-minimum manifest. It provides concurrency-policy guidance for two different failure modes: Forbid to block overlapping runs (e.g. a nightly backup or DB cleanup job) versus Replace to let a newer run replace a stuck one (e.g. a file processor running every 15 minutes). It is not a fit for long-running services - those belong in a Deployment or StatefulSet, not a CronJob, which is scoped to bounded, schedule-triggered work.

Output is a complete CronJob YAML manifest. A baseline scheduling example:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: data-backup-job
  namespace: production
spec:
  schedule: "0 2 * * *"  # Daily at 2 AM
  timezone: "UTC"  # Always specify timezone
  concurrencyPolicy: Forbid  # Prevent overlapping jobs
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      activeDeadlineSeconds: 3600  # 1 hour timeout
      backoffLimit: 2
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: backup-container
            image: backup-tool:v1.2.0
            resources:
              requests:
                cpu: 100m
                memory: 256Mi
              limits:
                cpu: 500m
                memory: 512Mi

Security-hardened variants add a pod-level securityContext (runAsNonRoot, runAsUser, fsGroup), a container-level securityContext (allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, dropping all Linux capabilities), secrets pulled via secretKeyRef, and a dedicated serviceAccountName. Documented common patterns include a database-cleanup job (postgres image running a DELETE + VACUUM ANALYZE via psql on a nightly schedule) and a file-processor job (every 15 minutes, concurrencyPolicy: Replace, PVC and ConfigMap volume mounts).

For observability it recommends comprehensive labels and annotations for job identification, Prometheus scrape annotations (prometheus.io/scrape: "true"), init containers for setup tasks, and container scripts that log start/completion/failure timestamps with explicit non-zero exits on failure. Advanced scheduling supports the @yearly/@monthly/@weekly/@daily/@hourly shorthand, suspend: true to pause a job without deleting it, and jitter to avoid resource contention across multi-region deployments.

Platform and DevOps engineers writing or hardening Kubernetes CronJob manifests for scheduled batch work, who want built-in guardrails for concurrency, retries, timeouts, and security context rather than assembling them from scratch. It also recommends testing schedules in non-production first, monitoring job history and resource usage, applying RBAC to service accounts, and using Helm charts to manage CronJob variants across environments.