Rollout Strategy

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.

Example Configuration

Here is a LeaderWorkerSet configured with a rolling update strategy (see sample 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)

MaxUnavailable Feature Gate

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