← Back to docs

Production Kubernetes Readiness Checklist

A practical, battle-tested checklist for taking a Kubernetes workload from 'it runs' to 'it's production-ready', reliability, security, observability, and cost.

Production Kubernetes Readiness Checklist

"It works on my cluster" is not the same as production-ready. This checklist is what I actually walk through before signing off on a workload going live. It pairs with the gitops-kubernetes-platform and observability-stack reference repos.

1. Workload health

  • Liveness, readiness, and startup probes defined for every container.
  • Readiness probe gates traffic; liveness probe restarts only on true deadlock.
  • terminationGracePeriodSeconds set, and the app handles SIGTERM to drain.
  • preStop hook where needed (e.g. deregister from a load balancer first).

2. Resource management

  • Requests and limits set on every container, no unbounded pods.
  • Requests reflect real usage (measured, not guessed).
  • A LimitRange and ResourceQuota per namespace.
  • HPA configured for variable load; tested against a real traffic profile.

3. Resilience

  • replicas >= 2 for anything that must stay available.
  • PodDisruptionBudget so voluntary disruptions don't take the service down.
  • Pod anti-affinity / topology spread across nodes and zones.
  • Rolling update strategy with sane maxSurge / maxUnavailable.

4. Security

  • Run as non-root; readOnlyRootFilesystem: true where possible.
  • Drop all Linux capabilities, add back only what's needed.
  • securityContext and a Pod Security Standard (restricted) enforced.
  • NetworkPolicies: default-deny, then allow only required traffic.
  • Secrets from a real store (Vault / External Secrets), not plain Secret manifests.
  • Images scanned (Trivy) and ideally signed (cosign), see the devsecops-starter-kit.

5. Observability

  • Metrics exposed and scraped (Prometheus) with useful labels.
  • Structured logs shipped to a backend (Loki).
  • Traces for request flows (Tempo / OpenTelemetry).
  • SLOs defined and alerting on burn rate, not just raw thresholds.
  • Dashboards exist before launch, not after the first incident.

6. Delivery

  • GitOps: the cluster state lives in Git, reconciled by ArgoCD/Flux.
  • Automated rollback path tested (not just documented).
  • Progressive delivery (canary/blue-green) for high-risk services.

7. Cost

  • Right-sized nodes; consider Karpenter/Cluster Autoscaler.
  • Spot instances for fault-tolerant workloads.
  • Idle/oversized resources flagged and reviewed regularly.

The one question that matters

Before launch, ask: "What happens at 3am when this breaks, and can the on-call engineer fix it from the runbook?" If the answer is unclear, you're not done yet.

Reactions & comments