A cluster that accepts kubectl apply is not a cluster that is ready for customers. Closing that gap is what a Kubernetes production checklist is for: it separates "the pods are Running" from "this survives a node failure at 2am, a control-plane upgrade, a bad release and a compromised service account."
Most enterprise incidents in the first year of running Kubernetes are not exotic. They are missing resource limits, a probe that restarts a healthy pod, a namespace with no network policy, or a backup nobody has ever restored. This checklist covers the four gates every cluster should clear before it takes real traffic, plus the 2026 deadlines that catch teams out.
What "Production Ready" Actually Means for a Kubernetes Cluster
Production readiness is not a feature list. It is the answer to three questions:
- Can it lose things without losing service? A node, an availability zone, a pod, a dependency.
- Can you see it fail before customers tell you? And can you tell which service failed, not just that something did.
- Can you get back? From a bad deploy, a deleted namespace, a corrupted volume, a wrong
terraform apply.
Cluster and Workload Configuration Checks
Version currency has a deadline and a price
Kubernetes maintains release branches for the three most recent minor versions on a roughly 15-week cadence, which works out to about 14 months of support per release. Outside that window, you are running unpatched.
On managed platforms it also costs money. Amazon EKS bills $0.10 per cluster per hour during standard support and $0.60 once a version enters extended support — a 6x jump that arrives automatically, triggered by a calendar rather than a decision. That is roughly $4,380 extra per cluster per year for doing nothing.
Two 2026 upgrade hazards to plan around:
- cgroup v2 is required from Kubernetes 1.35. Old node images on cgroup v1 will not join.
gitRepovolumes are permanently disabled in 1.36. Any manifest still using one will fail to start pods.
Check your position against the EKS version lifecycle or your provider's equivalent. If you are still choosing a platform, our EKS vs GKE vs AKS comparison covers how their upgrade models differ.
The workload checks that prevent most early incidents
| Check | Why it matters |
|---|---|
| Requests and limits on every container | Without requests the scheduler guesses; without limits one pod starves a node |
| Liveness and readiness probes configured separately | A liveness probe that checks a dependency restarts healthy pods during a downstream blip |
| PodDisruptionBudgets on stateful and singleton workloads | Node drains during upgrades otherwise take your quorum with them |
| Topology spread across nodes and zones | Three replicas on one node is one replica |
maxUnavailable set deliberately per Deployment | Default rolling updates can drop capacity below what traffic needs |
| Autoscaling at pod and node level | HPA without node capacity just produces Pending pods — pair it with Karpenter or Cluster Autoscaler |
| Graceful shutdown handling | SIGTERM ignored means dropped in-flight requests on every deploy |
If voluntary disruptions have ever surprised you mid-upgrade, the PodDisruptionBudget documentation is worth a careful read.
Security, RBAC, and Network Policy Checks
Kubernetes defaults are permissive by design. Every pod can talk to every other pod, and service account tokens mount whether the pod needs them or not. Readiness means closing those defaults deliberately.
- RBAC scoped to namespaces, not the cluster. Audit
ClusterRoleBindingentries pointing atcluster-admin, and anything bound to adefaultservice account. Wildcard verbs and resources are a finding, not a convenience. automountServiceAccountToken: falseunless the pod calls the API. Most pods do not, and a mounted token is a free credential for whoever lands inside the container.- Default-deny NetworkPolicy per namespace, then allow what is needed. This is the control that turns a container escape into a contained incident instead of a lateral one.
- Pod Security Admission enforced at
baselineorrestricted. PodSecurityPolicy has been gone since 1.25, so clusters built before that with nothing in its place have no pod-level guardrails. The Pod Security Standards define the levels. - Secrets from an external store, encrypted at rest. Kubernetes Secrets are base64-encoded, not encrypted, unless you configure encryption at rest.
- Image provenance enforced by admission control. Signed, scanned images from your own registry, checked by a policy engine rather than a wiki page — which is where DevSecOps work pays for itself.
- Audit logs enabled and shipped off-cluster. If the cluster is the incident, logs stored inside it are not evidence.
Observability, Backup and Recovery Checks
Observability
Node dashboards tell you a cluster is busy. They do not tell you checkout is failing for 4% of users. Production readiness means:
- Metrics, logs and traces correlated by a shared identifier, not three tools with three search boxes.
- Alerts on user-facing symptoms — error rate, latency, saturation — rather than on
CPUThrottlingHigh, which pages you at 3am for nothing. - A named owner for every alert. An alert routed to a shared inbox is a suppressed alert.
- Retention long enough to investigate a slow regression, not just last night's spike.
Our Datadog vs Grafana for Kubernetes breakdown includes real cost maths if tooling is still open, and monitoring and observability services covers the instrumentation work.
Backup and recovery
| Failure scenario | What you need in place |
|---|---|
| Resource or namespace deleted by accident | Cluster state backups (etcd, or an application-aware tool such as Velero) |
| Persistent volume corruption | Volume snapshots with a tested restore path, not just a snapshot schedule |
| Bad release reaches production | A rollback that is one command or one Git revert, verified in staging |
| Whole cluster lost | Cluster rebuildable from code — Terraform for infrastructure, GitOps for workloads |
| Region unavailable | RTO and RPO the business has actually agreed to |
The check that fails most often is not "do you have backups" but "when did you last restore one?" Rehearse quarterly and time it — that number is your real RTO. Our Kubernetes backup and disaster recovery practice exists largely because that rehearsal keeps getting deferred.
Where Enterprise Teams Usually Fail This Checklist
Three patterns recur in readiness reviews:
- Staging that does not resemble production. One node, no network policies, no PDBs. Everything passes there and nothing is tested.
- Checks that live in a document instead of a pipeline. If a manifest without limits can merge, limits are optional. Enforce through admission policies and CI so the checklist is a gate.
- No owner for cluster health. Teams own services; nobody owns upgrades, node images or certificate expiry — until something expires. That is the gap SRE ownership closes.
Platforms such as Atmosly check much of this continuously, so drift surfaces as a report rather than an outage.
Turn the Checklist Into a Gate
Work the four gates in order — configuration, security, observability, recovery — and be honest about which items are enforced versus merely documented. Anything documented but unenforced will drift within a quarter.
If you would rather have this audited by engineers who do it weekly, our Kubernetes services include production readiness reviews, upgrade planning and 24x7 operations. Talk to our team and we will tell you which gate your clusters are actually at.
