Kubernetes CronJob Builder

How it works

A CronJob resource doesn't run your container directly — on each scheduled tick, the CronJob controller creates a new Job object from spec.jobTemplate, and that Job's controller in turn creates a Pod (or several, on retry) from its own template to actually run the container(s) to completion. That's why a valid CronJob manifest nests a full Job spec inside spec.jobTemplate.spec, which itself nests a full Pod spec inside template.spec — the containers array you're used to seeing directly under a Deployment's spec.template.spec ends up four levels deep, at spec.jobTemplate.spec.template.spec.containers, which is the part people most often get wrong by hand. This tool builds that nesting for you from the fields above and renders it live as you type.

FAQ

What does concurrencyPolicy actually control?

It decides what happens if a scheduled run is still going when the next scheduled time arrives: Allow (the default) lets the new Job start anyway so both run concurrently, Forbid skips the new run entirely and waits for the next schedule tick, and Replace cancels the still-running Job and starts the new one in its place.

Why do the successful/failed jobs history limits matter?

Kubernetes keeps the Job (and Pod) objects from completed runs around by default, and without a cap they accumulate indefinitely — successfulJobsHistoryLimit and failedJobsHistoryLimit (defaulting here to 3 and 1) tell the CronJob controller how many of each to keep before deleting the oldest, keeping kubectl get jobs readable.