A worked example, rendered from real sample data. Sign in to run the tool on your own input.
strategy=rolling
replicas=6
maxSurge=25%
maxUnavailable=25%
readinessSeconds=15
terminationGracePeriodSeconds=30
name=api
namespace=production
image=ghcr.io/acme/api:1.4.2═══ What this tool did ═══
✗ No cluster was contacted. Nothing here is read from a running Kubernetes API server: there are no pod counts, no CPU numbers and no memory numbers from any real workload. This page runs entirely on the server that rendered it and makes no outbound network calls.
✓ What it does compute is arithmetic on the settings you gave: how many pods the Deployment controller will create and delete at each step, how many stay available, and what the manifest for that has to say.
═══ Settings read from your input ═══
Strategy: rolling
Desired replicas: 6
Deployment: production/api
New image: ghcr.io/acme/api:1.4.2
Readiness delay assumed per pod: 15s
Termination grace period assumed per pod: 30s
maxSurge: 25% → 2 extra pods (percentages round UP for surge)
maxUnavailable: 25% → 1 pod (percentages round DOWN for unavailable)
ℹ The two timings are the only assumptions in this plan and they come from your input, not from a measurement. Every pod count below follows from them by arithmetic.
═══ Rollout steps ═══
t+ action old new available
---- ------------------------------------ --- --- ---------
0s steady state before the rollout 6 0 6
0s create 2 new pods 6 2 6
15s 2 new pods pass the readiness probe 6 2 8
45s terminate 3 old pods 3 2 5
45s create 3 new pods 3 5 5
60s 3 new pods pass the readiness probe 3 5 8
90s terminate 3 old pods 0 5 5
90s create 1 new pod
…
Model a Kubernetes rollout: exact pod counts per step for rolling, blue-green, canary and recreate, plus the manifest and kubectl commands. Part of the DevTools Surf developer suite. Browse more tools in the Developer Utilities collection.