toolkit

K8s Rollout Visualizer

Runs in browser

Visualize deployment rollout strategies

Extra pods during update

Max pods offline at once

Rollout Progress 0%

How to Use

Choose a strategy and start a rollout.

You will see:

  • RollingUpdate: Gradual replacement (Zero Downtime)
  • Recreate: Kill all -> Create all (Downtime)
  • Surge/Unavailable: Control update pace
Pod Visualization
Old Version
New Version
v1

pod-1

Running

v1

pod-2

Running

v1

pod-3

Running

v1

pod-4

Running

4

Running

0

New Version

4

Old Version

Event Timeline

Start a rollout to see events...

Related Tools

Kubernetes

K8s Probe Generator

Simulators

Pod Eviction

K8s

Resource Calculator

Guides

K8s Pod Creation

Mastering Kubernetes Deployment Strategies

A Kubernetes Deployment controller provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the controller changes the actual state to the desired state at a controlled rate. The mechanism by which this transition occurs—how old pods die and how new pods are born—is entirely dictated by the defined rollout strategy.

Choosing the wrong strategy in production can lead to dropped requests, database lock contention, or catastrophic split-brain scenarios where conflicting versions of an application attempt to modify state simultaneously.

1. Core Strategies: Recreate vs. RollingUpdate

.spec.strategy.type: Recreate

The Recreate strategy is the nuclear option. The deployment immediately scales the old ReplicaSet to 0, mercilessly terminating every single existing pod. Only after the very last old pod has completely died does it instruct the new ReplicaSet to scale up to the desired count.

When to use this: You only use Recreate when your application strictly cannot handle multiple versions running concurrently (e.g., executing a destructive database schema migration, or utilizing ReadWriteOnce Persistent Volumes that cannot be attached to two pods simultaneously). It guarantees downtime.

.spec.strategy.type: RollingUpdate

The RollingUpdate (Kubernetes default) gradually replaces old pods with new ones. It ensures that at least a certain number of pods remain online to handle traffic, while also capping the maximum number of new pods created at once to prevent resource exhaustion on your nodes. It enables zero-downtime deployments.

2. The Mathematics of Rolling Updates

A RollingUpdate is entirely governed by two highly configurable integer/percentage values. Understanding their mathematical relationship is critical for controlling your deployment pace.

maxSurge

Definition: The maximum number of pods that can be scheduled above the desired replicas count.

Default: 25% (rounded up)

If replicas: 4 and maxSurge: 1, the Deployment will ensure that no more than 5 pods exist at any time across all ReplicaSets. This controls compute resource bounds.

maxUnavailable

Definition: The maximum number of pods that can be unavailable relative to the desired replicas count.

Default: 25% (rounded down)

If replicas: 4 and maxUnavailable: 1, the Deployment guarantees that at least 3 pods are available at all times. This controls application availability bounds.

Crucial Configuration Rules

  • maxSurge and maxUnavailable cannot both be zero. (If both were zero, Kubernetes could neither create new pods to surge, nor kill old pods to create capacity).
  • If your nodes are running at 100% capacity and you set maxUnavailable: 0, your deployment will hang forever. It will try to surge a pod, the cluster will reject the scheduling due to lack of CPU/Memory, and the rollout will freeze.
  • For rapid deployments where cluster resources are vast, use maxSurge: 100% and maxUnavailable: 0%. It will immediately double your pod count, wait for readiness, and then abruptly terminate all old pods.

3. Advanced Traffic Control: Blue/Green & Canary

Sometimes Kubernetes Deployments aren't expressive enough. If you need to test traffic on a new version before fully committing, or need the ability to instantly rollback without waiting for pods to spin up, you must decouple your Kubernetes Deployment from your Kubernetes Service routing.

Blue/Green Deployments

You run two completely separate, identical environments: Blue (active/production) and Green (idle/staging). You deploy the new code to Green. Once verified, you simply update the Service selector to point to Green. Traffic cuts over instantly. If a bug is found, you point the Service back to Blue instantly.

Trade-off: Requires 2x the hardware/cloud costs, as you must maintain two full copies of production simultaneously.

Canary Deployments

You deploy a small "Canary" ReplicaSet alongside your production system (e.g., 1 Canary pod for every 9 Production pods). 10% of real user traffic randomly hits the new code. You monitor error rates and latency on the Canary. If metrics look good, you slowly scale up the Canary and scale down the Production set.

Trade-off: Requires advanced tooling (like Istio, Linkerd, or Argo Rollouts) to precisely control traffic percentages, rather than relying on crude pod-count math.

Further Reading