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:

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

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

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

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.:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

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:

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

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:

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

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:

spec:
  parallelism: 2
  completions: 4
  template:
    ...

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:

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

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.