Rollout Strategy

Rolling update configurations, maxUnavailable, and maxSurge in LeaderWorkerSet.

Rolling update is vital to online services requiring high availability and zero downtime. For LLM inference services, this is particularly important to mitigate stockout and maintain serving capacity during updates.

LeaderWorkerSet supports two primary parameters within .spec.rolloutStrategy.rollingUpdateConfiguration: maxUnavailable and maxSurge:

maxUnavailable: Indicates how many replicas (groups of pods) are allowed to be unavailable during the update, based on spec.replicas. Defaults to 1.
maxSurge: Indicates how many extra replicas can be deployed above spec.replicas during the update. Defaults to 0.

Note

maxSurge and maxUnavailable cannot both be zero at the same time.

Example Configuration

Here is a LeaderWorkerSet configured with a rolling update strategy (see a full runtime example here):

apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: leaderworkerset-sample
spec:
  rolloutStrategy:
    type: RollingUpdate
    rollingUpdateConfiguration:
      maxUnavailable: 2
      maxSurge: 2
  replicas: 4
  leaderWorkerTemplate:
    size: 4
    workerTemplate:
      spec:
        containers:
        - name: nginx
          image: nginxinc/nginx-unprivileged:1.27

Rolling Update Process

Below is a step-by-step trace of how a rolling update executes for a LeaderWorkerSet with 4 replicas where maxUnavailable=2 and maxSurge=2 (step size = maxUnavailable + maxSurge = 4).

Status indicators:

✅ Replica has been updated to the new revision
❎ Replica has not yet been updated (running old revision)
⏳ Replica is currently undergoing rolling update (not yet ready)

Stage	Partition	Replicas	R-0	R-1	R-2	R-3	R-4 (Surge)	R-5 (Surge)	Description
Stage 1	0	4	✅	✅	✅	✅			Steady state before rolling update
Stage 2	4	6	❎	❎	❎	❎	⏳	⏳	Rolling update starts; 2 surge replicas created
Stage 3	2	6	❎	❎	⏳	⏳	⏳	⏳	Partition decreases to 2; R-2 & R-3 begin update
Stage 4	2	6	❎	❎	⏳	⏳	✅	⏳	R-4 becomes ready; partition waits for R-5
Stage 5	0	6	⏳	⏳	⏳	⏳	✅	✅	R-5 becomes ready; partition drops to 0; R-0 & R-1 begin update
Stage 6	0	6	⏳	⏳	✅	✅	✅	✅	R-2 and R-3 become ready
Stage 7	0	4	⏳	⏳	✅	✅			Scaled down to 4 replicas; surge replicas reclaimed
Stage 8	0	4	⏳	✅	✅	✅			R-1 becomes ready
Stage 9	0	4	✅	✅	✅	✅			R-0 becomes ready; rolling update complete

MaxUnavailable Feature Gate

MaxUnavailable for StatefulSets graduated to Beta in Kubernetes 1.35, meaning it is enabled by default in supported Kubernetes clusters.

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.