# What "Production-Ready" Actually Means for a Kubernetes Cluster

Canonical: https://kaansystems.com/library/production-ready-kubernetes
Topic: Platform · Published: 2026-05-12 · Updated: 2026-10-12
Summary: 'Production-ready' is one of those phrases that lets engineering and product teams nod at each other while meaning different things. The concrete checklist that resolves the ambiguity: five dimensions, forty items, scored 0-2.

## Key takeaways

- Production-ready is a checklist, not an inherent property — a cluster either has the capabilities or it doesn't, and the checklist makes that explicit and scoreable.
- The scorecard spans five dimensions — Identity & Access, Network, Workload Health, Observability, and Recovery — with eight items each scored 0, 1, or 2, for a maximum of 80 points.
- 70 or above is production-ready, 60-69 is production-soft (fine only for non-customer-facing or non-regulated workloads), and below 60 is a demo that shouldn't run production traffic or hold PHI.
- Most teams score around 50 on their first honest pass; the next quarter's work is moving that 50 to 70, which is where the architectural investment lives.
- Re-score every cluster every six months, because readiness drifts: items that once scored 2 slip to 1 when a person leaves, a process lapses, or a tool changes.
- Make the scorecard part of a cluster's launch criteria, and when a customer asks whether your platform is production-grade, share the methodology rather than the raw score.

**What does "production-ready" actually mean for a Kubernetes cluster?** It's a checklist, not a property. Score the cluster across five dimensions — identity and access, network, workload health, observability, and recovery — with eight items each, rated 0 to 2. Seventy or more out of eighty is production-ready. Below sixty is a demo.

## Why do teams disagree on what production-ready means?

A new Kubernetes cluster goes from "demo working" to "production-ready" through a series of capabilities that aren't visible in any individual feature. The cluster has them all, or it doesn't. The people responsible for declaring "production-ready" (engineering leadership, security review, a customer's procurement team) usually don't have a shared definition of what those capabilities are. Cluster readiness is one pillar of the [Terraform and platform guide](/library/platform-engineering-for-regulated-startups). The deploy path is [GitOps and progressive delivery](/library/gitops-progressive-delivery), the controller choice is [Argo CD vs. Flux](/library/argo-cd-vs-flux), and the reliability number the scorecard should meet is an [SLO](/library/slos-for-small-teams). The [7-day Assessment](/assessment) scores the same items.

That causes two failure modes:

- A cluster gets declared production-ready and isn't. The first incident reveals that nothing was set up to recover. The team learns the gap the expensive way.
- A cluster gets blocked from production indefinitely because no two reviewers can agree on what's missing. The launch slips by quarters.

The fix is a checklist. Not exhaustive. Concrete and scoreable.

## How do you score a cluster so the argument ends?

Five dimensions. Each has eight items. Each item scores 0, 1, or 2:

- **0.** Not addressed.
- **1.** Partially or informally addressed.
- **2.** Fully addressed and operationally verified.

A score of 70+/80 across the dimensions is "production-ready." 60-69 is "production-soft." Below 60 is "demo." The threshold is somewhat arbitrary. The score is what matters: a number leadership can use to compare clusters and track progress.

```mermaid
flowchart TB
  CL((Cluster))
  CL --- D1[Identity &amp; Access<br/>8 items · 0-16 pts]
  CL --- D2[Network<br/>8 items · 0-16 pts]
  CL --- D3[Workload Health<br/>8 items · 0-16 pts]
  CL --- D4[Observability<br/>8 items · 0-16 pts]
  CL --- D5[Recovery<br/>8 items · 0-16 pts]

  D1 --> T[Total · 0-80]
  D2 --> T
  D3 --> T
  D4 --> T
  D5 --> T

  T --> R1[70-80<br/>Production-ready]
  T --> R2[60-69<br/>Production-soft]
  T --> R3[Below 60<br/>Demo]

  classDef hub  fill:#1F4A3E,stroke:#3FA585,stroke-width:2.5px,color:#E8F5EE;
  classDef dim  fill:#0d1f1a,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE;
  classDef good fill:#1F4A3E,stroke:#3FA585,stroke-width:2px,color:#E8F5EE;
  classDef warn fill:#0d1f1a,stroke:#2E8B6F,stroke-width:1px,color:#E8F5EE;
  classDef bad  fill:#0a1612,stroke:#1F4A3E,stroke-width:1px,color:#A8B8B0;

  class CL,T hub;
  class D1,D2,D3,D4,D5 dim;
  class R1 good;
  class R2 warn;
  class R3 bad;
```

### Dimension 1: Identity & Access

The cluster's answer to "who can do what."

1. **Cluster-level authentication source** is an enterprise identity provider (OIDC, SAML), not static kubeconfigs.
2. **RBAC is least-privilege by default.** No default-admin bindings. No `cluster-admin` ClusterRoleBindings to groups larger than a handful of platform engineers.
3. **Service accounts are namespaced and tightly scoped.** No application uses the `default` service account.
4. **Workload identity** (IRSA on EKS, Workload Identity on GKE, AAD Pod Identity on AKS) ties pod-level access to cloud IAM. No long-lived cloud credentials in cluster.
5. **Audit logging** for the API server is on, shipped to a log-archive store outside the cluster, with at least 90-day retention.
6. **MFA enforced** on the identity provider for any user with cluster access.
7. **Break-glass access** is documented: who has it, how it's used, how it's audited after.
8. **No long-lived kubeconfigs** issued to anyone. Access is short-lived and re-authenticated.

### Dimension 2: Network

How traffic flows in, out, and between pods.

1. **NetworkPolicy enforcement enabled** on the cluster (most clusters require an explicit CNI plugin choice for this).
2. **Default-deny network policy** in every namespace; explicit allow rules for required traffic.
3. **Ingress controllers terminate TLS** at the edge with managed certificates that auto-renew (cert-manager + ACME is standard).
4. **Egress controlled.** Either a NAT gateway with logging, an egress proxy, or — for stricter postures — explicit egress NetworkPolicy.
5. **Service mesh or sidecar mTLS** for service-to-service traffic in regulated environments. Not mandatory for non-regulated workloads.
6. **DNS policy** doesn't allow arbitrary external DNS. CoreDNS is configured with explicit forwarders.
7. **Load-balancer health checks** properly configured (path, interval, threshold) — not the AWS default which often misses application-level health.
8. **No services exposed as LoadBalancer or NodePort** without explicit review. Ingress is the only sanctioned external entry path.

### Dimension 3: Workload Health

What happens when things start to fail.

1. **Every deployment has liveness and readiness probes**, distinct from each other and not the default "/healthz returns 200" placeholder.
2. **Resource requests and limits set** on every container. Not optional. Enforced via OPA/Gatekeeper or Kyverno.
3. **PodDisruptionBudgets** on every production workload, set to allow at most 25% disruption.
4. **Horizontal Pod Autoscaler or KEDA** configured for workloads with variable load.
5. **Anti-affinity rules** prevent all replicas of a critical workload from landing on the same node.
6. **Quality of Service class is Guaranteed** for critical workloads (requests = limits).
7. **Init containers have timeouts** and are not used for arbitrary one-time setup that should be a Job.
8. **Graceful shutdown** is implemented in application code. SIGTERM is handled; in-flight requests complete.

### Dimension 4: Observability

What the operator can see during normal operation and during incidents.

1. **kube-state-metrics** scraped by Prometheus or equivalent.
2. **Node-level metrics** (node-exporter, kubelet) scraped.
3. **Application metrics** exposed by every service, with at minimum the four Golden Signals (latency, traffic, errors, saturation).
4. **Centralized logging** ships every container's stdout/stderr to a queryable store with at least 30-day retention.
5. **Audit log retention** beyond the centralized logging system (separate retention rule for security events).
6. **SLOs defined** for every production service, with error budget tracking visible on a shared dashboard.
7. **Alerts route to a paging system** with documented runbooks. Pages are tested quarterly.
8. **Tracing** enabled for services in the request path (less critical for backend batch services).

### Dimension 5: Recovery

What happens when the cluster, or a piece of it, fails entirely.

1. **etcd backups** every 30 minutes, retained for 30 days, stored outside the cluster.
2. **Application data backed up** via Velero or equivalent, with cross-region copies for regulated environments.
3. **Restore drill performed at least annually.** Documented runbook with timestamps.
4. **Documented disaster-recovery posture.** RTO and RPO targets stated, mapped to actual backup cadence.
5. **HA control plane.** Managed services (EKS, GKE, AKS) provide this; self-managed clusters need explicit verification.
6. **Multi-AZ workload spread** for production deployments via anti-affinity or topology spread constraints.
7. **Stateful workloads use StorageClasses** with documented backup and snapshot policies.
8. **Cluster upgrade procedure documented and rehearsed.** Last upgrade was within the support window of the current Kubernetes version.

## How do you upgrade without a version-skew outage?

A cluster that scored well last year and has not been upgraded is not production-ready. Kubernetes allows only a limited skew between the control plane and the nodes, and EKS, AKS, and GKE drop minor versions on a published calendar. Move one minor at a time, nodes after the control plane, and rehearse the procedure on a non-production cluster first. The scorecard already asks whether the last upgrade sat inside the current version's support window. If it did not, that row is a zero even when every other row is a two. The Assessment checks version, skew, and whether anyone has run the upgrade since the last support boundary.

## The Template

Score your cluster row by row. Anywhere you can't honestly score 2, write a one-line note explaining the gap and the planned remediation.

Total score: __ / 80

- **70-80: Production-ready.** Document the score, the date, the cluster, and circulate to whoever needs to approve.
- **60-69: Production-soft.** OK for non-customer-facing or non-regulated workloads. Not OK for the production workload your customers depend on.
- **Below 60: Demo.** Don't run production traffic. Don't put PHI on it. Don't claim it as "production" in customer contracts.

The number you produce will feel low the first time. That's the point. Most teams score around 50 on the first honest pass. The next quarter's work is moving 50 to 70.

## Operating Notes

Re-score every cluster every six months. Drift happens. Items that scored 2 become 1 because a person left, a process lapsed, a tool changed. The score is a leading indicator.

When a new cluster is built, the scorecard is part of the launch criteria. Cluster cannot host production traffic until the score is documented and approved. This creates an explicit gate that engineering, security, and product can all point at.

When a customer asks "is your platform production-grade?" — share the scorecard methodology, not the raw score. The methodology builds trust; the raw score gets weaponized in contract negotiations.

## Frequently asked questions

**Q: What does 'production-ready' actually mean for a Kubernetes cluster?**

It means the cluster passes a concrete checklist rather than possessing some vague quality. You score it across five dimensions — identity and access, network, workload health, observability, and recovery — and a total of 70 or more out of 80 is production-ready.

**Q: How is the production-readiness scorecard structured?**

Five dimensions, eight items each, and every item scored 0 (not addressed), 1 (partially or informally addressed), or 2 (fully addressed and operationally verified). That gives each dimension 0-16 points and a cluster a total out of 80.

**Q: What score counts as production-ready?**

70 to 80 is production-ready, 60 to 69 is 'production-soft' — acceptable for non-customer-facing or non-regulated workloads but not for the production workload customers depend on — and below 60 is a demo that shouldn't carry production traffic or PHI. The threshold is somewhat arbitrary; the number's real value is comparing clusters and tracking progress.

**Q: Why did my cluster score so low the first time?**

That's expected. Most teams score around 50 on their first honest pass, and the honesty is the point. The next quarter's work is moving that 50 to 70, which is where the identity, network-policy, and observability investment lives.

**Q: How often should you re-score a cluster?**

Every six months. Readiness drifts — an item that scored 2 becomes a 1 when a person leaves, a process lapses, or a tool changes — so the score is a leading indicator rather than a one-time certificate.

**Q: Should you show the scorecard to customers?**

Share the methodology, not the raw score. The methodology builds trust; the raw number tends to get weaponized in contract negotiations. Making the scorecard part of a cluster's launch criteria also gives engineering, security, and product one explicit gate to point at.

Template: "Production-readiness scorecard" — branded PDF at https://kaansystems.com/templates/production-ready-kubernetes.pdf

Source: https://kaansystems.com/library/production-ready-kubernetes · Work with Kaan Systems: https://kaansystems.com/contact