The Kubernetes Well-Architected Checklist: 12 Things to Check This Quarter

“Well-Architected” reviews have a reputation problem: they’re associated with multi-week consulting engagements, forty-page PDFs, and recommendations that assume a platform team large enough to implement them. Most of the underlying checks are genuinely useful, though, and most of them take minutes to run once you know what to look for. This is the version aimed at a small team doing this themselves, on a real cluster, this week — not a framework to schedule a workshop around.

Availability

1. Are you actually spread across availability zones, or just configured to look like it? Having three nodes doesn’t mean you’re resilient to a zone outage if all three landed in the same zone by chance. Check node labels for topology.kubernetes.io/zone and confirm your critical workloads have pod anti-affinity rules that actually spread them.

2. Does every production Deployment have a PodDisruptionBudget? Without one, a node drain during a routine upgrade can take your entire service down at once instead of rolling through it gradually. This is one of the most commonly missing pieces of production readiness — see our full breakdown of PodDisruptionBudgets for the specific numbers to set.

3. Do liveness and readiness probes actually differ? A common misconfiguration is using the same check for both, which means a pod that’s temporarily overloaded (and should stop receiving traffic via readiness) instead gets killed and restarted (via liveness), turning a load spike into a restart storm.

Security

4. Does any ServiceAccount have a ClusterRole with wildcard verbs or resources? verbs: ["*"] or resources: ["*"] bound broadly is one of the most common — and most dangerous — Kubernetes misconfigurations found in real audits. Run kubectl get clusterrolebindings -o json and grep for wildcards; see our full RBAC audit walkthrough for the exact commands.

5. Are Pod Security Standards enforced, even at the “baseline” level? Namespaces with no Pod Security Standard applied allow privileged containers, host network access, and root execution by default. Baseline enforcement blocks the most dangerous of these without requiring per-workload tuning.

6. Is there a default-deny NetworkPolicy in each namespace? Without one, every pod can talk to every other pod by default, regardless of what your architecture diagram implies. A default-deny policy plus explicit allow rules for actual traffic flows turns your network topology from documentation into enforcement.

Cost

7. What percentage of requested CPU and memory is actually used? If workloads are requesting far more than they use, you’re paying for headroom nobody needs. If they’re using far more than requested, you’re one noisy neighbor away from an eviction. Both directions are a right-sizing problem — see our guide to resource requests and limits.

8. Is Horizontal Pod Autoscaling actually configured on anything? A striking number of production clusters — by some estimates the majority — run with no HPA at all, meaning every workload is provisioned for peak load, permanently. See what most clusters get wrong about HPA for the specific gap.

9. Are non-production environments scaled down outside business hours? A staging cluster running 24/7 at production-equivalent size is one of the most common and easiest-to-fix sources of waste in a small company’s cloud bill.

Operations

10. Can you answer “what changed” for the last three incidents without checking Slack? If the answer to root cause always starts with someone scrolling through a deploy channel, that’s a signal your monitoring isn’t correlating changes with symptoms — which is exactly the gap AI-assisted root cause analysis is built to close.

11. Do you have more than 7 days of metric history? Postmortems and capacity planning both need to look back further than a week, and most default retention windows don’t. If your only visibility is “right now,” you can’t answer “has this happened before.”

12. Is there a single place to see the health of every cluster you run, or do you have to check each one individually? As soon as you’re running more than one cluster, checking each one’s dashboard separately is how a quietly degrading staging cluster goes unnoticed for weeks. A unified fleet view turns “did anyone check cluster three this week” into a single glance.

Running this as an actual quarterly habit

The value of this list isn’t the one-time pass — it’s re-running it every quarter as your cluster changes. New services get added without PodDisruptionBudgets. New ServiceAccounts get created with copy-pasted, overly broad RBAC. New namespaces skip the default-deny policy someone meant to template in. None of this is due to negligence; it’s just what happens when a cluster grows faster than anyone has time to audit it.

That’s the argument for continuous architecture review instead of a point-in-time audit: the questions above don’t change, but the answers do, quietly, every time someone ships something new. A review that reruns itself catches drift; a review that happened once in Q1 is already stale by Q2.

Frequently asked questions

How long should a full pass through this checklist take? For a small cluster, most of these checks take a few minutes each with kubectl and don’t require special tooling — a full pass is realistically an afternoon, not a multi-week engagement.

Which of these matters most if I can only fix one thing this quarter? RBAC wildcards (#4) and missing PodDisruptionBudgets (#2) tend to have the highest ratio of risk-to-effort — both are usually a few hours of work with an outsized reduction in blast radius.

Do I need a compliance framework to justify doing this? No — this list is useful purely on engineering merit. Formal frameworks (SOC 2, ISO 27001) will eventually require similar evidence, but that’s a reason to have already done this, not a prerequisite for starting.

Is this the same as a security audit? It overlaps significantly with one but is broader — a security audit typically stops at sections 4-6. Availability and cost matter just as much to whether your architecture is actually sound.

See how VantraOps turns this into an ongoing, automatic review instead of a quarterly chore — start free with one cluster.