Kubernetes Production Readiness Checklist

Kubernetes Production Readiness Checklist is a consolidated verification framework that draws together the individual guideline areas — container design, resource configuration, scheduling, health checks, deployment safety, storage, networking, identity and access, observability, and reliability — into a single pass/fail gate applied before a workload is allowed to serve real production traffic. It exists because any one guideline area can be followed correctly in isolation while the workload as a whole is still unready, since production readiness is a property of the complete configuration, not of any single dimension considered alone.

Container and Image Readiness

Image Provenance and Immutability

The workload's image must be referenced by digest or immutable tag, built from a minimal base image, scanned for known vulnerabilities with none above the organization's accepted severity threshold, and free of build tooling or secrets baked into any image layer.

Process Behavior

The main process must correctly handle SIGTERM within its configured grace period, run as a non-root user, and avoid unnecessary Linux capabilities and host namespace access unless a specific, justified need requires them.

Resource and Scheduling Readiness

Resource Declarations

Every container must declare CPU and memory requests sized from actual observed usage, and limits that protect node stability without causing routine throttling or OOM kills under expected load.

Placement and Spread

The workload must run at least the minimum replica count its availability requirement demands, spread across nodes and failure domains via anti-affinity or topology spread constraints, with a PriorityClass reflecting its actual criticality relative to other workloads sharing the cluster.

Health and Deployment Safety

Probe Correctness

Liveness, readiness, and (if needed) startup probes must be defined, checking the correct scope for each probe type — liveness never checking downstream dependencies, readiness reflecting genuine ability to serve traffic — with timing parameters validated against the workload's actual startup and response-time characteristics.

Rollout Configuration

The Deployment's rollout strategy must maintain acceptable capacity throughout an update (maxUnavailable and maxSurge reviewed, not left at defaults without consideration), progressDeadlineSeconds must be set to catch a stalled rollout, and a tested rollback path must exist.

Disruption Tolerance

A PodDisruptionBudget must be in place, sized to preserve the workload's minimum viable capacity (and, for quorum-based stateful workloads, quorum itself) during voluntary cluster disruptions.

Storage and State Readiness

Persistence Correctness

Any workload holding state must use appropriately access-moded, correctly reclaim-policied persistent storage, sized with headroom and monitored for utilization, with a tested backup and restore procedure independent of the cluster's own availability.

No Assumed Local State

Any data the workload assumes to persist across restarts must live in a PersistentVolume or external store — nothing critical should depend on the container's ephemeral writable layer surviving a restart.

Network and Security Readiness

Traffic Exposure

The workload's Service and any Ingress/Gateway routing must expose only what's genuinely needed externally, with TLS terminated using automatically renewed certificates and a minimum accepted TLS version explicitly configured.

Network Policy

A NetworkPolicy must restrict both ingress and egress to the specific traffic the workload legitimately requires, following a default-deny baseline rather than relying on the cluster's flat, open-by-default network model.

RBAC Scope

The workload's ServiceAccount must hold only the API permissions its own logic actually requires, with automatic token mounting disabled if it never calls the Kubernetes API at all, and any Secrets it consumes must be scoped narrowly and never committed to version control unencrypted.

Observability Readiness

Signal Coverage

The workload must expose structured logs to stdout/stderr, Prometheus-compatible metrics covering at minimum rate, error rate, and latency (or the equivalent resource-utilization signals for non-request-driven workloads), and participate in distributed tracing if it's part of a multi-service request path.

Alerting Coverage

Symptom-based alerts must exist for the conditions that would represent genuine user-facing degradation, tuned against historical data to avoid both false positives and missed real incidents, with a clear on-call ownership path for when they fire.

Reliability and Operational Readiness

Dependency Resilience

Calls to downstream dependencies must have explicit timeouts, retries with backoff and jitter (not naive immediate retries), and circuit breaking or graceful fallback behavior for non-critical dependencies.

Capacity and Autoscaling

Autoscaling (horizontal, and vertical where appropriate) must be configured against a metric that genuinely reflects load, with minReplicas reflecting real redundancy needs and maxReplicas reflecting what downstream dependencies can actually absorb.

Runbooks and Ownership

An on-call runbook must exist covering known failure modes and their remediation, and the workload must have a clearly identified owning team accountable for its production behavior.

Consolidated Checklist

[ ] Image pinned by digest, scanned, minimal base
[ ] Non-root, minimal capabilities, correct SIGTERM handling
[ ] Resource requests/limits sized from real usage data
[ ] Replica count and anti-affinity meet availability requirement
[ ] PriorityClass reflects actual workload criticality
[ ] Liveness/readiness/startup probes correctly scoped and tuned
[ ] Rolling update strategy and progressDeadlineSeconds reviewed
[ ] Rollback path tested
[ ] PodDisruptionBudget configured
[ ] Persistent storage access mode, reclaim policy, backups verified
[ ] Service/Ingress exposure minimized, TLS auto-renewed
[ ] Default-deny NetworkPolicy scoped to actual traffic needs
[ ] ServiceAccount RBAC scoped to least privilege
[ ] Secrets encrypted at rest, never committed in plaintext
[ ] Structured logs, metrics, and (if applicable) tracing wired up
[ ] Symptom-based alerts configured with on-call ownership
[ ] Dependency timeouts, backoff, and fallback behavior implemented
[ ] Autoscaling configured against a meaningful metric
[ ] Runbook exists and owning team identified

Practical Consequences

A workload that passes this checklist has been verified against every dimension known to commonly cause production incidents, rather than having only the dimensions its authors happened to think of. Skipping this consolidated review in favor of ad hoc, per-area diligence is how production incidents recur despite every individual guideline document existing — a gap in one area (an unset PodDisruptionBudget, an unscoped NetworkPolicy) is invisible until the exact failure condition it was meant to guard against actually occurs.