In this module, we will learn about the controllers that keep your applications running, scale them up and down, and update them safely. These are the autopilots that make Kubernetes truly powerful.

The Controller Pattern

Every controller in Kubernetes follows the same simple but powerful pattern: a reconciliation loop.

The Controller Family

Kubernetes has different controllers for different workload types:

Let's explore each one, starting from the foundation and building up.

ReplicaSets: Your First Safety Net

Sarah never wants to be caught with a single dead Pod again. A ReplicaSet ensures she always has the right number of copies running.

What a ReplicaSet guarantees:

• A specified number of Pod replicas are running at all times
• If a Pod fails or is deleted, the ReplicaSet creates a new one
• If too many Pods exist (e.g., after scaling down), it terminates the excess
• Uses label selectors to identify which Pods it manages

ReplicaSet Manifest

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: api-rs
  labels:
    app: my-api
spec:
  replicas: 3
  selector:                   # How the RS finds its Pods
    matchLabels:
      app: my-api
  template:                   # Pod template -- creates Pods from this
    metadata:
      labels:
        app: my-api           # MUST match selector above
    spec:
      containers:
      - name: api
        image: my-api:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "128Mi"

How ReplicaSets Work

# Create the ReplicaSet
kubectl apply -f replicaset.yaml

# See 3 Pods running
kubectl get pods
# api-rs-abc12   Running
# api-rs-def34   Running
# api-rs-ghi56   Running

# Delete a Pod manually
kubectl delete pod api-rs-abc12

# ReplicaSet immediately creates a new one!
kubectl get pods
# api-rs-def34   Running
# api-rs-ghi56   Running
# api-rs-xyz99   Running  (new!)

# Scale imperatively
kubectl scale rs api-rs --replicas=5

# Or edit the YAML and apply
spec:
  replicas: 5

kubectl apply -f replicaset.yaml

# Delete RS but keep Pods
kubectl delete rs api-rs --cascade=orphan

Why Not Use ReplicaSets Directly?

Sarah has self-healing now. But what happens when she needs to update her app to version 2.0?

To update all Pods, Sarah would have to:

1. Create a new ReplicaSet with the new image
2. Scale up the new ReplicaSet
3. Scale down the old ReplicaSet
4. Manage the transition carefully to avoid downtime

That is tedious and error-prone. Fortunately, there is a controller that automates this entire process...

Knowledge Check: ReplicaSets

Let's make sure the foundation is solid

Deployments: The Safe Way to Update

Sarah is ready to upgrade her API from v1 to v2. She needs zero downtime. Enter the Deployment -- the most commonly used controller in Kubernetes.

What Deployments add on top of ReplicaSets:

• Rolling updates -- gradually replace old Pods with new ones
• Rollback -- instantly revert to a previous version
• Pause/Resume -- halt a rollout mid-way for canary testing
• Revision history -- track every version change

Deployment Manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
  labels:
    app: my-api
spec:
  replicas: 3
  revisionHistoryLimit: 10        # Keep 10 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: my-api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1            # At most 1 Pod down during update
      maxSurge: 1                  # At most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: my-api
    spec:
      containers:
      - name: api
        image: my-api:1.0
        ports:
        - containerPort: 8080
        resources:
          requests: { cpu: "250m", memory: "128Mi" }
          limits:   { cpu: "500m", memory: "256Mi" }

Notice: the structure is nearly identical to a ReplicaSet, with the addition of strategy and revisionHistoryLimit.

Rolling Update: Step by Step

Sarah changes her image from my-api:1.0 to my-api:2.0 and applies. Here's what happens behind the scenes:

# Watch the rollout
kubectl rollout status deployment/my-api

# See both ReplicaSets
kubectl get rs
# my-api-5d8c9   3   3   3   (old, scaling down)
# my-api-7f4e2   2   2   2   (new, scaling up)

Triggering a Deployment Update

A rollout is triggered when you change the Pod template (.spec.template). Changes to replicas, labels on the Deployment itself, etc. do NOT trigger a rollout.

# Change image in YAML file
# image: my-api:2.0

kubectl apply -f deployment.yaml

kubectl set image deployment/my-api \
  api=my-api:2.0

kubectl annotate deployment/my-api \
  kubernetes.io/change-cause="Update to v2.0 with new auth module"

Rollbacks: When Things Go Wrong

Sarah deployed v2.0 but error rates are spiking. She needs to go back to v1.0 immediately.

# Check rollout history
kubectl rollout history deployment/my-api
# REVISION  CHANGE-CAUSE
# 1         Initial deploy v1.0
# 2         Update to v2.0 with new auth module

# Roll back to previous version
kubectl rollout undo deployment/my-api

# Roll back to a specific revision
kubectl rollout undo deployment/my-api --to-revision=1

# Check rollout status
kubectl rollout status deployment/my-api

Deployment Strategies

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 25%
    maxSurge: 25%

strategy:
  type: Recreate

Pause & Resume: Manual Canary Testing

Sarah wants to update to v3.0 but test it with a subset of traffic first. She can pause the rollout mid-way.

# Start the rollout
kubectl set image deployment/my-api api=my-api:3.0

# Pause after some new Pods are created
kubectl rollout pause deployment/my-api

# Now both v2.0 and v3.0 Pods are running
# Test, monitor metrics, check error rates...

# Happy with v3.0? Resume the rollout
kubectl rollout resume deployment/my-api

# Not happy? Undo instead
kubectl rollout undo deployment/my-api

Essential Deployment Commands

# Create deployment (imperative, for quick generation)
kubectl create deployment my-api --image=my-api:1.0 --replicas=3

# Generate YAML without creating
kubectl create deployment my-api --image=my-api:1.0 \
  --dry-run=client -o yaml > deployment.yaml

# Scale
kubectl scale deployment my-api --replicas=5

# Autoscale (HPA)
kubectl autoscale deployment my-api --min=3 --max=10 --cpu-percent=70

# View rollout history with details
kubectl rollout history deployment/my-api --revision=2

# Restart all Pods (rolling restart)
kubectl rollout restart deployment/my-api

Knowledge Check: Deployments

Test your understanding of the most important controller

StatefulSets: For Apps That Need Identity

Sarah needs to run a 3-node PostgreSQL cluster. Each instance needs its own persistent storage and a stable hostname. Deployments can't do this -- every Pod they create is interchangeable. She needs StatefulSets.

What makes StatefulSets special:

• Stable network identity -- Pods get predictable names: web-0, web-1, web-2
• Stable persistent storage -- each Pod gets its own PVC that persists across rescheduling
• Ordered deployment & scaling -- Pods are created/deleted in order (0, 1, 2... / ...2, 1, 0)
• Ordered rolling updates -- updated in reverse order by default

StatefulSet Manifest

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres-headless    # Required: headless Service for DNS
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:             # Each Pod gets its own PVC
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

Requires: A headless Service (clusterIP: None) for stable DNS entries.

Stable Network Identity

Each StatefulSet Pod gets a DNS name that follows a predictable pattern:

# Headless Service (required)
apiVersion: v1
kind: Service
metadata:
  name: postgres-headless
spec:
  clusterIP: None                   # Makes it headless
  selector:
    matchLabels:
      app: postgres
  ports:
  - port: 5432

Persistent Storage in StatefulSets

StatefulSet vs Deployment

DaemonSets: One Pod on Every Node

Sarah's security team needs a log collector running on every single node in the cluster. Not 3 copies, not 10 -- exactly one per node, including new nodes that join later.

Common DaemonSet workloads:

DaemonSet Manifest

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
  labels:
    app: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      tolerations:                    # Run on ALL nodes, including control plane
      - key: node-role.kubernetes.io/control-plane
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluentd:v1.16
        resources:
          requests: { cpu: "100m", memory: "200Mi" }
          limits:   { cpu: "200m", memory: "400Mi" }
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

Note: No replicas field -- the number of Pods is determined by the number of matching nodes.

DaemonSet Node Targeting

You can restrict a DaemonSet to specific nodes using nodeSelector or node affinity:

spec:
  template:
    spec:
      nodeSelector:
        role: gpu-worker

updateStrategy:
  type: RollingUpdate     # or OnDelete
  rollingUpdate:
    maxUnavailable: 1     # max Pods updated at once

Jobs: Run Once and Done

Sarah needs to run a database migration that should execute once, succeed, and stop. She doesn't want it running forever like a Deployment.

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
spec:
  backoffLimit: 4             # Retry up to 4 times on failure
  activeDeadlineSeconds: 300  # Kill if not done in 5 minutes
  template:
    spec:
      restartPolicy: Never    # Must be Never or OnFailure
      containers:
      - name: migrate
        image: my-api:2.0
        command: ["python", "manage.py", "migrate"]

Job Patterns: Parallelism & Completions

Jobs can run in different patterns depending on your needs:

spec:
  completions: 1     # default
  parallelism: 1     # default

spec:
  completions: 5
  parallelism: 2

spec:
  parallelism: 3

CronJobs: Scheduled Jobs

Sarah needs a nightly database backup at 2 AM. She could set an alarm and run it manually... or use a CronJob.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-backup
spec:
  schedule: "0 2 * * *"              # 2:00 AM every day
  concurrencyPolicy: Forbid          # Don't run if previous is still running
  successfulJobsHistoryLimit: 3      # Keep last 3 successful Jobs
  failedJobsHistoryLimit: 3          # Keep last 3 failed Jobs
  startingDeadlineSeconds: 600       # If missed by 10min, skip this run
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: backup
            image: postgres:15
            command: ["pg_dump", "-h", "postgres-0.postgres-headless", "mydb"]

Cron syntax: minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-6, Sunday=0)

CronJob Concurrency Policies

What happens when a new CronJob trigger fires while the previous Job is still running?

Useful commands:

# List CronJobs and their last schedule
kubectl get cronjobs

# Manually trigger a CronJob
kubectl create job manual-backup --from=cronjob/nightly-backup

# Suspend a CronJob
kubectl patch cronjob nightly-backup -p '{"spec":{"suspend":true}}'

Knowledge Check: DaemonSets, Jobs & CronJobs

Test your knowledge of specialized controllers

Horizontal Pod Autoscaler (HPA)

It's Black Friday. Sarah's API is getting 10x normal traffic. She can't manually scale fast enough. She needs autoscaling.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-api
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

HPA in Practice

# Create HPA
kubectl autoscale deployment my-api \
  --min=3 --max=20 --cpu-percent=70

# Check HPA status
kubectl get hpa
# NAME     REFERENCE         TARGETS   MIN  MAX  REPLICAS
# api-hpa  Deployment/my-api 45%/70%   3    20   3

# Detailed view
kubectl describe hpa api-hpa

behavior:
  scaleUp:
    stabilizationWindowSeconds: 60
    policies:
    - type: Percent
      value: 100
      periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Pods
      value: 1
      periodSeconds: 60

Beyond HPA: VPA & KEDA

Knowledge Check: Strategies & Scaling

Deployment strategies and autoscaling

Choosing the Right Controller

This is the decision framework Sarah's team uses when deploying a new workload:

How Controllers Find Their Pods

Understanding the ownership chain is crucial for debugging:

selector:
  matchLabels:
    app: my-api

kubectl get pod my-api-7f4e2 -o yaml
# ownerReferences:
# - apiVersion: apps/v1
#   kind: ReplicaSet
#   name: my-api-7f4e2

Rolling Update: Tuning for Zero Downtime

Sarah's first rolling update caused brief 503 errors. Here's how she fixed it.

spec:
  minReadySeconds: 30
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1

StatefulSet Update Strategies

updateStrategy:
  type: RollingUpdate
  rollingUpdate:
    partition: 0

updateStrategy:
  type: OnDelete

Real-World Architecture Example

Here's how Sarah's production stack uses all the controllers together:

Common Mistakes & How to Avoid Them

Exam Quick Reference: Imperative Commands

# Deployments
kubectl create deployment nginx --image=nginx:1.25 --replicas=3
kubectl create deployment nginx --image=nginx --dry-run=client -o yaml > deploy.yaml
kubectl set image deployment/nginx nginx=nginx:1.26
kubectl scale deployment nginx --replicas=5
kubectl rollout status deployment/nginx
kubectl rollout history deployment/nginx
kubectl rollout undo deployment/nginx
kubectl rollout undo deployment/nginx --to-revision=1
kubectl rollout restart deployment/nginx

# Jobs
kubectl create job my-job --image=busybox -- echo "Hello"
kubectl create job my-job --from=cronjob/my-cronjob

# CronJobs
kubectl create cronjob my-cron --image=busybox \
  --schedule="0 2 * * *" -- echo "Nightly task"

# Scaling
kubectl autoscale deployment nginx --min=3 --max=10 --cpu-percent=70

# Debugging
kubectl describe deployment nginx
kubectl get rs -l app=nginx
kubectl rollout history deployment/nginx --revision=2

Sarah's Story Continues...

Sarah now has a resilient, self-healing architecture. Her Pods are managed by Deployments, her database runs in a StatefulSet, and logs are collected by a DaemonSet. But she has new questions...

Final Knowledge Check

Comprehensive review of all workload controllers