Mastering Kubernetes Controllers: Deployments, DaemonSets, Jobs & CronJobs Explained

In Kubernetes, a Pod is the smallest deployable unit, but a single Pod cannot guarantee continuous availability; controllers are needed to keep the desired state in sync with the actual state.

The most commonly used controllers are Deployment, DaemonSet, Job, and CronJob (StatefulSet is covered elsewhere).

Deployment

Before using Deployment, understand ReplicaSet (RS). RS replaces the older ReplicationController and adds selector support. A simple ReplicaSet can be created with the following manifest:

<code>apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-set
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx</code>

Creating a Deployment automatically creates an RS, which in turn creates the Pods. Example Deployment manifest:

<code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx</code>

After applying the manifest, you can see the Deployment, its RS, and the Pods with

kubectl get deployments

,

kubectl get rs

, and

kubectl get po

.

Horizontal Scaling / Shrinking

You can change the replica count in three ways:

Use

kubectl scale deployment nginx-deployment --replicas 4

to increase.

Edit the live Deployment with

kubectl edit deployment nginx-deployment

.

Modify the YAML file and apply it with

kubectl apply -f nginx.yaml

.

Scaling down follows the same commands with a lower replica number.

Rolling Update and Rollback

Deployments support rolling updates by default. The update strategy can be set with

strategy.type

and

strategy.rollingUpdate

fields, e.g.:

<code>strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1</code>

During a rolling update, new Pods are created before old Pods are terminated, ensuring service continuity. If an update fails, you can roll back to a previous revision with

kubectl rollout undo deployment nginx-deployment --to-revision 1

or simply

kubectl rollout undo deployment nginx-deployment

. The number of retained revisions is controlled by

spec.revisionHistoryLimit

(default 10).

DaemonSet

A DaemonSet ensures that exactly one Pod runs on each Node (including newly added Nodes). It is ideal for cluster‑wide services such as log collectors, monitoring agents, or storage daemons.

Example DaemonSet manifest for Filebeat:

<code>apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat-ds
  namespace: default
spec:
  selector:
    matchLabels:
      app: filebeat
      role: logstorage
  template:
    metadata:
      labels:
        app: filebeat
        role: logstorage
    spec:
      containers:
      - name: filebeat
        image: ikubernetes/filebeat:5.6.5-alpine
        env:
        - name: REDIS_HOST
          value: redis.default.svc.cluster.local</code>

After applying, you can verify the Pods with

kubectl get po -o wide

. DaemonSets also support update strategies:

OnDelete

(delete old Pods before creating new ones) and

RollingUpdate

(default). Newer versions allow

maxSurge

to keep a configurable percentage of Nodes available during updates.

Job / CronJob

Jobs handle one‑off or batch tasks that run to completion. A simple Job manifest:

<code>apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
  namespace: default
spec:
  template:
    metadata:
      name: job-demo
    spec:
      containers:
      - name: test-job
        image: busybox
        command: ["/bin/sh", "-c"]
        args: ["for i in $(seq 10); do echo $i; done"]
      restartPolicy: Never
  backoffLimit: 4</code>

Run the Job with

kubectl apply -f job-demo.yaml

and view output via

kubectl logs

. Job status shows completions (e.g.,

1/1

) and the controlled Pod reaches

Completed

.

Jobs can be configured with

parallelism

(max concurrent Pods) and

completions

(total Pods that must finish). Example:

<code>spec:
  parallelism: 2
  completions: 4
  template:
    ...</code>

Additional controls include

activeDeadlineSeconds

to limit total runtime and

restartPolicy

(Never, OnFailure) to define retry behavior.

CronJob

CronJob extends Job with a schedule, similar to Linux crontab. Example:

<code>apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            command: ["/bin/sh", "-c"]
            args: ["for i in $(seq 10); do echo $i; done"]
          restartPolicy: OnFailure</code>

The

concurrencyPolicy

field controls how overlapping runs are handled (Allow, Forbid, Replace). Missed runs are counted, and after a configurable threshold the CronJob stops creating new Jobs.

Summary

Deployments, DaemonSets, Jobs, and CronJobs are the core Kubernetes controllers used daily. Mastering their manifests, scaling methods, update strategies, and rollback mechanisms enables efficient, reliable management of both long‑running services and short‑lived batch tasks in cloud‑native environments.