Kubernetes production checklist

1. Workload safety

• Resource requests are set from observed workload behavior. Limits are used deliberately where they protect the platform without creating avoidable throttling or OOM risk.
• Startup, readiness and liveness probes represent different failure modes. A readiness failure removes a backend; liveness is not a substitute for application monitoring.
• Deployments use controlled rollout settings. Max surge/unavailable values reflect capacity and availability requirements.
• Critical workloads have disruption protection appropriate to replica count and failure domains. Test node drains rather than assuming a PDB is sufficient.
• Pods are spread across relevant nodes or zones when the architecture requires failure-domain resilience.

2. Identity and least privilege

• Workloads use named ServiceAccounts. Avoid the default account where a workload needs explicit permissions.
• RBAC grants the smallest useful verbs, resources and namespaces. Periodically inspect who can impersonate users, read Secrets or mutate cluster-scoped resources.
• Human cluster access uses short-lived or centrally managed identity where the platform supports it.
• Cloud API access uses workload identity mechanisms rather than long-lived credentials in Pod environment variables.

3. Pod and runtime security

• Pod Security Admission or equivalent policy is configured deliberately. Use the restricted profile where compatible and document exceptions.
• Containers run without privilege escalation and drop unnecessary Linux capabilities.
• Run-as-non-root and seccomp settings are enforced where the image supports them.
• HostPath, host networking, host PID/IPC and privileged workloads require explicit justification.
• Read-only root filesystems are used where application behavior permits them, with writable paths mounted intentionally.

4. Network boundaries

• The CNI actually enforces NetworkPolicy before policy is treated as a control.
• Namespaces that require isolation have a default-deny posture plus explicit DNS and application flows.
• Ingress/Gateway exposure is limited to intended services and protected with TLS.
• Egress to external services is documented where the threat model requires it.

5. Secrets and configuration

• Secrets are not committed in plaintext to Git. Use an approved encrypted or external secret delivery mechanism.
• Kubernetes Secret encryption at rest is understood for the cluster type. Managed-service defaults and customer-managed key options are documented.
• Rotation and revocation are tested for material credentials.
• Configuration and secret changes are observable and follow the same review discipline as application changes.

6. Supply chain and admission

• Production images use immutable references where practical.
• Images and dependencies are scanned according to a documented vulnerability policy. Avoid pretending “zero CVEs” is a permanent state.
• Build provenance, signing or attestations are used where the threat model requires them.
• Admission policy blocks the classes of configuration your organization has explicitly prohibited.

7. Observability and SLOs

• Metrics, logs and traces are retained long enough to investigate material incidents.
• Alerts map to user impact or actionable platform conditions. Avoid paging on every resource fluctuation.
• SLOs and error-budget policy exist for important services where that operating model is appropriate.
• Capacity and saturation signals include Pods, nodes, storage, queues and external dependencies.

8. Backup and recovery

• Stateful data has a documented backup owner, retention policy and restore procedure.
• Snapshots or backups are restored in a disposable or recovery environment on a defined cadence.
• Control-plane recovery responsibility is explicit. Managed Kubernetes and self-managed clusters have different boundaries.
• RTO/RPO targets are tied to actual recovery tests, not only backup-job success.

9. Change and GitOps controls

• Desired state changes are reviewed and traceable.
• GitOps reconciliation behavior, pruning, self-heal and emergency overrides are documented.
• Production promotion records the artifact and configuration revision that was approved.
• Rollback or forward-fix decisions account for data/schema compatibility.

10. Operational ownership

• Every critical service has an accountable owner and escalation path.
• Runbooks cover the high-value failure modes the on-call team can actually act on.
• Incident reviews create measurable follow-up work and later verify whether the control helped.
• Platform upgrades, node maintenance and disaster-recovery rehearsals have owners and evidence.

How to use the checklist

Pick one environment and one service. Mark each item as proven, partially proven, not proven, not applicable, or intentionally accepted risk. Attach the evidence or the location of the evidence. Then convert the highest-risk gaps into an owned backlog with validation criteria.

That produces a more useful production-readiness review than a green checkbox with no evidence behind it.