Deployment Strategies

May 20, 2026

Strategy comparison

Strategy	Built-in	Downtime	Two versions	Use
RollingUpdate	Yes (default)	No	Yes briefly	Production zero-downtime
Recreate	Yes	Yes	No	Dev/test, breaking changes
Blue-Green	Manual	No	Yes full	Instant rollback
Canary	Manual	No	Yes partial	Gradual / A/B

RollingUpdate (default)

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 40%   # max Pods down during update
      maxSurge: 10%         # max extra Pods above desired count
  minReadySeconds: 60       # ready probe must pass this long before continuing

Service routes to both old and new Pods during rollout
Breaking API changes risky: keep backward compatible

Recreate

spec:
  strategy:
    type: Recreate

All old Pods terminated before new ones start: downtime

Blue-Green (manual)

Two Deployments: app-blue, app-green (different image/labels)
One Service: flip selector to cut traffic instantly
Rollback = flip selector back

kubectl patch service myapp -p '{"spec":{"selector":{"version":"green"}}}'

Canary (manual)

Two Deployments, same Service selector label (e.g. app=myapp)
Different replica counts → traffic ratio (e.g. 9 old : 1 new ≈ 10% canary)
Scale canary up gradually; delete old when satisfied

Exam tips

minReadySeconds refers to readiness probe health duration
Canary needs shared label on both Deployments for same Service
Blue-green: only one Deployment receives traffic at a time via Service selector