The Origin Story Everyone Knows

Google built Borg, its internal container orchestration system, in the early 2000s. A decade later, a team at Google distilled those ideas into an open-source project called Kubernetes, donated it to the newly formed Cloud Native Computing Foundation, and stepped back from sole ownership. That was 2014. In the eleven years since, Kubernetes has become the operating system of the cloud, and the story of its origin has become a kind of sovereignty anxiety for European organisations wondering whether their infrastructure depends on American goodwill.

It does not. But understanding why requires looking past the creation myth and into how Kubernetes actually works as a project, a community, and an institution.

Governance That Outgrew Its Creator

The CNCF is a project of the Linux Foundation. Its governing board includes representatives from companies across continents: European firms like SAP, Bosch, and Siemens sit alongside American, Chinese, and Japanese members. Technical decisions are made by Special Interest Groups whose membership is open and whose leadership is elected by contributors, not appointed by any single company.

Google retains influence in this structure. Its engineers contribute heavily and its cloud platform benefits from Kubernetes adoption. But influence is not control. The Kubernetes release process, the API review process, and the security response process are all community-governed. No single company can block a release, reject a feature, or suppress a vulnerability disclosure.

This governance model is not accidental. It was designed explicitly to prevent the scenario that European policymakers worry about: a single company holding critical infrastructure hostage. The CNCF's charter, its intellectual property framework, and its trademark policies all exist to make Kubernetes ungovernable by any one entity. That is the entire point.

The API Is the Sovereignty Layer

Kubernetes' most important contribution to European digital sovereignty is not the software itself. It is the API.

The Kubernetes API is a standard interface for describing computational workloads, storage, networking, and access control. Every conformant Kubernetes distribution implements this API. A deployment manifest that runs on Google's GKE runs identically on OVHcloud's managed Kubernetes, on Scaleway's Kapsule, on a self-managed cluster in a Frankfurt data centre, or on a k3s installation on a Raspberry Pi in someone's office.

This is portability at the infrastructure layer, something the industry has promised and failed to deliver for decades. VMware promised it and then charged licensing fees that made migration economically irrational. OpenStack promised it and then fractured into incompatible distributions. Kubernetes actually delivered it, not because of altruism, but because the API conformance tests are rigorous and the ecosystem punishes non-compliance.

For European organisations this means something concrete: choosing Kubernetes does not mean choosing Google. It means choosing an interface that European providers implement, European engineers operate, and European companies extend through operators and custom resources. The workloads are portable. The skills are portable. The operational tooling is portable. Moving from a US cloud provider to a European one is a migration project, not a rewrite.

European Kubernetes Is Already Real

The narrative that Kubernetes is American infrastructure does not survive contact with the European cloud landscape.

OVHcloud runs managed Kubernetes from data centres in France, Germany, Poland, and the UK. Scaleway operates Kapsule from Paris. IONOS provides Kubernetes from German infrastructure. Exoscale runs it from Switzerland. Hetzner, already popular for its pricing, offers Kubernetes from Finnish and German locations. These are not toy deployments or proofs of concept. They are production platforms serving European companies that have made deliberate sovereignty choices.

Beyond managed offerings, European organisations run self-managed Kubernetes at significant scale. Public sector institutions, financial services companies, and healthcare providers operate clusters on European soil, managed by European teams, subject exclusively to European law. The software they run was contributed to by Google engineers, just as it was contributed to by engineers at Red Hat, VMware, Microsoft, independent contributors, and dozens of European companies whose names rarely appear in the origin story.

What "European" Software Actually Looks Like

There is a persistent assumption in sovereignty discussions that European software must be written by Europeans, governed by Europeans, and hosted by Europeans to qualify as sovereign. This assumption is both impractical and philosophically incoherent.

The internet protocols that European networks depend on were designed at American universities. The TLS encryption that protects European banking was standardised by the IETF, a US-incorporated organisation. The DNS system that resolves European domain names was invented by American researchers. None of this makes European internet infrastructure "American." Infrastructure becomes sovereign when the people operating it have full control over its configuration, its data, and its availability, regardless of who wrote the first line of code.

Kubernetes fits this model precisely. European organisations deploying Kubernetes on European infrastructure, managed by European engineers, storing European data in European jurisdictions, are running sovereign infrastructure. The fact that the first commit came from a Google office in Mountain View is historically interesting and strategically irrelevant.

The Real Dependency to Watch

If Kubernetes itself is not a sovereignty risk, what is?

The answer is managed Kubernetes from hyperscalers. GKE, EKS, and AKS bundle Kubernetes with proprietary integrations: load balancers, identity systems, logging pipelines, and monitoring stacks that create quiet, accumulating lock-in. The Kubernetes API is portable but the ecosystem around a hyperscaler's managed offering is deliberately not. Moving off GKE means replacing Google's proprietary ingress controller, its workload identity federation, its operations suite, and dozens of small integrations that seemed convenient when they were adopted.

This is where European sovereignty work should focus. Not on whether Kubernetes was created in America, but on whether the deployment is entangled with a specific American cloud provider's proprietary extensions. Building on the Kubernetes API with portable, open-source components, Gateway API instead of proprietary ingress, Prometheus instead of proprietary monitoring, Flux or ArgoCD instead of proprietary deployment pipelines, is what makes infrastructure genuinely sovereign.

Building on Solid Ground

Kubernetes is the closest thing the industry has to neutral infrastructure. Its governance is multi-national, its API is a genuine standard, its implementations span continents and providers, and its license makes restriction impossible. Europe should engage with it not as a foreign dependency to be tolerated, but as shared infrastructure to be shaped.

Contribute to the project. Run European Kubernetes distributions. Build operators that encode European operational practices. Participate in SIG governance. Maintain the European provider ecosystem that makes Kubernetes portable in practice, not just in theory.

The foundation is solid. The question is not whether to build on it, but how ambitiously.

#kubernetes #freedom-to-operate #european-cloud #open-source-governance #vendor-lock-in