1. Start here
1.3 Open standards and portability
OneK8s is one Kubernetes platform, one application contract for every cloud – built on Azure (AKS) first. Applications run in any public cloud without changes to them or to how they are deployed (requirement R16). What is portable is the contract; the platform under it is an AKS platform that uses what Azure manages, because portability is weighed after security, automation, standard offerings, simplicity and cost. Azure (AKS) is the first cloud implemented.
The rule that makes it work: applications, their manifests and the platform’s in-cluster configuration speak only open standards; cloud-specific choices live only in the picture’s two lower layers, the values per cluster being handed to Flux by the IaC.
What is the same in every cloud
| Layer | Open standard / project | In this platform |
|---|---|---|
| Container images | OCI image and distribution specs | Every app is an OCI image; every cloud registry serves the same image |
| Cluster API | Kubernetes, CNCF certified | Manifests use only GA Kubernetes APIs; no cloud CRDs in team repositories |
| Delivery | Flux (CNCF graduated), Kustomize, Helm | The same Git repositories and Kustomizations reconcile every cluster (section 3.3) |
| Ingress | Gateway API, the implementation chosen per cluster | Teams write HTTPRoutes; the Gateway, its listeners and TLS are the platform’s (section 4.1) |
| Secrets | External Secrets Operator | Teams write ExternalSecrets against a SecretStore named key-vault; only the store’s provider is cloud-specific (section 2.5) |
| Identity | OIDC workload identity federation | Pods get cloud tokens through a Kubernetes service account – never stored keys |
| DNS | external-dns | Publishes listener hostnames in the cloud’s DNS – one provider flag |
| Network policy | Kubernetes NetworkPolicy, Cilium |
Deny-by-default between namespaces; egress to named destinations is the cloud’s firewall |
| Workload security | Pod Security Standards, Gatekeeper constraint templates, ValidatingAdmissionPolicy (CEL) |
The rules of section 2.7 are Gatekeeper templates and CEL policies; on AKS the Azure Policy add-on delivers them |
| Telemetry | OpenTelemetry, Prometheus | Apps emit OTLP; the collector’s destination is configuration (section 6.2) |
| Data | PaaS services over open protocols: PostgreSQL, MySQL, Redis, MongoDB, Kafka, the S3 API | An application talks to a data service through its protocol, never a cloud SDK, and uses the common subset of its features (section 3.1, below) |
The reference application of section 0.3 shows it end to end: its manifests contain no Azure name at all.
What stays cloud-specific
| Piece | Where | On Azure |
|---|---|---|
| Tenant, accounts / subscriptions, policy, hub network | The landing zone, out of this design’s scope: Microsoft’s Azure landing zones with the hub-and-spoke of section 1.1 | Azure landing zone accelerator |
| Clusters and what an environment’s clusters share: network, secret store, registry, DNS, global traffic manager | Cluster IaC | Terraform modules per environment and cluster type (section 3.2) |
| The few facts the cluster needs about its cloud: cluster name and exposure, tenant ID, secret store URLs and client IDs per namespace, DNS zones and resource groups, the gateway class per gateway, the registry and image-signing identity | cluster-settings of each cluster, filled in by the IaC |
A ConfigMap per cluster in the platform repository (section 3.3) |
| Providers of a few platform components | Platform repository, per cloud overlay | External Secrets azurekv, external-dns azure, the Gateway API implementation (approuting-istio or traefik-<gateway>) |
| Day-2 tools that read the cloud | The agents’ tools (section 6.1) | Azure tools behind a cloud-neutral tool interface |
| How the admission policies reach the cluster | Cluster IaC (policy assignments) | Azure Policy add-on (Gatekeeper managed by AKS), assigned per environment subscription |
| The egress firewall and its per-application rule files | The hub | Azure Firewall Premium per exposure (section 5.1) |
| Human access to the clusters | Landing zone and cluster IaC | Entra ID groups, PIM, Azure RBAC for Kubernetes |
Data in PaaS services that every cloud offers
Data belongs in managed PaaS services (section 3.1). To stay portable,
an application talks to a data service through its open protocol, never through a cloud SDK, and gets its
endpoint and credentials from a Kubernetes Secret (synced by External Secrets, or – preferably – an identity-based
login with workload identity). The platform offers only services that every major cloud runs as a managed
service with the same wire protocol:
| Service | Protocol / API | Azure | AWS | Google Cloud |
|---|---|---|---|---|
| PostgreSQL | PostgreSQL wire protocol | Azure Database for PostgreSQL – Flexible Server | Amazon RDS for PostgreSQL, Aurora PostgreSQL | Cloud SQL for PostgreSQL, AlloyDB |
| MySQL | MySQL protocol | Azure Database for MySQL – Flexible Server | Amazon RDS for MySQL, Aurora MySQL | Cloud SQL for MySQL |
| Redis / Valkey | RESP (Redis protocol) | Azure Managed Redis | Amazon ElastiCache (Valkey, Redis OSS), MemoryDB | Memorystore for Valkey / Redis |
| MongoDB | MongoDB wire protocol | Azure Cosmos DB for MongoDB (vCore) | Amazon DocumentDB (MongoDB compatible) | Firestore with MongoDB compatibility |
| Kafka | Kafka protocol | Azure Event Hubs (Kafka endpoint) | Amazon MSK | Google Cloud Managed Service for Apache Kafka |
| Object storage | S3 API (on Azure through a gateway) | Azure Blob Storage | Amazon S3 | Cloud Storage (S3-compatible XML API) |
| Secrets | External Secrets provider | Azure Key Vault | AWS Secrets Manager | Google Secret Manager |
| Container registry | OCI distribution | Azure Container Registry | Amazon ECR | Artifact Registry |
Every cloud’s offer is compatible, not identical: version support, extensions (for example PostgreSQL extensions), MongoDB feature coverage and Redis modules differ. So:
- An application uses the common subset: core PostgreSQL features and widely available extensions, standard Redis commands without modules, the MongoDB features DocumentDB, Cosmos DB and Firestore all support. A team that needs more records it as an exception in its onboarding, because that exception pins it to one cloud.
- Vendor-neutral managed offers that run in all three clouds – MongoDB Atlas, Confluent Cloud, Aiven, Redis Cloud – are acceptable alternatives where the cloud-native service falls short, ordered through the marketplace so billing and networking (Private Link / PrivateLink / Private Service Connect) stay in the cloud.
- Services without a cross-cloud equivalent with the same protocol (for example Cosmos DB’s NoSQL API, DynamoDB, Spanner, Service Bus) are not offered as platform services; where the Azure sections name them, they describe the Azure implementation of a documented cloud-pinning exception.