Jobs and CronJobs

A Job, in the batch/v1 API group, runs one or more Pods until a specified number of them complete successfully, then stops. Its Pod template must set restartPolicy to OnFailure or Never — Always, the default for an ordinary Pod, is rejected, because a Job's Pod is meant to finish, not be kept alive forever. Two fields shape how the work is spread out: .spec.completions sets how many successful Pod completions the Job needs before it is done, and .spec.parallelism caps how many of those Pods run at once. .spec.backoffLimit sets how many times a failing Pod is retried — with a fresh Pod created for each attempt, not the same Pod restarted in place — before the whole Job is marked Failed.

A CronJob wraps a Job template in a schedule, written in standard cron syntax, and creates a new Job each time that schedule fires. Because a CronJob's job is only to create Jobs on time, everything you already know about a Job's completions, parallelism and backoffLimit still applies to the Job it creates.

apiVersion: batch/v1
kind: Job
metadata:
  name: report-export
spec:
  completions: 3
  parallelism: 1
  backoffLimit: 2
  template:
    spec:
      restartPolicy: OnFailure
      containers:
        - name: export
          image: reports:1.4

The .spec.concurrencyPolicy field on a CronJob decides what happens if a scheduled run's Job is still going when the next scheduled time arrives. Allow, the default, lets both run at once. Forbid skips the new run entirely if the previous one is still active. Replace cancels the still-running Job and starts the new one in its place.

.spec.startingDeadlineSeconds bounds how late a missed run can still be started; if that many seconds pass after the scheduled time with no Job created, the run is skipped rather than started late. The CronJob controller itself only checks for due schedules roughly every ten seconds, so setting the deadline below that makes it practical for a run to be judged already-missed before the controller gets a chance to start it.