Deployments & ReplicaSets

In one line

A Deployment describes the desired state of a stateless application — how many copies, which image — and handles creating, healing, and rolling out updates to the pods underneath it automatically.

0/5 · 0%

Think of it like this

A restaurant manager's staffing sheet that just says 'always have exactly 3 cooks on shift' — the manager doesn't care WHICH specific three people, only that the number stays at 3; if one calls in sick, a replacement is found automatically, without anyone rewriting the sheet.

Key ideas

01
A DEPLOYMENT describes a desired state for a set of identical pods: which container image to run, how many REPLICAS (copies) should exist, and how updates should be rolled out. You create and manage a Deployment directly; you almost never touch the pods it creates directly, exactly as Phase 0.3 foreshadowed.
02
Underneath a Deployment sits a REPLICASET — a simpler controller whose only job is 'ensure exactly N pods matching this template exist right now.' You rarely interact with ReplicaSets directly either; the Deployment creates and manages them FOR you, specifically so it can keep an OLD ReplicaSet around briefly during a rolling update (Phase 6 covers this directly) while the new one scales up.
03
This is reconciliation (Phase 0.1) in its most common real form: if a pod managed by a Deployment crashes, is deleted, or its node fails, the underlying ReplicaSet notices the actual count has dropped below the desired count and creates a replacement automatically — this self-healing behavior is the single biggest practical reason to use a Deployment instead of a raw pod.
04
kubectl scale deployment <name> --replicas=5 changes the desired replica count directly — the Deployment (via its ReplicaSet) creates or removes pods to match, live, with zero downtime for the pods that already exist and remain unaffected by the change.
05
A Deployment update (changing the container image, for instance) triggers a ROLLING UPDATE by default: new pods (from a new ReplicaSet) are created gradually while old ones are gradually removed, so the application stays available throughout — the exact mechanics and rollback process are covered fully in Phase 6, but knowing this happens automatically on every kubectl apply with a changed image is essential from day one.

Code & diagrams

DeploymentReplicaSetPoddiagram

You manage the Deployment; it manages the ReplicaSet; the ReplicaSet manages the actual pods.

Rendering diagram…

deployment.yamlmarkdown

A realistic, minimal Deployment — the shape you'll write constantly.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-registry/my-app:1.4.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080

deployments.shmarkdown

Create, scale, heal, and inspect — the everyday Deployment loop.

kubectl apply -f deployment.yaml

# See the Deployment, its ReplicaSet, and its pods — three layers, one command each
kubectl get deployment my-app
kubectl get replicaset -l app=my-app
kubectl get pods -l app=my-app

# Scale live
kubectl scale deployment my-app --replicas=5
kubectl get pods -l app=my-app

# Self-healing in action — kill a pod directly and watch it get replaced
kubectl delete pod <one-of-the-pod-names>
kubectl get pods -l app=my-app -w
# a NEW pod appears automatically — the ReplicaSet noticed the count dropped

# Trigger a rolling update by changing the image
kubectl set image deployment/my-app my-app=my-registry/my-app:1.5.0
kubectl rollout status deployment/my-app

Explain it without notes

Why does a Deployment create a ReplicaSet underneath it, rather than managing pods directly itself?

You delete one pod that's managed by a Deployment. What happens next, and why?

Practice

Create the example Deployment, confirm 3 pods are running, then delete one directly and watch (with kubectl get pods -w) a replacement appear automatically.

Scale the Deployment up and down using kubectl scale, confirming the pod count changes to match each time.

Trade-offs

↔
A Deployment's stateless model (any pod is interchangeable with any other, all sharing one identical template) is what makes scaling and self-healing so simple — but it's specifically wrong for workloads where each instance needs a stable, distinct identity or its own persistent storage (a database, for instance), which is exactly the gap Topic 1.3's StatefulSet exists to fill.

Done when you can

I can create a Deployment and explain the relationship between Deployment, ReplicaSet, and Pod.
I can scale a Deployment and observe self-healing after manually deleting a pod.
I know that changing a Deployment's image triggers a rolling update automatically.