Kubernetes Deployment Generator
Build a Deployment and see the capacity envelope your rollout settings actually produce, drawn to scale. The output is checked by our own validator as you type.
deployment.yaml
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Leaving the default rolling update strategy on a small deployment
25% of 2 replicas rounds to 1, so half the capacity can be gone during a rollout.
Instead:Set maxUnavailable to 0 with maxSurge 1 where capacity matters.
Omitting resource requests
The pod becomes BestEffort, first to be evicted and last for CPU under contention.
Instead:Set requests at minimum. That alone moves it to Burstable.
Setting replicas in the manifest while an HPA manages it
They fight: the HPA scales up and the next apply scales back down.
Instead:Remove replicas from the manifest once an HPA owns it.
What a Deployment does during a deploy
A Deployment is a controller that manages ReplicaSets, and a rollout is one ReplicaSet scaling up while another scales down. Everything that goes wrong during a deploy is one of the numbers governing how fast that happens.
spec.selector is immutable, and that is a one-way door
It is required, and once the Deployment exists it cannot be changed. Adding or renaming a label in the selector means deleting and recreating the Deployment, which means downtime unless you plan around it. This is why the selector should be one stable label, not a copy of every label on the pod.
selector:
matchLabels:
app.kubernetes.io/name: api <- pick one, keep it
# not this:
selector:
matchLabels:
app: api
version: v1.2.3 <- now every release needs a
delete and recreateA failed rollout does not roll back
progressDeadlineSeconds decides when a stalled rollout is marked Failed. That is all it does. The Deployment sits with both ReplicaSets present, the old pods still serving, and the new ones still crashing, until a person runs kubectl rollout undo. Nothing is automatic, and nothing alerts.
kubectl rollout status deploy/api
error: deployment "api" exceeded its progress deadline
kubectl rollout undo deploy/api # the manual step
# CI that runs `rollout status` and fails the build is
# what turns this into something you find out about.minReadySeconds is what catches a pod that lies
Without it, a pod counts as available the instant its readiness probe passes once. A container that starts, passes one probe and then crashes still lets the rollout move on to the next pod, so a broken build can roll all the way out. minReadySeconds makes the rollout wait and watch.
minReadySeconds: 10
# the pod has to stay Ready for 10 seconds before it
# counts. A crash at t+3 stops the rollout with most
# of the old ReplicaSet still up and serving.Replica count is not availability
Nothing stops the scheduler placing every replica on one node. Three replicas on one node is one node failure away from zero. A topology spread constraint fixes it, and the strict form leaves pods Pending forever on a single-zone cluster, so ScheduleAnyway is the safer default.
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector: {matchLabels: {...}}
# DoNotSchedule is stricter and correct in production
# across real zones. On a one-zone test cluster it
# leaves pods Pending with an unhelpful event.