Run Jobs and CronJobs to Completion

Why this matters

Migrations, exports and cleanups run on every cluster, and parking them in Deployments hides the only signal that matters: did it finish. Jobs surface completion as API state, which means monitoring, alerting and exam questions can all read the same truth. Retry budgets plus deadlines keep a bad batch from burning the night.

Concepts

A Job completes when the success count reaches completions, running up to parallelism pods at once. backoffLimit caps pod retries before the Job fails outright; activeDeadlineSeconds caps total elapsed time. restartPolicy must be Never or OnFailure. ttlSecondsAfterFinished cleans up finished Jobs automatically so history does not accumulate forever.

CronJobs wrap the same Job template in schedule plus timezone. concurrencyPolicy picks Allow, Forbid or Replace when runs overlap. History limits bound stored Jobs; suspend: true pauses the clock without deleting anything, which is the incident-safe way to silence a schedule.

Worked example

Parallel export, four shards, at most two at once, two retries, one hour max, auto-cleanup in a day:

apiVersion: batch/v1
kind: Job
metadata:
  name: export-2026-10-12
spec:
  completions: 4
  parallelism: 2
  backoffLimit: 2
  activeDeadlineSeconds: 3600
  ttlSecondsAfterFinished: 86400
  template:
    spec:
      restartPolicy: OnFailure
      containers:
      - name: export
        image: exporter:1.0
        command: ["sh", "-c", "export-shard $JOB_COMPLETION_INDEX"]

kubectl wait --for=condition=complete job/export-2026-10-12 --timeout=600s blocks until done, and kubectl logs -l job-name=export-2026-10-12 reads all four shards at once. Completion plus logs is proof; a quiet cluster is not.

Exam notes

Completions count successful pods, not attempts: retries do not inflate the target. Parallelism above completions just idles. And indexed mode (completionMode: Indexed) hands each pod its shard number, which is how real fan-out batches address their slice without a queue.