# Kubernetes Checklist

**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 | | |