How fast should a rollout go, and may old and new run side by side? The strategy decides.
Two strategies
text
RollingUpdate (default) Recreate
old: ■ ■ ■ old: ■ ■ ■
■ ■ ■ □ a new Pod is added □ □ □ every old Pod stopped
■ ■ □ □ an old Pod is removed □ □ □ then new Pods started
■ □ □ □
□ □ □ never dark dark between the two| Strategy | Behaviour | Use when |
|---|---|---|
RollingUpdate | Replace a few Pods at a time; old and new serve together for a while | Almost always |
Recreate | Stop every old Pod, then start the new ones | Two versions must never overlap, such as a single database writer |
The two knobs
RollingUpdate has two settings, as numbers or percentages of replicas:
| Field | Meaning | Default |
|---|---|---|
maxSurge | Extra Pods allowed above replicas during the rollout | 25% |
maxUnavailable | Pods allowed to be missing below replicas | 25% |
maxUnavailable: 0 means a new Pod must be ready before an old one goes. maxSurge: 1 lets exactly one extra Pod exist while that happens. Together they give a rollout with no dip in capacity, one Pod at a time.
In the manifest
yaml
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
template:
...The strategy sits next to replicas, outside the template. For Recreate the block is just strategy: {type: Recreate}.