Desired State and the Theology of Convergence

Doctrine

Kubernetes is built on a declaration: the desired state of the world is written into the API. The platform’s legitimacy rests on its ability to approach that state over time.

Kubblai doctrine is strict: desired state is not a wish. It is an owned contract with costs, constraints, and enforcement.

Eventual consistency is not an excuse

Eventual consistency means you cannot demand immediate agreement across the system. It does not mean you accept ambiguity forever.

Operators who hide behind ‘eventual’ to justify persistent drift are refusing stewardship.

• Define acceptable convergence windows (time-to-ready, time-to-rollout).
• Treat prolonged drift as incident-worthy, not merely inconvenient.
• Use conditions and SLOs to quantify convergence.

Where desired state lives (and where it leaks)

Desired state is stored in etcd, served by the API server, and interpreted by controllers. But it also leaks into other systems: CI pipelines, registries, secret stores, admission policies, and the operator’s runbooks.

A mature platform treats this as a supply chain of intent.

• Version manifests and policies.
• Control who can write intent (RBAC + review).
• Ensure intent can be audited and reconstructed.

The hard cases: defaults, mutability, and partial ownership

The best failures are explicit. The worst failures are implicit defaults and drifting ownership. Mutating webhooks that rewrite intent without documentation create invisible state.

Kubblai doctrine prefers explicitness over cleverness.

• Prefer declarative defaults via policy tooling you can review.
• Avoid hidden mutation unless it is measured and documented.
• Use server-side apply ownership to formalize authority.

Practical checklist

If you want a platform that converges, you must answer these questions.

• What is the desired state, and where is it defined?
• Which controllers enforce it, and how do they report progress?
• What does ‘converged’ mean operationally (conditions, metrics, SLOs)?
• What are the failure domains and the rollback story?
• What changes are allowed during incident conditions?