1. Strategy type
RollingUpdate replaces Pods gradually; the alternative, Recreate, kills all old Pods first.
type: RollingUpdateTyporithm · medium
Step 1 of 8 · intro card
Workloads
spec.strategy controls how a Deployment swaps Pods. RollingUpdate with maxUnavailable: 0 and maxSurge: 1 brings up a new Pod before retiring an old one — zero downtime.
When a Deployment's template changes, spec.strategy decides how the old Pods are replaced by new ones.
type: RollingUpdate replaces Pods incrementally; the alternative type: Recreate deletes all old Pods before creating new ones, causing a gap.
maxSurge sets how many extra Pods may run above the desired count, and maxUnavailable sets how many may be missing. maxUnavailable: 0 with maxSurge: 1 means a new Pod becomes Ready before an old one is removed — true zero-downtime rollouts.
type: RollingUpdate replaces Pods gradually.
maxSurge: extra Pods allowed above desired.
maxUnavailable: 0 keeps full capacity online.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0Connect each part of the code to the concept before you type.
RollingUpdate replaces Pods gradually; the alternative, Recreate, kills all old Pods first.
type: RollingUpdaterollingUpdate tunes how many Pods may be added or taken down during the swap.
rollingUpdate:
maxSurge: 1
maxUnavailable: 0maxSurge is how many Pods above the desired count may exist mid-rollout.
maxSurge: 1maxUnavailable: 0 keeps full capacity available throughout the rollout.
maxUnavailable: 0Read the concept map and follow the code breakdown.
Type the implementation, repair mistakes and work through every recall exercise.
Use the final check without hints; revisit weak concepts in short practice sessions.