Production Readiness Is Easier to Inspect Than to Debate

Teams often describe a Kubernetes environment as "production ready" without agreeing on what that means.

That makes readiness surprisingly difficult to discuss.

One person is thinking about redundancy.

Another is thinking about security.

Another is thinking about observability.

Another is simply thinking, "the application is running in the production cluster."

A checklist is useful because it turns the argument into inspection.

Production ready is not a binary feature

Kubernetes itself does not make a workload production ready.

A cluster can be healthy while an application has no tested restore path.

A Deployment can have multiple replicas while all replicas depend on the same failure domain.

A service can have dashboards while nobody knows which alert requires action.

A GitOps controller can report synchronization while the rollback process remains unclear.

So production readiness is better treated as a set of operating conditions than as a label.

Start with failure

One of the fastest ways to test readiness is to stop asking how the happy path works.

Ask what happens when something fails.

For example:

• What happens when a node disappears?
• What happens when a zone becomes unavailable?
• What happens when DNS is unhealthy?
• What happens when the database cannot be reached?
• What happens when a deployment introduces a bad configuration?
• What happens when credentials expire?
• What happens when a persistent volume cannot attach?
• What happens when an operator is unavailable during an incident?

The point is not to predict every possible failure.

The point is to make important failure behavior explicit before production pressure arrives.

A useful inspection model

A production-readiness review can be grouped into several control areas.

Workload resilience

Check whether the workload has meaningful redundancy.

Questions include:

• Are replica counts intentional?
• Are PodDisruptionBudgets appropriate?
• Do topology constraints prevent all replicas from landing in one failure domain?
• Are probes testing meaningful application behavior?
• Does the application tolerate dependency failure?
• Are termination and shutdown behaviors safe?

A three-replica Deployment is not automatically resilient if all three replicas share the same failure path.

Resource behavior

CPU and memory configuration should be deliberate.

Inspect:

• requests
• limits
• observed utilization
• throttling
• OOM events
• autoscaling behavior
• burst requirements

Poorly selected requests can waste capacity.

Poorly selected limits can create instability.

The goal is not to maximize utilization. It is to make resource behavior predictable enough to operate safely.

Deployment safety

A production deployment process should answer:

• How is a change promoted?
• What evidence is required?
• Can the change be rolled back?
• How quickly can rollback happen?
• Are database migrations compatible with rollback?
• Can deployment drift be detected?
• Who owns a failed release?

GitOps can make state traceable, but it does not replace these operating decisions.

Observability

A system is difficult to operate if the team cannot distinguish symptoms from causes.

Readiness includes:

• application metrics
• platform metrics
• logs
• traces where appropriate
• alert routing
• useful dashboards
• service ownership
• dependency visibility

The question is not "Do we have Prometheus?"

The question is "Can an operator use the available evidence to make a correct decision during an incident?"

Recovery

Backup configuration is not the same as recovery capability.

Inspect:

• backup frequency
• restore testing
• recovery point objective
• recovery time objective
• storage dependencies
• database replication
• secret recovery
• external service dependencies
• documented failover behavior

A backup that has never been restored is an assumption.

Security and access

Readiness also includes the controls that limit blast radius.

Examples:

• RBAC
• workload identity
• secret management
• network policy
• image provenance
• admission controls
• Pod Security settings
• privileged workload review
• auditability

The exact controls depend on the environment, but the principle is consistent: production access should be intentional and reviewable.

Ownership and operations

Many production failures are not caused by Kubernetes configuration.

They are caused by ambiguity.

A readiness review should identify:

• service owner
• escalation path
• runbook location
• dependency owner
• deployment owner
• recovery decision-maker
• maintenance expectations
• after-hours responsibility

Technology can automate many operations.

It cannot compensate for unclear ownership.

Make the result scoreable, but do not worship the score

A scored checklist can be useful because it makes gaps visible and allows teams to track progress.

But a score should not become a substitute for engineering judgment.

Some controls are more important than others.

A missing label is not equivalent to an untested database restore.

A useful readiness system therefore combines:

• control status
• evidence
• severity
• ownership
• remediation state

The value is not the number itself.

The value is that the team can see what is missing and why it matters.

Readiness should be repeatable

A one-time production review ages quickly.

Clusters change.

Dependencies change.

Applications change.

Teams change.

A stronger model treats readiness as a repeatable inspection that can be revisited before major releases, after architecture changes and periodically for critical services.

That is where automation helps.

Controls that can be checked mechanically should be automated.

Controls that require judgment should remain explicit human review points.

The deeper lesson

Production readiness is easier to inspect than to debate.

Turn the claim into observable conditions.

Collect evidence.

Record gaps.

Assign ownership.

Retest after remediation.

Tayoca's Kubernetes Production Readiness package was built around this discipline, with a 150-control dataset, scored tracker and supporting release artefacts.

The goal is not to turn engineering into paperwork.

The goal is to make operational confidence traceable.