# Jobs, CronJobs, and DaemonSets: The Other Workload Shapes

Everything in the previous module assumed a long-running application that should always have N
replicas up. Not every workload looks like that. Kubernetes has three other primitives for
genuinely different shapes of work — using a Deployment for any of these would be the wrong
tool, not just a less elegant one.

## Job: run to completion, exactly once (or a fixed number of times)

A Job creates one or more Pods and considers itself done when they exit successfully — it does
NOT restart a Pod that exits with success, and it DOES retry one that fails, up to a configured
limit. This is fundamentally different from a Deployment, which expects its Pods to run forever
and treats any exit as something to replace.

Use a Job for: a database migration, a batch data-processing task, a one-off cleanup script —
anything with a defined "finished" state.

```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: migrate-db
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: myapp:latest
        command: ["./migrate.sh"]
      restartPolicy: Never
  backoffLimit: 3
```

## CronJob: a Job, on a schedule

A CronJob doesn't run Pods itself — it creates a new Job on a cron schedule (`schedule:
"0 2 * * *"` for "every day at 2am"), and that Job behaves exactly as described above. Use a
CronJob for anything that should run periodically and finish: nightly backups, scheduled
reports, periodic cleanup.

A CronJob that reliably fails to complete (an image that always crashes, for example) will keep
creating new Jobs on schedule, each failing the same way — this is a real, common way to
silently exhaust cluster resources (job/pod history accumulating) if nobody's watching.

## DaemonSet: exactly one Pod per node, automatically

A DaemonSet doesn't declare a replica count at all — it ensures exactly one matching Pod runs
on every node in the cluster (or every node matching a selector), and automatically adds a Pod
when a new node joins. Use a DaemonSet for per-node infrastructure: a log-shipping agent, a
node-level monitoring exporter, a network plugin component — things that fundamentally need to
exist once per machine, not "N copies somewhere."

## The decision in one pass

| You need... | Use |
|---|---|
| Always-on, N identical copies, restarted forever | Deployment |
| Run once (or a few times) until it finishes successfully | Job |
| The above, but on a recurring schedule | CronJob |
| Exactly one copy on every node | DaemonSet |

## Instructor Notes

**Approximate timing:** 15 minutes read; 10 minutes live.

**Demo plan (if extending this PARTIAL module later):** live-create a Job with a command that
deliberately fails once then succeeds (`backoffLimit: 2`), and watch `kubectl get pods` show
the failed attempt alongside the eventual successful one — makes the retry-until-backoffLimit
behavior concrete.

**Likely misconceptions to watch for:**
- Students often assume a Job that finishes successfully gets cleaned up automatically. It
  doesn't by default — the completed Pod/Job objects remain until manually deleted or a
  `ttlSecondsAfterFinished` is configured (not covered here, worth a one-line mention if asked).
- "DaemonSet" is sometimes confused with "one Pod, cluster-wide" (singular). It's the opposite —
  one Pod PER NODE, which can be many Pods total in a multi-node cluster.

**Discussion question:** "Why doesn't a Deployment support 'run once and be done'?" (Answer: a
Deployment's whole contract is maintaining a standing replica count forever — repurposing it for
one-shot work would fight that contract rather than use a primitive designed for it.)

**Optional extension:** ask what would go wrong if a CronJob's schedule ran more often than a
single Job execution takes to complete (answer: overlapping Job runs, unless
`concurrencyPolicy` is set to `Forbid` or `Replace` — a real gotcha worth naming even without
building a full lab around it).