Update strategy

An update strategy determines how a Kubernetes workload replaces its pods after its Pod template changes. It lets you choose between replacing pods automatically and controlling when replacements happen. The available choices depend on whether the workload is a Deployment, StatefulSet, or DaemonSet. section 15.2 section 16.3 section 17.1.4

For a Deployment, set the strategy in spec.strategy:

• RollingUpdate gradually replaces old pods with new ones. Kubernetes waits for a replacement to be ready before removing the next pod, keeping the service available during the upgrade. This is the default; you can configure how many pods are replaced at a time. section 15.2
• Recreate deletes all old pods, waits for their containers to finish, then creates the new pods. Choose it when old and new versions cannot run together and a period of unavailability is acceptable. It has no configuration options. section 15.2

A Deployment’s spec also contains replicas, selector, and template. Unlike changing a ReplicaSet’s Pod template, changing a Deployment’s Pod template starts replacing its existing pods immediately. For example, updating the template’s container image from version 0.5 to 0.6 starts a rollout; the configured strategy determines how that rollout proceeds. section 15.1.1 section 15.2

StatefulSets use spec.updateStrategy, but their choices are RollingUpdate and OnDelete. The default RollingUpdate replaces pods one at a time, starting with the highest ordinal and waiting for each replacement to be ready. OnDelete leaves existing pods alone after a template change: delete each pod yourself when you want the controller to recreate it from the new template. You may choose any deletion order, but you must judge readiness yourself before continuing. OnDelete also requires manual pod deletion during a rollback. section 16.3 section 16.3.3

DaemonSets also use spec.updateStrategy and offer RollingUpdate or OnDelete. Their default RollingUpdate replaces pods across nodes, waiting for a new pod to become ready and then for any configured minReadySeconds before continuing. Its maxSurge and maxUnavailable settings control replacement behavior; the shown defaults are 0 and 1. OnDelete instead waits for you to delete each pod. A DaemonSet’s choices therefore resemble a StatefulSet’s, while its RollingUpdate settings resemble a Deployment’s. section 17.1.4

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: demo
spec:
  minReadySeconds: 30       #1
  updateStrategy:                  #2
    type: RollingUpdate            #2
    rollingUpdate:                 #2
      maxSurge: 0                  #2
      maxUnavailable: 1            #2
  selector: #2
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
        ver: v2      #3
    spec:
      ...

See a DaemonSet manifest that sets RollingUpdate, maxSurge, maxUnavailable, and minReadySeconds together. section 17.1.4