Universal on K8s is a deployment pattern that runs a mesh control plane on Kubernetes while using an external Postgres datastore instead of Kubernetes CRDs for configuration storage. The pattern is designed to improve regional resilience and support broader high availability objectives across multiple regions.
What Universal on K8s Is Solving
Universal on K8s is a deployment pattern for mesh control planes that changes the storage and recovery model. Instead of tying configuration state to Kubernetes CRDs alone, it places durable state in an external Postgres datastore so the control plane can better survive regional disruption.
The key idea is separation of concerns: Kubernetes still hosts the runtime, but Postgres becomes the system of record for configuration and orchestration data. That architecture is chosen when regional resilience, faster recovery, or multi-region continuity matter more than keeping all state inside the cluster boundary.
How the Pattern Changes Control Plane Architecture
In a conventional Kubernetes-native design, CRDs are often the natural place to store desired state because they fit the cluster control model. Universal on K8s changes that assumption by moving important configuration persistence out of the cluster, which reduces dependence on a single regional Kubernetes control plane and can simplify recovery after a cluster or region failure.
This is not just a storage substitution. It changes the failure domain, because the control plane now depends on both Kubernetes for execution and Postgres for state durability. If those layers are not designed and operated carefully, the deployment can become harder to reason about than a fully in-cluster configuration model.
Why External Postgres Matters for Resilience
Externalizing state to Postgres is valuable when the objective is to preserve service continuity during regional outages, control plane restarts, or cluster replacement events. It gives the deployment a stateful anchor that can be replicated, backed up, and restored independently of the Kubernetes cluster that is running the workload.
That resilience benefit comes with an architectural trade-off: you are moving trust and availability requirements onto the database layer. The pattern only delivers its intended value if the Postgres tier itself is highly available, protected against split-brain and replication drift, and accessible from the regions that may need it during failover.
Where Universal on K8s Fits in Platform Design
Universal on K8s is best understood as a platform availability pattern, not a general Kubernetes best practice. It is used when a control plane needs to behave more like a distributed service than a purely cluster-local component, especially in environments where a single regional outage should not force a full reinitialisation of desired state.
For teams evaluating the pattern, the practical question is whether the extra operational complexity of an external datastore is justified by the recovery objectives. The answer is usually strongest in multi-region platforms, regulated environments, or systems where configuration loss or delayed restoration would create outsized operational impact.
Risk and Threat Considerations
Externalising control plane state improves resilience, but it also expands the attack and failure surface. The main risks are database compromise, misconfiguration, replication failure, or loss of connectivity between Kubernetes and Postgres, any of which can affect availability, integrity, or recovery speed.
Failure mechanism: If the datastore becomes unavailable, inconsistent, or exposed to unauthorized access, the control plane may lose its authoritative configuration source or recover with stale state.
Impact: That can lead to degraded service, incorrect control-plane behaviour, prolonged failover, or in the worst case a regional recovery process that restores infrastructure but not the intended configuration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IR-04 — Mitigation | External state and regional failover are resilience concerns for this control-plane pattern. |
| PR.DS-01 — Data-at-rest is protected | The Postgres datastore becomes authoritative configuration state that must be protected. | |
| Recommendation — Design the datastore and control plane to recover cleanly from regional outages and dependency loss. Protect stored control-plane state in Postgres with strong data-at-rest safeguards. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | The pattern is chosen to improve continuity and recovery across regions. |
| SC-28 — Protection of Information at Rest | Configuration persisted outside Kubernetes must remain protected while stored in Postgres. | |
| Recommendation — Document and test regional recovery procedures for the control plane and its database dependency. Encrypt and protect control-plane data stored in the external database. | ||
| ISO/IEC 27001:2022 | A.8.14 — Redundancy of information processing facilities | Multi-region availability depends on redundant processing and storage capabilities. |
| Recommendation — Build redundant control-plane and datastore capacity to sustain regional failure. | ||
Practitioner Guidance
Why practitioners should care: This pattern is only as strong as the database design behind it. Treat Postgres as part of the control plane, not as an incidental dependency, because its durability, access control, and replication behaviour directly shape recovery outcomes.
What to watch for: Validate that backup, restore, replication, and connectivity assumptions are tested under regional-failure conditions, not just in steady state. Universal on K8s succeeds when the state layer is engineered for the same availability objective as the runtime layer.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
