What's the difference between parallelism and completions?

`completions` is the total number of Pods that must complete successfully for the Job to be considered done; `parallelism` is how many Pods are allowed to run at the same time while working toward that total. Setting both to 1 runs a single Pod to completion; setting completions to 5 and parallelism to 2 runs up to 2 Pods concurrently until 5 total have succeeded.

What happens when backoffLimit is reached?

Each time a Job's Pod fails, the Job controller retries by creating a new Pod, with an exponentially increasing back-off delay between attempts. Once the number of retries exceeds `backoffLimit`, the Job is marked as failed and stops creating new Pods, so this field is effectively your 'give up after N failures' setting.

OnFailure vs Never restartPolicy, which should I pick?

`OnFailure` restarts the failed container in place within the same Pod, which the Job's own backoff/retry counter still tracks; `Never` instead lets the Pod fail outright and has the Job controller create a brand-new Pod for the retry. `Never` is more common in practice because it makes each attempt's logs and Pod easy to inspect separately with `kubectl describe pod`.

What does activeDeadlineSeconds protect against?

It's a hard wall-clock timeout for the entire Job (not per-Pod): once that many seconds have elapsed since the Job started, Kubernetes terminates all running Pods and marks the Job failed, regardless of backoffLimit. Use it to guard against a Job that's retrying forever, or one whose individual Pods hang instead of failing cleanly.

Job YAML Generator

Overview

Introduction

A Job is the run-to-completion counterpart to a Deployment: instead of keeping a fixed number of replicas alive forever, it runs Pods until a certain number of them finish successfully, then stops. The fields that control that behavior, completions, parallelism, backoffLimit, aren't ones most people memorize.

This tool builds a Job manifest from a form covering exactly those fields, plus command/args and an optional overall time limit.

What Is Kubernetes Job Generator?

A form-based generator for the `batch/v1/Job` resource, the Kubernetes controller for run-to-completion (rather than always-on) workloads.

It covers completions and parallelism together (to model both single-run and batch-of-N job shapes), backoffLimit for retry behavior, an optional activeDeadlineSeconds hard timeout, and the restartPolicy that governs how failed Pods are handled.

How Kubernetes Job Generator Works

Name and image fill the container the same way as any other workload; command and args are split on whitespace into the array form the Pod spec expects for `command`/`args`.

completions, parallelism, and backoffLimit are validated as sane whole numbers and passed straight through to `spec`; activeDeadlineSeconds is only emitted at all if you set one, since its absence (the default) means no overall timeout.

When To Use Kubernetes Job Generator

Use it for one-off or batch tasks that need to run to completion and then stop: a database migration, a data import/export, a report generation script, or a batch of independent parallel work items.

If the work needs to repeat on a schedule rather than run once, use the CronJob Generator instead, a CronJob wraps this same Job shape with a schedule.

Often used alongside Kubernetes CronJob Generator.

Features

Advantages

Splits command/args into proper YAML flow-sequence arrays automatically, avoiding a common mistake of pasting a whole shell command into a single string field.
Validates completions, parallelism, and backoffLimit as sane bounded integers before generating anything.
Only emits activeDeadlineSeconds when you actually set one, keeping the output clean for the common case of no overall timeout.

Limitations

Doesn't expose `ttlSecondsAfterFinished` for automatic cleanup of completed Jobs, that field is worth adding by hand if your cluster accumulates many finished Jobs.
Command/args splitting is whitespace-based, so arguments containing spaces (e.g. a quoted string) need to be entered carefully or adjusted after generation.

Examples

A one-shot database migration Job

Input

name: db-migrate, image: myapp/migrator:2.3, command: 'migrate up', parallelism: 1, completions: 1, backoffLimit: 3, restartPolicy: Never

Output

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
spec:
  parallelism: 1
  completions: 1
  backoffLimit: 3
  template:
    metadata:
      labels:
        app: db-migrate
    spec:
      restartPolicy: Never
      containers:
        - name: db-migrate
          image: myapp/migrator:2.3
          command: [migrate, up]

A single Pod runs once; up to 3 retries are attempted if it fails before the Job is marked Failed.

Best Practices & Notes

Best Practices

Prefer restartPolicy: Never for anything where you want to inspect each failed attempt's own Pod and logs separately.
Set backoffLimit deliberately rather than leaving it at the API default (6), a lower number fails fast for jobs that are unlikely to succeed on retry without a fix.
Set activeDeadlineSeconds for any Job whose failure mode might be 'hangs forever' rather than 'fails cleanly', so a stuck Job doesn't run indefinitely.

Developer Notes

Command and args are each split into a YAML flow-sequence array (`command: [a, b, c]`) by trimming and splitting the input string on runs of whitespace, matching how Kubernetes itself expects `command`/`args` as string arrays rather than a single shell string (the Pod spec does not invoke a shell unless the image's entrypoint does). No shell quoting or escaping is attempted, so arguments containing embedded spaces should be adjusted in the output directly.

Kubernetes Job Generator Use Cases

Running a database schema migration as a one-off task before a deployment
Executing a batch data import/export or ETL script with a bounded number of parallel workers
Running a report-generation or cleanup script that should execute once and terminate

Common Mistakes

Setting parallelism higher than completions for no reason, which doesn't cause an error but means some parallel capacity goes unused near the end.
Leaving restartPolicy unset and expecting Always to work, Jobs only accept OnFailure or Never, unlike other workload types.
Not setting backoffLimit low enough for a task that's deterministic, letting it retry many times against the same underlying failure.

Tips

If this task needs to repeat on a schedule instead of running once, use the CronJob Generator, it wraps this same Job template under a schedule field.

Kubernetes Job Generator