Checklist · Kubernetes

Kubernetes Readiness Checklist

Two checklists in one — first, whether you should adopt Kubernetes at all; second, what to get right if you do. Starts with the honest test most guides skip.

Download the checklist Read the full guide

Markdown. No sign-up, no email.

Team: _______________ Date: _______

Part 1 — Should you adopt it at all?#

Answer honestly before the rest of this checklist matters. The most expensive Kubernetes mistake is adopting it for a workload that never needed it.

Count the ones that are true:

[ ] More services than the team can track by hand (typically a dozen or more)
[ ] Genuinely variable load that benefits from automatic scaling
[ ] Multiple teams needing isolated, self-service deployment
[ ] Strict availability requirements where automatic recovery is worth real money
[ ] Portability across environments as an actual requirement, not a slide

Now the other side:

[ ] We run a handful of services with steady traffic
[ ] One team deploys everything
[ ] A managed container service already meets our availability target
[ ] Nobody on the team wants to own cluster operations
[ ] Our whole estate fits comfortably on two decent servers

If more boxes are ticked in the second group, use a managed container service instead. That is not a compromise — it is the correct answer for a large share of workloads.

Decision: Adopt / Managed service / Virtual machines · Decided by: _______

Part 2 — If you are adopting it#

Cluster#

[ ] Managed control plane unless there is a specific reason otherwise
[ ] Version and upgrade path understood — support windows are short
[ ] Upgrade process rehearsed, not assumed
[ ] Node pools sized with headroom for rescheduling

Workloads — the three that cause most production problems#

[ ] Resource requests and limits set on every workload. Without them one container starves its neighbours
[ ] Liveness probe checks that the app actually works, not just that the process is running
[ ] Readiness probe distinct from liveness
[ ] Graceful shutdown handled — SIGTERM respected
[ ] Rolling update strategy set deliberately

Configuration and secrets#

[ ] Configuration in ConfigMaps, not baked into images
[ ] Secrets in a secret store, not in manifests
[ ] Same image promoted through environments
[ ] Manifests in version control and applied from there — cluster state that exists only because someone typed a command cannot be reproduced

State#

[ ] Databases are managed services, unless there is a specific reason
[ ] Any stateful workload has a tested backup and restore
[ ] Persistent volume reclaim policy understood

Security#

[ ] Containers run as non-root
[ ] Unnecessary capabilities dropped
[ ] Read-only root filesystem where possible
[ ] Network policy restricting traffic between namespaces
[ ] RBAC assigned to groups, not individuals
[ ] Images scanned, base images rebuilt regularly

Operations#

[ ] Logging, metrics, secrets, certificates and ingress decided once and applied uniformly
[ ] Monitoring answers "is the business function working", not just CPU
[ ] Rollback tested
[ ] Someone can debug a scheduling or networking failure at 3am

Restraint#

[ ] No service mesh until something specific hurts
[ ] No custom operators until something specific hurts
[ ] No multi-cluster federation until something specific hurts

Measure whether it earned its cost#

Measure	Before	After
Merge → serving traffic
Deployment failure rate
Time to restore

If these are not better than what you had, the platform is not earning its cost.

Sign-off#

	Name	Date
Completed by
Platform owner

Back to Kubernetes