Deployments

Deployments

A Deployment owns ReplicaSets and each ReplicaSet owns Pods. That extra level is what makes zero-downtime updates and rollbacks possible.

graph TB D[Deployment nginx] --> RS1[ReplicaSet v1 - replicas 0] D --> RS2[ReplicaSet v2 - replicas 3] RS2 --> P1[Pod] RS2 --> P2[Pod] RS2 --> P3[Pod]

Changing the Pod template creates a new ReplicaSet and scales the old one down in steps. The old ReplicaSet stays at 0 replicas - that is your rollback.

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1     # how many may be down
      maxSurge: 1           # how many extra may exist

Because maxUnavailable protects the old Pods, a broken new image does not take the application down: the new ReplicaSet fails, the old one keeps serving, and the rollout simply never completes.

Daily commands

kubectl scale deploy web --replicas=5
kubectl set image deploy/web nginx=nginx:1.28
kubectl rollout status deploy/web
kubectl rollout history deploy/web
kubectl rollout undo deploy/web
kubectl rollout restart deploy/web     # same image, new Pods - picks up config changes

Probes

Probes are what make a rollout honest.

ProbeQuestionFailure means
readinessProbecan it serve traffic?removed from Service endpoints
livenessProbeis it still alive?container restarted
startupProbehas it finished booting?the other probes wait
readinessProbe:
  httpGet: { path: /, port: 80 }
  initialDelaySeconds: 3
  periodSeconds: 5

Without a readiness probe, Kubernetes calls a Pod ready as soon as the process starts - and a rolling update will happily route traffic into an application that is still warming up.

References