Phase 04 · Operations & SecurityChapter 19 of 33

Phase 04Read time ~16 minDifficulty intermediate

Jobs & CronJobs

Warrior, until now almost everything we've deployed has been a long-running application:

In this chapter (72 sections)

Deployment
    ↓
Pod
    ↓
Application keeps running

But many real applications also need tasks that run, finish, and stop.

Examples:

Database migration
Data processing
Sending a report
Cleanup old records
Generating invoices
Running an ML batch job
Processing a queue batch
Backups
Scheduled maintenance

For these, Kubernetes provides:

Job
CronJob

1. Deployment vs Job#

This distinction is extremely important.

Deployment#

A Deployment wants Pods to keep running.

Pod starts
   ↓
Application runs
   ↓
Pod keeps running

Example:

Node.js API
Next.js
Nginx

Job#

A Job wants a task to complete successfully.

Pod starts
   ↓
Task executes
   ↓
Task finishes
   ↓
Pod completes

Example:

Database migration

So:

Deployment = keep application running

Job = run task to completion

2. Real-World Example#

Suppose your Node.js application has:

npm run migrate

You don't want:

Migration Pod
    ↓
Run forever

You want:

Migration Pod
    ↓
Run migration
    ↓
Exit successfully
    ↓
Completed

That's a Job.

3. What Is a Kubernetes Job?#

A Kubernetes Job creates one or more Pods and ensures that a specified number of them successfully complete.

Simple architecture:

Job
 │
 ▼
Pod
 │
 ▼
Container
 │
 ▼
Task
 │
 ▼
Exit 0
 │
 ▼
Completed

4. Simple Job Example#

apiVersion: batch/v1
kind: Job
 
metadata:
  name: hello-job
 
spec:
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: hello
          image: busybox:1.36
          command:
            - sh
            - -c
            - echo "Hello from Kubernetes Job"

Apply:

kubectl apply -f job.yaml

Check:

kubectl get jobs

You might see:

NAME         COMPLETIONS   DURATION   AGE
hello-job    1/1           2s         10s

Check Pods:

kubectl get pods

You may see:

hello-job-xxxxx   0/1   Completed

5. Why `restartPolicy`?#

A Job Pod must use an appropriate restart policy.

Commonly:

restartPolicy: Never

or:

restartPolicy: OnFailure

For Jobs, Always isn't appropriate because the workload is supposed to terminate after completion.

6. `Never` vs `OnFailure`#

`Never`#

If the container fails:

Container fails
    ↓
Pod fails
    ↓
Job can create another Pod

`OnFailure`#

The container can be restarted within the Pod when it fails.

Think:

Never
→ new Pod may be created
 
OnFailure
→ container can restart in same Pod

The Job controller still tracks successful completion.

7. Job Lifecycle#

A Job may go through:

Created
   ↓
Pod created
   ↓
Running
   ↓
Task executes
   ↓
Success
   ↓
Completed

If it fails:

Pod
 ↓
Task fails
 ↓
Job retries according to configuration

8. Example: Node.js Job#

Suppose you have:

my-node-api:1.0

and the Docker image contains:

{
  "scripts": {
    "migrate": "node scripts/migrate.js"
  }
}

Job:

apiVersion: batch/v1
kind: Job
 
metadata:
  name: db-migration
 
spec:
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: migration
          image: my-node-api:1.0
          command:
            - npm
            - run
            - migrate

Flow:

Job
 ↓
Node.js container
 ↓
npm run migrate
 ↓
Database migration
 ↓
Exit 0
 ↓
Job Completed

9. Job Status#

Run:

kubectl get jobs

Example:

NAME            COMPLETIONS   DURATION
db-migration    1/1           5s

Meaning:

1 successful completion
out of 1 required

10. Check Job Details#

kubectl describe job db-migration

Check logs:

kubectl logs job/db-migration

You can also inspect the Pod:

kubectl get pods

11. What If the Job Fails?#

Suppose:

Database unavailable

Your migration exits:

exit code 1

The Job isn't successful.

Job
 ↓
Pod
 ↓
Migration
 ↓
❌ Failed

Kubernetes can retry according to the Job configuration.

12. `backoffLimit`#

You can control how many failures are tolerated before the Job is considered failed.

Example:

spec:
  backoffLimit: 4

Conceptually:

Attempt 1 → Fail
Attempt 2 → Fail
Attempt 3 → Fail
Attempt 4 → Fail
...
Job eventually marked Failed

The exact retry behavior includes controller backoff, so don't interpret backoffLimit simply as a fixed number of seconds or always exactly one new Pod per failure.

13. Example#

apiVersion: batch/v1
kind: Job
 
metadata:
  name: data-processing
 
spec:
  backoffLimit: 3
 
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: processor
          image: my-data-processor:1.0
          command:
            - python
            - process.py

Meaning:

Run processing task
      ↓
If it fails
      ↓
Retry within configured Job behavior
      ↓
After failure limit
      ↓
Job = Failed

14. `completions`#

Suppose you need:

10 successful executions

You can specify:

completions: 10

Now Kubernetes wants:

10 successful completions

Conceptually:

Job
 ├── Task 1 ✅
 ├── Task 2 ✅
 ├── Task 3 ✅
 ├── ...
 └── Task 10 ✅

Then:

10/10 Completed

15. `parallelism`#

Suppose you have:

completions: 10
parallelism: 3

This means:

Need:
10 successful completions
 
Run at most approximately:
3 active Pods at a time

Conceptually:

Batch 1:
Pod 1
Pod 2
Pod 3
 
Batch 2:
Pod 4
Pod 5
Pod 6
 
Batch 3:
Pod 7
Pod 8
Pod 9
 
Batch 4:
Pod 10

This is useful for batch processing.

16. Example: Processing 10,000 Documents#

This is particularly relevant to your RAG/document workloads.

Suppose:

150,000 documents

need embedding.

Instead of:

One huge process

you could divide the workload:

150,000 documents
       ↓
10,000-document batches
       ↓
Jobs
       ↓
Multiple workers

For example:

Job
 ├── Worker 1
 ├── Worker 2
 ├── Worker 3
 └── Worker 4

Each worker processes a portion of the dataset.

17. `parallelism` vs `completions`#

Remember:

completions
→ How many successful tasks are required?
 
parallelism
→ How many can run simultaneously?

Example:

completions: 100
parallelism: 10

Means:

Need 100 successful completions
Maximum desired active parallelism = 10

18. Job with Parallel Processing#

apiVersion: batch/v1
kind: Job
 
metadata:
  name: document-processing
 
spec:
  completions: 100
  parallelism: 10
  backoffLimit: 5
 
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: worker
          image: document-worker:1.0

Architecture:

                 Job
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    Worker 1   Worker 2   Worker 3
       ...
       │
       ▼
   100 completions

19. Indexed Jobs#

For some batch workloads, you may want each Pod to receive a unique completion index.

For example:

0
1
2
3
...
99

You can use:

completionMode: Indexed

Then each worker can know:

"I am worker #37"

This can be useful for partitioning workloads.

For example:

Worker 0 → Documents 0–999
Worker 1 → Documents 1000–1999
Worker 2 → Documents 2000–2999

Your application needs to use the index correctly.

20. Job Timeout#

What if your task hangs forever?

You don't want:

Job
 ↓
Running
 ↓
Running
 ↓
Running
 ↓
Running forever

You can configure:

activeDeadlineSeconds: 600

Meaning:

The Job has a maximum active duration of about 600 seconds.

After the deadline, the Job is terminated and marked failed.

21. `ttlSecondsAfterFinished`#

Completed Jobs can remain in the cluster.

Over time:

Job 1
Job 2
Job 3
...
Job 10000

That's undesirable.

You can configure cleanup:

ttlSecondsAfterFinished: 300

Meaning Kubernetes can clean up the finished Job after the configured TTL.

Example:

Job completes
   ↓
Wait 300 seconds
   ↓
Job cleaned up

This helps avoid accumulating large numbers of historical Job objects.

22. Complete Job Example#

apiVersion: batch/v1
kind: Job
 
metadata:
  name: document-worker
 
spec:
  completions: 10
  parallelism: 3
  backoffLimit: 4
  activeDeadlineSeconds: 1800
  ttlSecondsAfterFinished: 600
 
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: worker
          image: document-worker:1.0
 
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
 
            limits:
              cpu: "1"
              memory: "1Gi"

This is much closer to a real production batch workload.

23. Now: What Is a CronJob?#

A Job runs when you create it.

But what if you want:

Every day at 2 AM

or:

Every 15 minutes

or:

Every Sunday

You need:

CronJob

24. CronJob = Scheduled Job#

Think:

CronJob
   │
   │ schedule
   ▼
Job
   │
   ▼
Pod
   │
   ▼
Task

A CronJob doesn't directly run your application container forever.

It creates Jobs according to a schedule.

25. Simple CronJob#

apiVersion: batch/v1
kind: CronJob
 
metadata:
  name: daily-report
 
spec:
  schedule: "0 2 * * *"
 
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
 
          containers:
            - name: report
              image: report-generator:1.0

Schedule:

0 2 * * *

means:

Every day at 2:00 AM

The actual timezone behavior should be explicitly configured where needed; don't assume your cluster's local timezone.

26. Cron Syntax#

Traditional cron has five fields:

┌──────── minute
│ ┌────── hour
│ │ ┌──── day of month
│ │ │ ┌── month
│ │ │ │ ┌ day of week
│ │ │ │ │
* * * * *

27. Common Cron Examples#

Every minute#

* * * * *

Every hour#

0 * * * *

Every day at 2 AM#

0 2 * * *

Every Sunday at 3 AM#

0 3 * * 0

Every 15 minutes#

*/15 * * * *

Every Monday at 9 AM#

0 9 * * 1

28. CronJob Example: Database Backup#

Imagine:

PostgreSQL

You want a backup every night.

Architecture:

CronJob
   │
   │ every day 2 AM
   ▼
Job
   │
   ▼
Backup Pod
   │
   ▼
pg_dump
   │
   ▼
Object Storage

For example:

apiVersion: batch/v1
kind: CronJob
 
metadata:
  name: postgres-backup
 
spec:
  schedule: "0 2 * * *"
 
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
 
          containers:
            - name: backup
              image: postgres:17
              command:
                - sh
                - -c
                - |
                  pg_dump "$DATABASE_URL" > /backup/db.sql

In production, you'd also need proper secret handling, durable backup storage, retention, encryption, failure monitoring, and restore testing.

29. CronJob Example: Cleanup#

Suppose your application stores temporary records.

You could run:

Every night
    ↓
Cleanup expired records

CronJob:

apiVersion: batch/v1
kind: CronJob
 
metadata:
  name: cleanup
 
spec:
  schedule: "0 1 * * *"
 
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
 
          containers:
            - name: cleanup
              image: my-node-api:1.0
              command:
                - npm
                - run
                - cleanup

30. CronJob Example: Daily AI Processing#

Suppose your AI system needs to process documents every night:

11 PM
 ↓
Fetch new documents
 ↓
Extract text
 ↓
Generate embeddings
 ↓
Store vectors

CronJob:

CronJob
   ↓
Job
   ↓
Workers
   ↓
Documents
   ↓
Embeddings
   ↓
Vector DB

This is a very realistic Kubernetes use case.

31. `concurrencyPolicy`#

What if your CronJob runs every 10 minutes but a previous Job takes 30 minutes?

You could have:

10:00 → Job A starts
10:10 → Job B starts
10:20 → Job C starts
10:30 → Job D starts

Now multiple copies overlap.

Sometimes that's desired.

Sometimes it's dangerous.

Kubernetes provides:

concurrencyPolicy: Forbid

Meaning:

Don't start a new Job while the previous one is still running.

32. Concurrency Policies#

Three important values:

Allow
Forbid
Replace

Allow#

Multiple Jobs can overlap.

Job A ─────────
Job B    ─────────
Job C       ─────────

Forbid#

Don't start another while one is active.

Job A ─────────
 
Job B
   ↓
Skipped because A is active

Replace#

A newer scheduled Job can replace the currently running one according to CronJob semantics.

This can be useful when only the latest scheduled execution matters.

33. `startingDeadlineSeconds`#

What if the scheduled execution is missed?

For example:

Scheduled: 2:00 AM
Controller couldn't schedule/run it normally

You can configure:

startingDeadlineSeconds: 300

This specifies a deadline for starting a missed Job.

34. `successfulJobsHistoryLimit`#

CronJobs can retain historical Jobs.

You can configure:

successfulJobsHistoryLimit: 3

Meaning:

Keep a limited number of successful Job histories.

Similarly:

failedJobsHistoryLimit: 3

helps control retained failed Job history.

35. Production CronJob Example#

apiVersion: batch/v1
kind: CronJob
 
metadata:
  name: daily-processing
 
spec:
  schedule: "0 2 * * *"
 
  concurrencyPolicy: Forbid
 
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
 
  jobTemplate:
    spec:
      backoffLimit: 3
      activeDeadlineSeconds: 1800
      ttlSecondsAfterFinished: 600
 
      template:
        spec:
          restartPolicy: Never
 
          containers:
            - name: processor
              image: document-processor:1.0
 
              resources:
                requests:
                  cpu: "500m"
                  memory: "512Mi"
 
                limits:
                  cpu: "1"
                  memory: "1Gi"

This is a useful production-style template.

36. CronJob Lifecycle#

Remember this:

                 CronJob
                    │
                schedule
                    │
                    ▼
                   Job
                    │
                    ▼
                   Pod
                    │
                    ▼
                Container
                    │
                    ▼
                  Task
                    │
              ┌─────┴─────┐
             Success     Failure
                │           │
                ▼           ▼
            Completed     Retry

37. Job vs CronJob vs Deployment#

This table is worth memorizing.

Feature	Deployment	Job	CronJob
Long-running	✅	❌	❌
Runs to completion	❌	✅	✅
Scheduled	❌	❌	✅
Typical use	API	Migration	Daily backup
Creates Pods	✅	✅	Via Job
Keeps replicas running	✅	No	No

Simple mental model:

Deployment
→ "Keep this application alive."
 
Job
→ "Do this task and finish."
 
CronJob
→ "Do this task on a schedule."

38. Important Production Example#

Imagine your application:

Next.js
Node.js API
PostgreSQL
Redis

You could have:

Deployment
├── Next.js
└── Node.js API
 
Stateful workload / managed DB
└── PostgreSQL
 
Deployment
└── Redis
 
Job
└── Database migration
 
CronJob
├── Daily cleanup
├── Daily report
└── Scheduled data processing

This is how different Kubernetes workload types fit together.

39. Jobs + Secrets#

Suppose your migration requires:

DATABASE_URL

Don't hardcode it.

Use a Secret:

env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: DATABASE_URL

Then:

Job
 ↓
Secret
 ↓
DATABASE_URL
 ↓
Migration

This connects Chapter 9 with Chapter 18.

40. Jobs + ConfigMaps#

Similarly:

envFrom:
  - configMapRef:
      name: app-config

Now your batch worker can consume normal configuration without embedding it in the image.

41. Jobs + Resource Limits#

Batch jobs also need resource settings:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
 
  limits:
    cpu: "1"
    memory: "1Gi"

Why?

Because Jobs are still Pods.

Therefore:

Job
 ↓
Pod
 ↓
Scheduler
 ↓
Resources matter

All the scheduling concepts from Chapter 17 still apply.

42. Jobs + Cluster Autoscaler#

Here's a useful connection.

Suppose:

100 batch Pods

are created.

Your cluster doesn't have enough capacity.

Batch Pods
   ↓
Pending
   ↓
Cluster Autoscaler
   ↓
More Nodes
   ↓
Scheduler
   ↓
Batch Pods run

So Cluster Autoscaler isn't only useful for HTTP traffic.

It can also help batch workloads when configured appropriately.

43. What Happens When a Job Pod Dies?#

Suppose:

Job
 ↓
Pod
 ↓
Processing
 ↓
Node crashes

The Job controller can create replacement work according to the Job's configuration and completion state.

This is one reason Jobs are preferable to manually creating one-off Pods for important batch tasks.

44. Important Difference: Job vs Pod#

You could create:

Pod
 ↓
Run migration
 ↓
Done

But a standalone Pod doesn't give you the same Job semantics around:

desired completions
retry behavior
parallelism
completion tracking
deadlines

So:

For batch workloads, use Jobs rather than manually managed one-off Pods.

45. Important Interview Questions#

Q1. What is a Kubernetes Job?#

A workload controller that runs Pods until a specified number of successful completions is achieved.

Q2. Job vs Deployment?#

Deployment → long-running
 
Job → finite task

Q3. What is a CronJob?#

A controller that creates Jobs according to a schedule.

Q4. What is `completions`?#

The desired number of successful completions.

Q5. What is `parallelism`?#

The desired maximum number of active Pods for the Job at a time.

Q6. What is `backoffLimit`?#

Controls how many retries/failures are allowed before the Job is considered failed.

Q7. What is `concurrencyPolicy`?#

Controls how overlapping executions of a CronJob are handled.

Q8. What is `Forbid`?#

Don't start a new Job while the previous scheduled Job is still active.

Q9. What is `ttlSecondsAfterFinished`?#

Allows finished Job resources to be automatically cleaned up after a configured delay.

Q10. Can Jobs use Secrets?#

Yes.

Just like normal Pods, Job Pods can consume ConfigMaps and Secrets.

🧠 Chapter 18 Cheat Sheet#

Deployment
    ↓
Long-running application

Job
    ↓
One-time/batch task
    ↓
Completion

CronJob
    ↓
Schedule
    ↓
Job
    ↓
Pod
    ↓
Task

Job keywords#

completions
parallelism
backoffLimit
activeDeadlineSeconds
ttlSecondsAfterFinished
completionMode

CronJob keywords#

schedule
concurrencyPolicy
startingDeadlineSeconds
successfulJobsHistoryLimit
failedJobsHistoryLimit

🎯 Final Mental Model#

Imagine you're running your NextGen Blog / AI platform:

                    Kubernetes Cluster
                           │
          ┌────────────────┼─────────────────┐
          │                │                 │
          ▼                ▼                 ▼
     Deployment          Job             CronJob
          │                │                 │
          ▼                ▼              schedule
      Node.js API      DB Migration          │
          │                │                 ▼
          ▼                ▼                Job
       Service         Completed             │
          │                                  ▼
          ▼                                Pod
       Users                                 │
                                             ▼
                                         Cleanup

And the larger architecture is now:

                         INTERNET
                            │
                            ▼
                         Ingress
                            │
                            ▼
                         Service
                            │
                  ┌─────────┴─────────┐
                  ▼                   ▼
              Deployment             HPA
                  │                   │
                Pods            More/Fewer Pods
                  │
                  ▼
              Scheduler
                  │
                  ▼
               Nodes
                  │
                  ▲
                  │
        Cluster Autoscaler
 
Separate workloads:
       │
       ├── Job → one-time task
       │
       └── CronJob → scheduled task

The 3 words to remember:#

Deployment = Run

Job = Finish

CronJob = Schedule

Next → Chapter 19: Kubernetes Security 🔐#

We'll now enter the Security phase, covering:

Authentication
Authorization
RBAC
ServiceAccounts
Secrets security
Roles
RoleBindings
ClusterRoles
Least privilege
SecurityContext
Pod security

And we'll build a realistic example of securing a Node.js API + PostgreSQL + Redis Kubernetes application.

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 17 — Kubernetes Scheduling Next ChapterChapter 19 — Kubernetes Security 🔐

Prev Next

Deployment
    ↓
Pod
    ↓
Application keeps running

But many real applications also need tasks that run, finish, and stop.

Examples:

Database migration
Data processing
Sending a report
Cleanup old records
Generating invoices
Running an ML batch job
Processing a queue batch
Backups
Scheduled maintenance

For these, Kubernetes provides:

Job
CronJob

1. Deployment vs Job#

This distinction is extremely important.

Deployment#

A Deployment wants Pods to keep running.

Pod starts
   ↓
Application runs
   ↓
Pod keeps running

Example:

Node.js API
Next.js
Nginx

Job#

A Job wants a task to complete successfully.

Pod starts
   ↓
Task executes
   ↓
Task finishes
   ↓
Pod completes

Example:

Database migration

So:

Deployment = keep application running

Job = run task to completion

2. Real-World Example#

Suppose your Node.js application has:

npm run migrate

You don't want:

Migration Pod
    ↓
Run forever

You want:

Migration Pod
    ↓
Run migration
    ↓
Exit successfully
    ↓
Completed

That's a Job.

3. What Is a Kubernetes Job?#

A Kubernetes Job creates one or more Pods and ensures that a specified number of them successfully complete.

Simple architecture:

Job
 │
 ▼
Pod
 │
 ▼
Container
 │
 ▼
Task
 │
 ▼
Exit 0
 │
 ▼
Completed

4. Simple Job Example#

apiVersion: batch/v1
kind: Job
 
metadata:
  name: hello-job
 
spec:
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: hello
          image: busybox:1.36
          command:
            - sh
            - -c
            - echo "Hello from Kubernetes Job"

Apply:

kubectl apply -f job.yaml

Check:

kubectl get jobs

You might see:

NAME         COMPLETIONS   DURATION   AGE
hello-job    1/1           2s         10s

Check Pods:

kubectl get pods

You may see:

hello-job-xxxxx   0/1   Completed

5. Why `restartPolicy`?#

A Job Pod must use an appropriate restart policy.

Commonly:

restartPolicy: Never

or:

restartPolicy: OnFailure

For Jobs, Always isn't appropriate because the workload is supposed to terminate after completion.

6. `Never` vs `OnFailure`#

`Never`#

If the container fails:

Container fails
    ↓
Pod fails
    ↓
Job can create another Pod

`OnFailure`#

The container can be restarted within the Pod when it fails.

Think:

Never
→ new Pod may be created
 
OnFailure
→ container can restart in same Pod

The Job controller still tracks successful completion.

7. Job Lifecycle#

A Job may go through:

Created
   ↓
Pod created
   ↓
Running
   ↓
Task executes
   ↓
Success
   ↓
Completed

If it fails:

Pod
 ↓
Task fails
 ↓
Job retries according to configuration

8. Example: Node.js Job#

Suppose you have:

my-node-api:1.0

and the Docker image contains:

{
  "scripts": {
    "migrate": "node scripts/migrate.js"
  }
}

Job:

apiVersion: batch/v1
kind: Job
 
metadata:
  name: db-migration
 
spec:
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: migration
          image: my-node-api:1.0
          command:
            - npm
            - run
            - migrate

Flow:

Job
 ↓
Node.js container
 ↓
npm run migrate
 ↓
Database migration
 ↓
Exit 0
 ↓
Job Completed

9. Job Status#

Run:

kubectl get jobs

Example:

NAME            COMPLETIONS   DURATION
db-migration    1/1           5s

Meaning:

1 successful completion
out of 1 required

10. Check Job Details#

kubectl describe job db-migration

Check logs:

kubectl logs job/db-migration

You can also inspect the Pod:

kubectl get pods

11. What If the Job Fails?#

Suppose:

Database unavailable

Your migration exits:

exit code 1

The Job isn't successful.

Job
 ↓
Pod
 ↓
Migration
 ↓
❌ Failed

Kubernetes can retry according to the Job configuration.

12. `backoffLimit`#

You can control how many failures are tolerated before the Job is considered failed.

Example:

spec:
  backoffLimit: 4

Conceptually:

Attempt 1 → Fail
Attempt 2 → Fail
Attempt 3 → Fail
Attempt 4 → Fail
...
Job eventually marked Failed

The exact retry behavior includes controller backoff, so don't interpret backoffLimit simply as a fixed number of seconds or always exactly one new Pod per failure.

13. Example#

apiVersion: batch/v1
kind: Job
 
metadata:
  name: data-processing
 
spec:
  backoffLimit: 3
 
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: processor
          image: my-data-processor:1.0
          command:
            - python
            - process.py

Meaning:

Run processing task
      ↓
If it fails
      ↓
Retry within configured Job behavior
      ↓
After failure limit
      ↓
Job = Failed

14. `completions`#

Suppose you need:

10 successful executions

You can specify:

completions: 10

Now Kubernetes wants:

10 successful completions

Conceptually:

Job
 ├── Task 1 ✅
 ├── Task 2 ✅
 ├── Task 3 ✅
 ├── ...
 └── Task 10 ✅

Then:

10/10 Completed

15. `parallelism`#

Suppose you have:

completions: 10
parallelism: 3

This means:

Need:
10 successful completions
 
Run at most approximately:
3 active Pods at a time

Conceptually:

Batch 1:
Pod 1
Pod 2
Pod 3
 
Batch 2:
Pod 4
Pod 5
Pod 6
 
Batch 3:
Pod 7
Pod 8
Pod 9
 
Batch 4:
Pod 10

This is useful for batch processing.

16. Example: Processing 10,000 Documents#

This is particularly relevant to your RAG/document workloads.

Suppose:

150,000 documents

need embedding.

Instead of:

One huge process

you could divide the workload:

150,000 documents
       ↓
10,000-document batches
       ↓
Jobs
       ↓
Multiple workers

For example:

Job
 ├── Worker 1
 ├── Worker 2
 ├── Worker 3
 └── Worker 4

Each worker processes a portion of the dataset.

17. `parallelism` vs `completions`#

Remember:

completions
→ How many successful tasks are required?
 
parallelism
→ How many can run simultaneously?

Example:

completions: 100
parallelism: 10

Means:

Need 100 successful completions
Maximum desired active parallelism = 10

18. Job with Parallel Processing#

apiVersion: batch/v1
kind: Job
 
metadata:
  name: document-processing
 
spec:
  completions: 100
  parallelism: 10
  backoffLimit: 5
 
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: worker
          image: document-worker:1.0

Architecture:

                 Job
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    Worker 1   Worker 2   Worker 3
       ...
       │
       ▼
   100 completions

19. Indexed Jobs#

For some batch workloads, you may want each Pod to receive a unique completion index.

For example:

0
1
2
3
...
99

You can use:

completionMode: Indexed

Then each worker can know:

"I am worker #37"

This can be useful for partitioning workloads.

For example:

Worker 0 → Documents 0–999
Worker 1 → Documents 1000–1999
Worker 2 → Documents 2000–2999

Your application needs to use the index correctly.

20. Job Timeout#

What if your task hangs forever?

You don't want:

Job
 ↓
Running
 ↓
Running
 ↓
Running
 ↓
Running forever

You can configure:

activeDeadlineSeconds: 600

Meaning:

The Job has a maximum active duration of about 600 seconds.

After the deadline, the Job is terminated and marked failed.

21. `ttlSecondsAfterFinished`#

Completed Jobs can remain in the cluster.

Over time:

Job 1
Job 2
Job 3
...
Job 10000

That's undesirable.

You can configure cleanup:

ttlSecondsAfterFinished: 300

Meaning Kubernetes can clean up the finished Job after the configured TTL.

Example:

Job completes
   ↓
Wait 300 seconds
   ↓
Job cleaned up

This helps avoid accumulating large numbers of historical Job objects.

22. Complete Job Example#

apiVersion: batch/v1
kind: Job
 
metadata:
  name: document-worker
 
spec:
  completions: 10
  parallelism: 3
  backoffLimit: 4
  activeDeadlineSeconds: 1800
  ttlSecondsAfterFinished: 600
 
  template:
    spec:
      restartPolicy: Never
 
      containers:
        - name: worker
          image: document-worker:1.0
 
          resources:
            requests:
              cpu: "500m"
              memory: "512Mi"
 
            limits:
              cpu: "1"
              memory: "1Gi"

This is much closer to a real production batch workload.

23. Now: What Is a CronJob?#

A Job runs when you create it.

But what if you want:

Every day at 2 AM

or:

Every 15 minutes

or:

Every Sunday

You need:

CronJob

24. CronJob = Scheduled Job#

Think:

CronJob
   │
   │ schedule
   ▼
Job
   │
   ▼
Pod
   │
   ▼
Task

A CronJob doesn't directly run your application container forever.

It creates Jobs according to a schedule.

25. Simple CronJob#

apiVersion: batch/v1
kind: CronJob
 
metadata:
  name: daily-report
 
spec:
  schedule: "0 2 * * *"
 
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
 
          containers:
            - name: report
              image: report-generator:1.0

Schedule:

0 2 * * *

means:

Every day at 2:00 AM

The actual timezone behavior should be explicitly configured where needed; don't assume your cluster's local timezone.

26. Cron Syntax#

Traditional cron has five fields:

┌──────── minute
│ ┌────── hour
│ │ ┌──── day of month
│ │ │ ┌── month
│ │ │ │ ┌ day of week
│ │ │ │ │
* * * * *

27. Common Cron Examples#

Every minute#

* * * * *

Every hour#

0 * * * *

Every day at 2 AM#

0 2 * * *

Every Sunday at 3 AM#

0 3 * * 0

Every 15 minutes#

*/15 * * * *

Every Monday at 9 AM#

0 9 * * 1

28. CronJob Example: Database Backup#

Imagine:

PostgreSQL

You want a backup every night.

Architecture:

CronJob
   │
   │ every day 2 AM
   ▼
Job
   │
   ▼
Backup Pod
   │
   ▼
pg_dump
   │
   ▼
Object Storage

For example:

apiVersion: batch/v1
kind: CronJob
 
metadata:
  name: postgres-backup
 
spec:
  schedule: "0 2 * * *"
 
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
 
          containers:
            - name: backup
              image: postgres:17
              command:
                - sh
                - -c
                - |
                  pg_dump "$DATABASE_URL" > /backup/db.sql

In production, you'd also need proper secret handling, durable backup storage, retention, encryption, failure monitoring, and restore testing.

29. CronJob Example: Cleanup#

Suppose your application stores temporary records.

You could run:

Every night
    ↓
Cleanup expired records

CronJob:

apiVersion: batch/v1
kind: CronJob
 
metadata:
  name: cleanup
 
spec:
  schedule: "0 1 * * *"
 
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
 
          containers:
            - name: cleanup
              image: my-node-api:1.0
              command:
                - npm
                - run
                - cleanup

30. CronJob Example: Daily AI Processing#

Suppose your AI system needs to process documents every night:

11 PM
 ↓
Fetch new documents
 ↓
Extract text
 ↓
Generate embeddings
 ↓
Store vectors

CronJob:

CronJob
   ↓
Job
   ↓
Workers
   ↓
Documents
   ↓
Embeddings
   ↓
Vector DB

This is a very realistic Kubernetes use case.

31. `concurrencyPolicy`#

What if your CronJob runs every 10 minutes but a previous Job takes 30 minutes?

You could have:

10:00 → Job A starts
10:10 → Job B starts
10:20 → Job C starts
10:30 → Job D starts

Now multiple copies overlap.

Sometimes that's desired.

Sometimes it's dangerous.

Kubernetes provides:

concurrencyPolicy: Forbid

Meaning:

Don't start a new Job while the previous one is still running.

32. Concurrency Policies#

Three important values:

Allow
Forbid
Replace

Allow#

Multiple Jobs can overlap.

Job A ─────────
Job B    ─────────
Job C       ─────────

Forbid#

Don't start another while one is active.

Job A ─────────
 
Job B
   ↓
Skipped because A is active

Replace#

A newer scheduled Job can replace the currently running one according to CronJob semantics.

This can be useful when only the latest scheduled execution matters.

33. `startingDeadlineSeconds`#

What if the scheduled execution is missed?

For example:

Scheduled: 2:00 AM
Controller couldn't schedule/run it normally

You can configure:

startingDeadlineSeconds: 300

This specifies a deadline for starting a missed Job.

34. `successfulJobsHistoryLimit`#

CronJobs can retain historical Jobs.

You can configure:

successfulJobsHistoryLimit: 3

Meaning:

Keep a limited number of successful Job histories.

Similarly:

failedJobsHistoryLimit: 3

helps control retained failed Job history.

35. Production CronJob Example#

apiVersion: batch/v1
kind: CronJob
 
metadata:
  name: daily-processing
 
spec:
  schedule: "0 2 * * *"
 
  concurrencyPolicy: Forbid
 
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
 
  jobTemplate:
    spec:
      backoffLimit: 3
      activeDeadlineSeconds: 1800
      ttlSecondsAfterFinished: 600
 
      template:
        spec:
          restartPolicy: Never
 
          containers:
            - name: processor
              image: document-processor:1.0
 
              resources:
                requests:
                  cpu: "500m"
                  memory: "512Mi"
 
                limits:
                  cpu: "1"
                  memory: "1Gi"

This is a useful production-style template.

36. CronJob Lifecycle#

Remember this:

                 CronJob
                    │
                schedule
                    │
                    ▼
                   Job
                    │
                    ▼
                   Pod
                    │
                    ▼
                Container
                    │
                    ▼
                  Task
                    │
              ┌─────┴─────┐
             Success     Failure
                │           │
                ▼           ▼
            Completed     Retry

37. Job vs CronJob vs Deployment#

This table is worth memorizing.

Feature	Deployment	Job	CronJob
Long-running	✅	❌	❌
Runs to completion	❌	✅	✅
Scheduled	❌	❌	✅
Typical use	API	Migration	Daily backup
Creates Pods	✅	✅	Via Job
Keeps replicas running	✅	No	No

Simple mental model:

Deployment
→ "Keep this application alive."
 
Job
→ "Do this task and finish."
 
CronJob
→ "Do this task on a schedule."

38. Important Production Example#

Imagine your application:

Next.js
Node.js API
PostgreSQL
Redis

You could have:

Deployment
├── Next.js
└── Node.js API
 
Stateful workload / managed DB
└── PostgreSQL
 
Deployment
└── Redis
 
Job
└── Database migration
 
CronJob
├── Daily cleanup
├── Daily report
└── Scheduled data processing

This is how different Kubernetes workload types fit together.

39. Jobs + Secrets#

Suppose your migration requires:

DATABASE_URL

Don't hardcode it.

Use a Secret:

env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: DATABASE_URL

Then:

Job
 ↓
Secret
 ↓
DATABASE_URL
 ↓
Migration

This connects Chapter 9 with Chapter 18.

40. Jobs + ConfigMaps#

Similarly:

envFrom:
  - configMapRef:
      name: app-config

Now your batch worker can consume normal configuration without embedding it in the image.

41. Jobs + Resource Limits#

Batch jobs also need resource settings:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
 
  limits:
    cpu: "1"
    memory: "1Gi"

Why?

Because Jobs are still Pods.

Therefore:

Job
 ↓
Pod
 ↓
Scheduler
 ↓
Resources matter

All the scheduling concepts from Chapter 17 still apply.

42. Jobs + Cluster Autoscaler#

Here's a useful connection.

Suppose:

100 batch Pods

are created.

Your cluster doesn't have enough capacity.

Batch Pods
   ↓
Pending
   ↓
Cluster Autoscaler
   ↓
More Nodes
   ↓
Scheduler
   ↓
Batch Pods run

So Cluster Autoscaler isn't only useful for HTTP traffic.

It can also help batch workloads when configured appropriately.

43. What Happens When a Job Pod Dies?#

Suppose:

Job
 ↓
Pod
 ↓
Processing
 ↓
Node crashes

The Job controller can create replacement work according to the Job's configuration and completion state.

This is one reason Jobs are preferable to manually creating one-off Pods for important batch tasks.

44. Important Difference: Job vs Pod#

You could create:

Pod
 ↓
Run migration
 ↓
Done

But a standalone Pod doesn't give you the same Job semantics around:

desired completions
retry behavior
parallelism
completion tracking
deadlines

So:

For batch workloads, use Jobs rather than manually managed one-off Pods.

45. Important Interview Questions#

Q1. What is a Kubernetes Job?#

A workload controller that runs Pods until a specified number of successful completions is achieved.

Q2. Job vs Deployment?#

Deployment → long-running
 
Job → finite task

Q3. What is a CronJob?#

A controller that creates Jobs according to a schedule.

Q4. What is `completions`?#

The desired number of successful completions.

Q5. What is `parallelism`?#

The desired maximum number of active Pods for the Job at a time.

Q6. What is `backoffLimit`?#

Controls how many retries/failures are allowed before the Job is considered failed.

Q7. What is `concurrencyPolicy`?#

Controls how overlapping executions of a CronJob are handled.

Q8. What is `Forbid`?#

Don't start a new Job while the previous scheduled Job is still active.

Q9. What is `ttlSecondsAfterFinished`?#

Allows finished Job resources to be automatically cleaned up after a configured delay.

Q10. Can Jobs use Secrets?#

Yes.

Just like normal Pods, Job Pods can consume ConfigMaps and Secrets.

🧠 Chapter 18 Cheat Sheet#

Deployment
    ↓
Long-running application

Job
    ↓
One-time/batch task
    ↓
Completion

CronJob
    ↓
Schedule
    ↓
Job
    ↓
Pod
    ↓
Task

Job keywords#

completions
parallelism
backoffLimit
activeDeadlineSeconds
ttlSecondsAfterFinished
completionMode

CronJob keywords#

schedule
concurrencyPolicy
startingDeadlineSeconds
successfulJobsHistoryLimit
failedJobsHistoryLimit

🎯 Final Mental Model#

Imagine you're running your NextGen Blog / AI platform:

                    Kubernetes Cluster
                           │
          ┌────────────────┼─────────────────┐
          │                │                 │
          ▼                ▼                 ▼
     Deployment          Job             CronJob
          │                │                 │
          ▼                ▼              schedule
      Node.js API      DB Migration          │
          │                │                 ▼
          ▼                ▼                Job
       Service         Completed             │
          │                                  ▼
          ▼                                Pod
       Users                                 │
                                             ▼
                                         Cleanup

And the larger architecture is now:

                         INTERNET
                            │
                            ▼
                         Ingress
                            │
                            ▼
                         Service
                            │
                  ┌─────────┴─────────┐
                  ▼                   ▼
              Deployment             HPA
                  │                   │
                Pods            More/Fewer Pods
                  │
                  ▼
              Scheduler
                  │
                  ▼
               Nodes
                  │
                  ▲
                  │
        Cluster Autoscaler
 
Separate workloads:
       │
       ├── Job → one-time task
       │
       └── CronJob → scheduled task

The 3 words to remember:#

Deployment = Run

Job = Finish

CronJob = Schedule

Next → Chapter 19: Kubernetes Security 🔐#

We'll now enter the Security phase, covering:

Authentication
Authorization
RBAC
ServiceAccounts
Secrets security
Roles
RoleBindings
ClusterRoles
Least privilege
SecurityContext
Pod security

And we'll build a realistic example of securing a Node.js API + PostgreSQL + Redis Kubernetes application.

1. Deployment vs Job#

Deployment#

Job#

2. Real-World Example#

3. What Is a Kubernetes Job?#

4. Simple Job Example#

5. Why restartPolicy?#

6. Never vs OnFailure#

Never#

OnFailure#

7. Job Lifecycle#

8. Example: Node.js Job#

9. Job Status#

10. Check Job Details#

11. What If the Job Fails?#

12. backoffLimit#

13. Example#

14. completions#

15. parallelism#

16. Example: Processing 10,000 Documents#

17. parallelism vs completions#

18. Job with Parallel Processing#

19. Indexed Jobs#

20. Job Timeout#

21. ttlSecondsAfterFinished#

22. Complete Job Example#

23. Now: What Is a CronJob?#

24. CronJob = Scheduled Job#

25. Simple CronJob#

26. Cron Syntax#

27. Common Cron Examples#

Every minute#

Every hour#

Every day at 2 AM#

Every Sunday at 3 AM#

Every 15 minutes#

Every Monday at 9 AM#

28. CronJob Example: Database Backup#

29. CronJob Example: Cleanup#

30. CronJob Example: Daily AI Processing#

31. concurrencyPolicy#

32. Concurrency Policies#

Allow#

Forbid#

Replace#

33. startingDeadlineSeconds#

34. successfulJobsHistoryLimit#

35. Production CronJob Example#

36. CronJob Lifecycle#

37. Job vs CronJob vs Deployment#

38. Important Production Example#

39. Jobs + Secrets#

40. Jobs + ConfigMaps#

41. Jobs + Resource Limits#

42. Jobs + Cluster Autoscaler#

43. What Happens When a Job Pod Dies?#

44. Important Difference: Job vs Pod#

45. Important Interview Questions#

Q1. What is a Kubernetes Job?#

Q2. Job vs Deployment?#

Q3. What is a CronJob?#

Q4. What is completions?#

Q5. What is parallelism?#

Q6. What is backoffLimit?#

Q7. What is concurrencyPolicy?#

Q8. What is Forbid?#

Q9. What is ttlSecondsAfterFinished?#

Q10. Can Jobs use Secrets?#

🧠 Chapter 18 Cheat Sheet#

Job keywords#

CronJob keywords#

🎯 Final Mental Model#

The 3 words to remember:#

Next → Chapter 19: Kubernetes Security 🔐#

Finished this chapter?

1. Deployment vs Job#

Deployment#

Job#

2. Real-World Example#

3. What Is a Kubernetes Job?#

5. Why `restartPolicy`?#

6. `Never` vs `OnFailure`#

`Never`#

`OnFailure`#

12. `backoffLimit`#

14. `completions`#

15. `parallelism`#

17. `parallelism` vs `completions`#

21. `ttlSecondsAfterFinished`#

31. `concurrencyPolicy`#

33. `startingDeadlineSeconds`#

34. `successfulJobsHistoryLimit`#

Q4. What is `completions`?#

Q5. What is `parallelism`?#

Q6. What is `backoffLimit`?#

Q7. What is `concurrencyPolicy`?#

Q8. What is `Forbid`?#

Q9. What is `ttlSecondsAfterFinished`?#

5. Why `restartPolicy`?#

6. `Never` vs `OnFailure`#

`Never`#

`OnFailure`#

12. `backoffLimit`#

14. `completions`#

15. `parallelism`#

17. `parallelism` vs `completions`#

21. `ttlSecondsAfterFinished`#

31. `concurrencyPolicy`#

33. `startingDeadlineSeconds`#

34. `successfulJobsHistoryLimit`#

Q4. What is `completions`?#

Q5. What is `parallelism`?#

Q6. What is `backoffLimit`?#

Q7. What is `concurrencyPolicy`?#

Q8. What is `Forbid`?#

Q9. What is `ttlSecondsAfterFinished`?#