Production Readiness Checklist

A Kubernetes workload is production-ready only when it can be operated, secured, observed, updated, recovered, and explained under pressure.

Kubernetes Field Notes · Production Readiness · Estimated reading time: 20 minutes

What this lesson covers

This lesson turns the training path into a practical production readiness checklist. It is not a replacement for architecture review, but it gives you a concrete set of questions before calling a Kubernetes workload production-ready.

Workload design checklist

• Does the workload run through a Deployment, StatefulSet, DaemonSet, Job, or CronJob instead of unmanaged Pods?
• Are replicas appropriate for availability and load?
• Are labels consistent and meaningful?
• Are selectors correct and stable?
• Are container images pinned to intentional versions rather than loose tags?
• Are startup, readiness, and liveness probes configured correctly?

Resource checklist

• Are CPU and memory requests set?
• Are memory limits reasonable?
• Are CPU limits intentional?
• Have actual metrics been compared to requested resources?
• Are Namespace ResourceQuotas or LimitRanges needed?
• Is there enough cluster capacity for failures, rollouts, and scaling?

Configuration checklist

• Are non-sensitive settings stored in ConfigMaps?
• Are sensitive values stored in Secrets or an external secret manager?
• Are secrets excluded from Git?
• Are configuration updates handled through rollout or reload behavior?
• Are environment-specific settings clearly separated from the image?

Networking checklist

• Does each workload that needs stable access have a Service?
• Do Service selectors match Pod labels?
• Do Services have ready endpoints?
• Are ports and targetPorts correct?
• Is Ingress configured with the correct hostnames and paths?
• Is DNS pointed at the correct ingress/load balancer entry point?
• Is TLS configured correctly for production HTTP traffic?

Security checklist

• Does the workload use a dedicated ServiceAccount?
• Are RBAC permissions least privilege?
• Can the workload read only the Kubernetes resources it actually needs?
• Are Secrets protected by RBAC and operational process?
• Are risky Pod settings restricted by policy?
• Are images scanned through the organization’s normal process?
• Are NetworkPolicies needed for workload isolation?

Storage checklist

• Does the workload need persistent storage?
• Are PVCs sized appropriately?
• Is the StorageClass suitable for the workload?
• Are backup and restore processes defined?
• Has restore actually been tested?
• Are stateful workloads using the right controller pattern?

Observability checklist

• Are application logs useful and structured enough to troubleshoot?
• Are secrets excluded from logs?
• Are metrics collected?
• Are restart counts, readiness failures, and resource saturation monitored?
• Are alerts tied to user impact and operational symptoms?
• Is there a dashboard for the workload?

Release checklist

• Is the deployment process repeatable?
• Is rollout status checked after deployment?
• Is rollback tested?
• Are Helm values or manifests reviewed?
• Are changes traceable to commits, tickets, or approvals?
• Are migrations handled safely?

Failure checklist

• What happens if a Pod is deleted?
• What happens if a node is unavailable?
• What happens if a dependency is down?
• What happens if an image pull fails?
• What happens if the app exceeds memory limits?
• What happens during a rolling update?
• What happens if storage is unavailable?

Operational runbook starter

Every production workload should have at least a basic runbook:

Workload name:
Namespace:
Owner/team:
Criticality:
Public or internal:
Primary URL:
Primary Service:
Ingress:
ConfigMaps:
Secrets:
Storage:
Normal replica count:
Resource requests:
Resource limits:
Health endpoints:
Dashboard:
Alerts:
Rollback command:
Common failure modes:
Escalation path:

Minimum kubectl checks before signoff

kubectl get all -n <namespace>
kubectl get ingress -n <namespace>
kubectl get configmaps -n <namespace>
kubectl get secrets -n <namespace>
kubectl get pvc -n <namespace>
kubectl describe deployment <deployment-name> -n <namespace>
kubectl rollout status deployment/<deployment-name> -n <namespace>
kubectl get endpoints -n <namespace>
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp

Go/no-go questions

• Can the workload be rebuilt from source and redeployed?
• Can the workload be rolled back?
• Can the team explain how traffic reaches the Pods?
• Can the team explain what happens when a Pod dies?
• Can the team explain where configuration and secrets come from?
• Can the team explain how to troubleshoot the top three failure modes?
• Can the team prove backups and restores where state exists?

Check your understanding

1. Why is “it runs” not enough for production readiness?
2. Why should workloads avoid unmanaged Pods?
3. Why do probes matter in production?
4. Why are requests and limits part of readiness?
5. Why should rollback be tested?
6. Why should Secrets be part of the checklist?
7. What should a runbook identify?
8. Why do endpoints matter for Services?
9. Why does restore testing matter for stateful systems?
10. Name five categories in the production readiness checklist.