About the K8s Deployment & Pod Generator
A Deployment manifest that merely runs is easy; one that upgrades without dropping traffic and restarts when it wedges takes a handful of fields that are omitted far more often than they are set. This generator produces the manifest with probes, resources, and rollout strategy in place.
The fields that matter most on day two are the probes. A readiness probe controls whether a pod receives traffic, and its absence is the single most common cause of requests being routed into a container that is still starting. A liveness probe restarts a container that has stopped making progress — and pointed at the wrong endpoint it will restart a perfectly healthy pod under load, turning a slow service into a crash loop.
Resource requests belong here too, because the scheduler places pods on requests alone. A Deployment with no requests can be scheduled onto a node with nothing left to give, and is also the first thing evicted when the node comes under pressure.
Frequently asked questions
What is the difference between a readiness and a liveness probe?
Readiness decides whether the pod is sent traffic; failing it removes the pod from Service endpoints but leaves it running. Liveness decides whether the container is restarted. Use readiness for anything temporary such as warm-up or a lost dependency, and liveness only for states the process cannot recover from. Pointing liveness at a dependency check means one slow database restarts your whole fleet.
How do I get zero-downtime rolling updates?
Four things together: a readiness probe that is honest about when the process can serve, maxUnavailable set to zero so capacity never dips, a preStop hook with a short sleep so the pod leaves endpoints before it stops accepting connections, and a terminationGracePeriodSeconds longer than the longest in-flight request. Missing the preStop hook is why connections still fail during an otherwise correct rollout.
Should I set replicas in the manifest if I use an autoscaler?
No — omit it after the initial creation. If both the manifest and a HorizontalPodAutoscaler specify a replica count, every apply resets the count to the manifest value and the autoscaler then corrects it, which produces a visible oscillation on each deploy. Let the autoscaler own the field.
What is a startupProbe for?
Slow-starting containers. Without one you must set the liveness probe's initial delay high enough for the worst-case start, which also delays detection of a genuine hang for the entire life of the pod. A startupProbe disables the liveness and readiness probes until it passes once, so you can allow minutes to boot while still checking health every few seconds afterwards.
Why did my Deployment not roll out after I changed a ConfigMap?
Because nothing in the Deployment changed. A ConfigMap mounted as a volume updates in place after a delay, but a ConfigMap consumed as environment variables is read only at process start and will not change until the pod restarts. The usual fix is to put a hash of the ConfigMap into a pod template annotation, so editing the ConfigMap changes the template and triggers a normal rollout.
Need this managed for you, not just automated?
We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.