Kubernetes Production Checklist

Kubernetes will happily run a workload that is not ready for production. A Deployment with one replica, no requests, no readiness probe and a container running as root applies cleanly and serves traffic, right up to the first node drain, the first memory spike or the first leaked token. Nothing in the API stops you; the gaps only show up under load, during an upgrade or in an incident. This checklist is the last pass before go-live, written as checks you can run against the real cluster instead of principles to agree with.

It is built from the Kubernetes project's own documentation: the security checklist, the Pod Security Standards, the disruptions and PodDisruptionBudget guide, the version skew policy, the release support schedule and the etcd operations guide. Everything was checked against Kubernetes 1.37, the newest minor release as of October 2026, and holds for 1.35 and 1.36 as well. Where a managed service (EKS, GKE, AKS and others) handles part of the control plane for you, the check says what to confirm with your provider instead.

This is not a tutorial on how to write manifests. If you want the reasoning behind requests, probes and network policies, read a Kubernetes best practices guide first. Here each item states one thing that should be true, why it matters in production, and how to verify it: a kubectl command, a setting to inspect or a drill to run. A box ticked without that evidence does not count.

Each check carries a severity. A must is something that turns a routine event (a node drain, a traffic spike, a compromised Pod) into an outage or a breach if it is missing. A should closes a gap that usually bites within the first months. A nice adds depth for workloads that matter more or clusters that are shared. Run it with the team that will be on call for the workload, and turn every gap into a ticket with an owner before the launch date.