Kubernetes Deployment Checklist

Most failed Kubernetes releases are not exotic. They are a missing probe, an unpinned tag, a Secret baked into an image, or a rollout that went green while the app stayed broken. This is a working checklist for shipping to a cluster, grouped by when each item matters. If you want the underlying concepts (the Deployment object, ReplicaSets, rolling updates), start with the Kubernetes deployment guide; this post assumes you know those and focuses on what to verify before, during, and after a deploy.

Before You Deploy#

• Readiness probe configured. Kubernetes only sends traffic once it passes, so a pod that is up but not ready is held out of the Service instead of dropping requests.
• Liveness probe configured. Restarts a pod that is alive but wedged; keep it conservative so a slow dependency does not trigger a restart loop.
• Startup probe for slow starters. Gives apps with long boot times room to initialize before liveness kicks in, avoiding premature kills.
• Resource requests set. The scheduler uses requests to place pods; without them, packing is blind and noisy neighbors starve each other.
• Resource limits set. Caps a runaway container so one pod cannot exhaust a node and take its neighbors down.
• Image tags pinned (no :latest). A floating tag makes rollouts non-reproducible and rollbacks guesswork; pin a version or a digest so every node runs the same bits.
• Secrets and config externalized. Read credentials and settings from Secrets and ConfigMaps, never baked into the image, so you can rotate them without a rebuild and keep them out of the registry.
• Rollout strategy chosen. Decide between rolling, blue-green, and canary before you ship; see deployment strategies for the tradeoffs and what each one needs.
• Replica count and PodDisruptionBudget set. Run more than one replica, and a PodDisruptionBudget keeps a minimum available during drains and node upgrades so maintenance does not cause an outage.
• HPA wired if load varies. A HorizontalPodAutoscaler scales replicas on CPU, memory, or custom metrics, which only works if resource requests are set first.
• Observability ready before cutover. Logs shipping, metrics scraping, and health endpoints exposed in advance, so the release is visible the instant it lands rather than after you scramble to add dashboards.
• Rollback plan confirmed. Know the previous good revision and that kubectl rollout undo returns to it; the old ReplicaSet is retained, but confirm it before you need it.

During Rollout#

• Watch the rollout, not just the apply. kubectl rollout status deployment/<name> confirms the new ReplicaSet reaches the desired ready count instead of stalling on failing pods.
• Confirm capacity holds. With maxSurge and maxUnavailable set sanely, the fleet stays near full capacity as pods cycle; a stalled rollout means new pods are failing readiness, which is the system protecting you.
• For canary or blue-green, verify the slice first. Check the small slice or the standby color is healthy before shifting the rest of the traffic over.

After Cutover#

• Verify from the user's side. Hit real endpoints and exercise a real flow (log in, load a page, complete a request); a clean rollout proves pods are ready, not that the feature works.
• Check error rates and latency. Compare against the pre-deploy baseline so a regression that does not crash pods still surfaces.
• Confirm config actually loaded. A bad ConfigMap or Secret does not trigger a new rollout, so the breakage often appears only as pods restart later; verify the new values are live.
• Keep the previous revision until you trust the release. Once metrics and external checks are clean, the deploy is done; until then, the old ReplicaSet is your fastest way back.

Common Mistakes#

• Treating "rollout succeeded" as "release works." Readiness probes check only what you wrote into them; the cluster cannot tell you a checkout button is broken.
• Shipping :latest. It makes two nodes silently run different code and turns rollback into archaeology.
• No PodDisruptionBudget. A routine node drain evicts every replica at once and causes an avoidable outage.
• Setting limits without requests (or neither). The scheduler and the HPA both rely on requests; without them, autoscaling and bin-packing do not work as expected.
• Adding observability after the incident. If logs and metrics are not wired before cutover, your first signal is a user complaint.

Conclusion#

A Kubernetes deploy is a sequence of small verifications, not a single command. Get the probes, resources, pinned tags, externalized config, disruption budget, and rollback path right before you ship, watch the rollout while it runs, and confirm the release from the outside once it lands.

That last step is the one the cluster cannot do for you: every signal in the rollout loop comes from inside the cluster, so a green rollout that does not actually serve traffic looks fine from kubectl. ObserveOne checks your endpoints from outside the cluster, scheduled from multiple regions, so when a deploy goes green but the service does not, you hear it from an alert instead of a user.