Kubernetes Production Readiness Checklist
A copyable review checklist for workload ownership, resources, health checks, disruption, security, observability and recovery before a Kubernetes release.
Choose the right control
Use this template when
- A Kubernetes workload is approaching its first production release.
- A material change alters scaling, scheduling, security, persistence or recovery behaviour.
Use another workflow when
- You need live incident triage rather than a pre-release control.
- The workload is an experiment with no production traffic, data or availability commitment.
Before you start
Collect these inputs before review so unchecked controls become evidence-backed decisions rather than placeholders.
How to use this template
Copy the checklist into the change or readiness record.
Replace every unchecked item with evidence, an owner and a due date.
Treat not-applicable decisions as explicit, reviewed exceptions.
# Kubernetes production readiness ## Ownership and release - [ ] Service owner and on-call route are recorded - [ ] Image is pinned to an immutable digest - [ ] Rollback trigger and rollback procedure are tested - [ ] Deployment strategy and maximum unavailable capacity are approved ## Scheduling and resources - [ ] CPU and memory requests reflect measured normal load - [ ] Limits have been load-tested for throttling and OOM behaviour - [ ] Pod topology, affinity and tolerations match the failure model - [ ] PodDisruptionBudget permits maintenance without blocking all eviction ## Health and shutdown - [ ] Startup, readiness and liveness probes test distinct conditions - [ ] Probe timing reflects measured startup and recovery behaviour - [ ] SIGTERM handling and termination grace period are tested - [ ] The Pod stops receiving traffic before destructive shutdown work ## Security and configuration - [ ] ServiceAccount has only the required RBAC verbs and resources - [ ] Secrets are not embedded in images, manifests or logs - [ ] Security context and filesystem permissions are explicit - [ ] NetworkPolicy behaviour is tested where enforcement is expected ## Observability and recovery - [ ] Logs, metrics and traces identify the service, version and environment - [ ] Alerts use customer-impact or exhaustion signals with owned runbooks - [ ] Backup and restore are tested for stateful dependencies - [ ] Failure of every required dependency has a documented response
Evidence to retain
Review record
- The reviewed image digest and deployment manifest
- Probe, disruption and rollback test results
- Links to dashboards, alerts, runbooks and restore evidence
Definition of done
Acceptance criteria
- Every applicable control has evidence and an accountable owner.
- Exceptions have an expiry date and explicit risk acceptance.
- Rollback and dependency-failure behaviour have been exercised in a representative environment.
Apply it to a real change
A payments API is moving from a shared VM to Kubernetes and must tolerate a node drain without dropping in-flight requests or losing access to its PostgreSQL dependency.
- Record the exact Deployment and PodDisruptionBudget revisions.
- Attach the drain test showing readiness removal before shutdown.
- Link the database-dependency alert and the release rollback command.
Related KBY resources
Follow Kubernetes failures and fixes
A useful digest about twice a week with new error references, tools, integration notes and production lessons. No daily noise.