A Kubernetes production readiness checklist

First, check that you need Kubernetes

Kubernetes is a powerful platform for running many containerized workloads with consistent scheduling, scaling, and self-healing. It also adds real operational surface area. For a small number of services, a managed container service or a well-run set of virtual machines can be simpler to operate and cheaper to own.

Kubernetes tends to pay off when you have multiple services, multiple teams, a need for consistent deployment tooling, or workloads that benefit from autoscaling. If none of those apply yet, it is reasonable to wait.

Workload fundamentals

Most production problems on Kubernetes trace back to workloads that were deployed with defaults. Settle these basics for every service:

• Resource requests and limits, so the scheduler can place pods sensibly and one workload cannot starve another.
• Readiness, liveness, and startup probes that reflect real health.
• Graceful shutdown: handle SIGTERM and set a termination grace period that matches your longest in-flight request.
• More than one replica for anything that must stay available, spread across nodes or zones.
• PodDisruptionBudgets so that node maintenance and upgrades do not take every replica down at once.

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    memory: 256Mi
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 5

Security baseline

The defaults in a cluster are permissive. A sensible baseline includes:

• Run containers as a non-root user, with a read-only root filesystem and unneeded Linux capabilities dropped.
• Apply Pod Security Standards at the baseline or restricted level per namespace.
• Use RBAC with least privilege, and avoid broad cluster-admin bindings.
• Use NetworkPolicies to restrict which workloads can talk to each other.
• Keep secrets out of manifests and images; use an external secrets manager or a sealed-secrets approach.
• Scan images for vulnerabilities and reference them by version or digest rather than a mutable latest tag.

Declarative, reviewed delivery

Production cluster state should come from version control, not from kubectl commands run by hand. Package applications with Helm or Kustomize, store manifests in Git, and consider a GitOps controller such as Argo CD or Flux that continuously reconciles the cluster toward what Git declares. Every change is then reviewable, auditable, and reversible.

Observability from day one

Collect cluster and workload metrics (Prometheus with kube-state-metrics is a common choice), centralize logs, and keep an eye on Kubernetes events. Alert on symptoms that affect users, such as error rates and latency, instead of every pod restart, and connect those alerts to SLOs where you have them.

Plan for upgrades and capacity

Kubernetes releases new minor versions several times a year and supports each for a limited window, so upgrades are routine work that needs a plan, a staging environment, and a rollback strategy. Managed offerings such as Amazon EKS and Azure AKS reduce the effort of running the control plane, but node pools, add-ons, and workload compatibility remain your responsibility.

For capacity, tune requests against observed usage, and use horizontal pod autoscaling and node autoscaling where demand varies. Over-requested resources are a common hidden cost.

Back up and rehearse recovery

Keep manifests in Git, back up persistent volumes and any stateful data, and for self-managed clusters back up etcd. Then test a restore into a clean cluster. As with any backup, the plan is only proven once it has been exercised.