Kubernetes production readiness for 2026

1. Scope and ownership

• The production boundary is explicit. Clusters, accounts, regions, namespaces, external dependencies and data stores in scope are documented.
• Every critical service has an accountable owner. On-call, escalation, security and business ownership are known before an incident.
• Risk acceptance has an owner and expiry. Exceptions are not permanent undocumented configuration.

2. Platform lifecycle and versioning

• Kubernetes and managed-service versions are within supported lifecycle windows.
• Upgrade sequencing is rehearsed. APIs, CRDs, controllers, admission policies and workloads are checked for compatibility before upgrade.
• Node images and runtime components have a patching path. Rollback or replacement behavior is understood.

3. Workload safety

• Requests and limits come from observed behavior and service objectives.
• Startup, readiness and liveness probes represent distinct failure modes.
• Rollout settings, disruption budgets and topology rules reflect the required availability model.
• Stateful workloads document storage class, backup ownership, restore procedure and failure-domain assumptions.

4. Security and admission

• Pod Security Admission or equivalent policy is configured deliberately. Exceptions are documented and reviewed.
• Privilege escalation, host access and unnecessary Linux capabilities are restricted.
• Admission policy blocks prohibited configuration classes. Policy behavior is tested before production enforcement.
• Runtime detection complements preventive controls where the threat model requires it.

5. Identity and RBAC

• Human cluster access uses centrally managed or short-lived identity where supported.
• Workloads use named ServiceAccounts and workload identity instead of long-lived cloud credentials.
• RBAC is reviewed for broad verbs, Secret reads, impersonation and cluster-scoped mutation.
• Break-glass access is explicit, time-bound and auditable.

6. Network boundaries

• The CNI is confirmed to enforce the network controls the team relies on.
• Default-deny policy is used where isolation requirements justify it, with DNS and application flows explicitly allowed.
• Ingress or Gateway exposure is intentional, TLS-protected and observable.
• Egress and external dependency paths are documented for sensitive workloads.

7. Secrets and encryption

• Secrets are not committed to Git in plaintext.
• Secret delivery, rotation and revocation are tested for material credentials.
• Encryption-at-rest responsibility is documented for Kubernetes state and application data.
• Key ownership and recovery are understood when customer-managed encryption is used.

8. Supply chain

• Production artifacts are traceable to a build and source revision.
• Immutable image references are used where practical.
• Vulnerability policy defines severity, exploitability, exceptions and remediation expectations.
• SBOM, provenance, signing or attestations are used when the risk model requires them.

9. Observability and service objectives

• Metrics, logs and traces cover the important user path and platform dependencies.
• Alerts represent actionable conditions rather than every resource fluctuation.
• SLOs and error-budget policy are defined for services where that model is appropriate.
• Capacity, saturation, queue depth and dependency health can be inspected during an incident.

10. Backup and recovery

• Backups have owners, retention, encryption and restore procedures.
• Restore tests prove recovery rather than only backup-job completion.
• RTO and RPO targets are based on rehearsed recovery behavior.
• Control-plane recovery boundaries are explicit for managed versus self-managed Kubernetes.

11. Change and GitOps controls

• Desired-state changes are reviewed, attributable and reproducible.
• Reconciliation, pruning, self-heal and emergency override behavior are documented.
• Production promotion records the exact artifact and configuration revision.
• Rollback and forward-fix decisions account for database, schema and external-state compatibility.

12. Evidence and sign-off

• Each material control points to current evidence. Configuration alone is not proof that the control is functioning.
• Exceptions state owner, reason, compensating control and review date.
• Recovery, incident, upgrade and maintenance exercises retain results and follow-up work.
• Production sign-off records the reviewers, evidence boundary, accepted risks and next review point.

A practical way to use this review

Choose one production environment and one critical service. For every item, record one of five states: proven, partially proven, not proven, not applicable, or accepted risk. Link the supporting evidence and give every gap an owner. Then prioritize work by business impact, exploitability, recovery risk and operational cost—not by how easy the checkbox is to turn green.

A useful readiness review should leave the team with a smaller number of clearly owned decisions and a stronger evidence trail, not a larger spreadsheet full of ambiguous green cells.