Deployments & ReplicaSets

0 / 15 lessons — 0%

Lesson 04 / 15

A ReplicaSet's only job is to keep a fixed number of identical Pods running — if one dies, it creates a replacement. A Deployment sits on top of that and adds the thing you actually want day to day: rolling out new versions without downtime, and rolling back when a release goes wrong.


# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myregistry/web:1.4.0
          ports:
            - containerPort: 3000

Deployment → ReplicaSet → Pods. Kill a Pod and the ReplicaSet replaces it within seconds.


kubectl apply -f deployment.yaml
kubectl get deployments
kubectl get pods -l app=web
kubectl scale deployment/web --replicas=5

# ship a new version — Kubernetes replaces pods gradually, not all at once
kubectl set image deployment/web web=myregistry/web:1.5.0
kubectl rollout status deployment/web

# that release was bad — go back
kubectl rollout undo deployment/web

The magic word is "rolling." By default a Deployment update brings up new Pods before tearing down old ones, a few at a time — your app never dips to zero running Pods mid-deploy.

Try it yourselfAfter applying the Deployment, run kubectl delete pod on one of its Pods by name. Immediately run kubectl get pods again — a replacement is already spinning up. That's the ReplicaSet doing its one job.

← Lesson 03 Next: Lesson 05 →