Before deploymentkubernetes-workload-readiness

Workload Production Readiness Checklist

14 items ·9 critical ·5 warn ·0 info

How to use this checklist

Run this against a specific workload before it carries production traffic. The recurring theme is that Kubernetes will do exactly what the manifest says, including the parts nobody wrote down.

Mark an item N/A when it genuinely does not apply, and write down why. An unexplained N/A is the most common way a checklist stops working.

Sign-off

Every critical item must pass. A failing critical item blocks the deployment or the maintenance window; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical9 items

Every container declares CPU and memory requests. Without them the scheduler is guessing and the Pod is BestEffort — first to be evicted.
```
kubectl get pods -n <ns> -o jsonpath'{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].resources}{"\n"}{end}'
```
Every container declares a memory limit. Memory is incompressible: without a limit a single leak takes the node down, not just the Pod.
Liveness and readiness probes exist and are not the same endpoint. A liveness probe that fails under load turns a slowdown into a restart loop.
Replica count is at least two for anything that must survive a node drain, and the workload has been tested with one replica removed.
```
kubectl get deploy -n <ns>
```
A PodDisruptionBudget exists and permits at least one disruption. A PDB with zero allowed disruptions blocks every drain and is worse than none.
```
kubectl get pdb -n <ns>
```
Replicas are spread across nodes and zones via topologySpreadConstraints or anti-affinity. Three replicas on one node is one failure.
```
kubectl get pods -n <ns> -o wide
```
terminationGracePeriodSeconds is longer than the application actually needs to drain, and the app handles SIGTERM rather than ignoring it.
Images are pinned by digest or an immutable tag. `:latest` makes the running version unknowable and rollbacks meaningless.
```
kubectl get pods -n <ns> -o jsonpath='{.items[*].spec.containers[*].image}'
```
A rollback has been performed at least once in a non-production environment, and the command is in the runbook.
```
kubectl rollout undo deployment/<name> -n <ns>
```

Warning5 items

The presence or absence of a CPU limit is a deliberate decision. A CPU limit on a latency-sensitive service buys throttling, not safety.
Slow-starting containers use a startupProbe rather than a long liveness initialDelaySeconds.
A preStop hook or equivalent covers the gap between endpoint removal and SIGTERM, so in-flight requests are not dropped on every rollout.
The workload runs as non-root with a read-only root filesystem and no added capabilities, or each exception is documented.
Configuration and secrets come from ConfigMaps and Secrets, not baked into the image.