How one enterprise built a Kubernetes control plane for Europe

Key Takeaways

• Kubernetes Control Plane methodology unifies cloud orchestration across providers, reducing toolchain complexity
• Inner-source collaboration and monthly tech talks drove adoption across teams with varying Kubernetes experience
• OpenControlPlane lets platform teams pre-configure operators so developers skip the setup burden

At KubeCon Europe, Maximilian Techritz and Johannes Ott explained how their enterprise replaced a sprawl of pipelines, CLIs, and ticket-based workflows with a single Kubernetes control plane that manages databases, secrets, and cloud resources across GCP, AWS, and Azure. The approach cut operational overhead for engineers and created a reusable platform other teams could adopt.

The talk resonated because it addressed a pain point most large organizations share: modern deployments involve too many tools, each with its own lifecycle. Rolling out a new version means verifying nothing breaks across that entire chain. That burden pulls engineers away from actual development work.

Why another tool wasn't the answer

Techritz made the point directly: building yet another internal tool would only add to the problem. Instead, the team surveyed what already existed in the open source ecosystem. The Kubernetes resource model offered a declarative way to describe desired state, and a growing set of projects extended that model to external cloud resources.

Crossplane handles databases on GCP, S3 buckets on AWS, and network policies on Azure. External Secrets Operator syncs and rotates credentials. Kyverno enforces company policies. Flux enables GitOps by pulling configuration from git repositories. All these tools share the same look and feel because they plug into the Kubernetes API.

The result: engineers apply a YAML file describing what they want, and controllers running in the cluster reconcile the actual cloud provider APIs. Create, read, update, delete. The complexity is still there, but it's abstracted behind a consistent interface.

OpenControlPlane: pre-configured operators for dev teams

The enterprise built an internal offering called OpenControlPlane. Platform owners define how secrets, databases, and applications should be provisioned. Development teams request a Control Plane instance and get operators pre-installed and pre-configured. They skip the setup entirely.

This model shifts responsibility. Platform teams own the operators and their upgrades. Application teams focus on declaring what resources they need. The separation is clean, and onboarding new teams doesn't require them to become Kubernetes experts first.

Driving adoption through tech talks and inner-source

Introducing a new methodology is the easy part. Getting people to use it is harder. Ott acknowledged that Kubernetes experience varied widely across teams and organizations. Some engineers knew the resource model well; others had never written a custom resource definition.

The team launched a monthly tech talk series. Hybrid events brought people from different corners of the company together to discuss common challenges. Sessions required close to zero prior knowledge and showed how the Control Plane approach could simplify daily work.

From day one, all code was inner-source. Most of it is now open source. Enablement material was collaborative. The goal was to make it easy for anyone to try the platform, give feedback, and contribute improvements.

“Don't highlight differences, embrace similarities, and actively invest in a shared minimum viable solution. Don't shoot for a perfect picture, but create a culture of collectively improving what can be improved.”

— Maximilian Techritz

Techritz recommended finding common pain points, building a proof of concept, and accepting that not every attempt will work. Patience and openness to failure matter. But the key is to keep enabling and educating the people around you.

The European context

The talk's title mentions "European," and that's not just geography. European enterprises face increasing pressure to demonstrate data sovereignty and reduce dependence on US hyperscalers. Private and sovereign clouds are becoming more common. Software no longer ships to a few data centers.

A Kubernetes-based control plane can abstract where resources run. The same YAML that provisions a database on GCP could provision one on a European private cloud, assuming controllers exist for both. That flexibility matters as regulatory requirements evolve.

What this means for platform engineering teams

The presentation validates a pattern that's gaining traction: treat the Kubernetes API as the universal interface for infrastructure, not just containers. Crossplane, the most prominent tool in this space, has seen steady adoption. Alternatives like Pulumi Operator and AWS Controllers for Kubernetes (ACK) offer similar capabilities with different trade-offs.

For teams considering this path, the inner-source and community-building aspects matter as much as the technology. A control plane nobody uses is just another tool in the pile.

Frequently Asked Questions

What is a Kubernetes control plane for cloud orchestration?

It extends the Kubernetes API to manage external cloud resources like databases, storage buckets, and network policies. Engineers apply YAML files describing desired state, and controllers reconcile those resources with cloud provider APIs.

How does Crossplane fit into this approach?

Crossplane is an open source project that adds cloud resource management to Kubernetes. It provides controllers for GCP, AWS, Azure, and other providers, letting teams manage infrastructure through the same interface they use for containers.

What's the difference between inner-source and open source?

Inner-source applies open source development practices within a company. Code is shared across teams, anyone can contribute, and collaboration happens in the open. The code stays inside the company, unlike open source, which is publicly available.

Why do European enterprises care about sovereign cloud?

GDPR and evolving regulations push companies to control where data is stored and processed. Sovereign cloud initiatives like Gaia-X aim to reduce dependence on US hyperscalers and ensure European data stays under European jurisdiction.

Source: InfoQ