Deployment Rollout Strategies

Kubernetes Deployments support two update strategies: RollingUpdate and Recreate. Choosing the right strategy depends on your application's ability to handle multiple versions running simultaneously.

RollingUpdate (Default)

RollingUpdate gradually replaces old pods with new ones, maintaining availability throughout the process:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    spec:
      containers:
        - name: web
          image: web-app:2.0

Key Parameters

• maxSurge: How many pods above the desired count can exist during the update. A value of 1 means at most 5 pods during a 4-replica rollout.
• maxUnavailable: How many pods can be unavailable during the update. A value of 1 means at least 3 pods are always running.

Both accept absolute numbers or percentages:

rollingUpdate:
  maxSurge: 25%
  maxUnavailable: 25%

Recreate

Recreate terminates all existing pods before creating new ones. There is a period of complete downtime:

spec:
  strategy:
    type: Recreate

No additional parameters are needed.

When to Use Which

Use RollingUpdate when:

• Your application supports running two versions simultaneously
• Zero-downtime deploys are required
• You have stateless services behind a load balancer

Use Recreate when:

• Your application cannot run two versions at once (e.g., database schema conflicts)
• You have a single-replica workload where overlap causes resource conflicts
• Shared volumes or locks prevent concurrent access

Controlling Rollout Speed

Slow down rollouts for safer deploys by minimizing surge and unavailability:

rollingUpdate:
  maxSurge: 1
  maxUnavailable: 0

This ensures no pod goes down until a new one is fully ready, at the cost of temporarily using extra resources. Pair this with readiness probes to prevent traffic from reaching pods that are not ready yet.