kcp.io – Blog

Blog: Get Ready for kcp ContribFest at KubeCon Europe 2026!

Tue, 17 Mar 2026 00:00:00 +0000

Pack your laptop and mark your calendar! kcp is hosting a ContribFest session at KubeCon + CloudNativeCon Europe 2026 in Amsterdam on Thursday, March 26, from 11:00 to 12:15 CET in room G106. Read on to get yourself prepared beforehand and make the most out of the session!

What is ContribFest?

ContribFest is a track at KubeCon where CNCF projects host hands-on sessions working with their communities on real contributions. You don’t need to be an existing contributor — new community members are especially encouraged to join!

Our session, kcp: From Zero To Your First Pull Request, is a 75-minute guided workshop where you’ll explore the kcp architecture, set up a local dev environment, and submit your very first pull request — all with personal guidance from maintainers. Just bring some familiarity with Kubernetes and general development practices.

What to prepare before you get there

To maximize your time during the session, we recommend completing these preparation steps beforehand.

1. Learn about kcp

While smaller issues don’t require a deep knowledge of kcp, knowing the rough terminology, concepts, and architecture is a good starting point:

2. Fork the repos

You’ll have the option to contribute to several kcp ecosystem repositories. To get started, follow the GitHub “Forking a repository” guide and fork the ones you’re interested in:

kcp — the core project
api-syncagent — synchronization agent for APIs
multicluster-provider — multi-cluster provider for controller-runtime
kcp-operator — Kubernetes operator for deploying kcp
helm-charts — Helm charts for kcp

3. Set up your local environment

kcp is written in Go — you’ll need a working Go toolchain installed. We have a few ways to run a local environment:

Single shard (recommended for most development): In most cases it is enough to go run the kcp binary to run a single root shard with no proxy. Follow the quickstart guide to get started.
Tilt multi-shard with front proxy: For testing cross-shard features, you can use the Tilt-based multi-shard setup.
Sharded test server: Another option for sharded testing is the sharded-test-server.

The components don’t necessarily require a running kcp instance to develop — some have enough options for unit and e2e tests that usually include running kcp in some form.

4. Test your setup

Let’s do a quick test to confirm everything is working:

Navigate to your cloned fork of the kcp repo
From the root, run make build
Then start a local kcp instance: ./bin/kcp start
If kcp starts and you can connect with kubectl --kubeconfig .kcp/admin.kubeconfig, you’re all set!

5. Find something to work on

We label issues that should be a good entry point for new contributors as “good first issue”. Browse the curated lists below to find something that interests you — and feel free to claim one ahead of time! Of course, if you feel brave, you can also tackle other issues.

Bonus: Check out the contribution guides

Take some time to read through the contribution guides to get familiar with the overall process:

kcp Contributing Guide

Getting help

Development topics are discussed mostly in our channel #kcp-dev on the Kubernetes Slack. If you don’t have a Kubernetes Slack account yet, get your invite here: https://slack.kubernetes.io/

Don’t hesitate to reach out before, during, or after the session — we’re always happy to see new contributors to kcp!

👋 See you in Amsterdam!

On behalf of the ContribFest co-hosts, thanks for following along! We look forward to meeting you in Amsterdam and working together on your first (or next!) kcp contribution. Make sure to say hello!

Blog: Our Schedule at KubeCon + CloudNativeCon Europe 2026

Mon, 16 Mar 2026 00:00:00 +0000

KubeCon + CloudNativeCon Europe 2026 is just a few days away! The major European cloud native conference kicks off on Monday, March 23rd in Amsterdam, Netherlands, and the kcp project will be there with exciting content and activities on every day!

From talks to lightning sessions, there are plenty of opportunities to learn about kcp and connect with our maintainers. You can meet us at the Project Pavilion on Wednesday, March 25, from 14:00 to 17:00 CET at kiosk 18B — feel free to drop by to chat about kcp or just say hi. 👋

We’re also running a hands-on Contribfest on Thursday, March 26, from 11:00 to 12:15 CET in room G106, where you can explore the kcp architecture, set up a local dev environment, and submit your very first pull request — all with personal guidance from maintainers. No deep prior experience required, just some familiarity with Kubernetes and general development practices. Don’t forget to bring your laptop!

Here’s a full overview of all kcp activities at this year’s KubeCon and surrounding events:

Date & Time	Title	Speakers	Location	Link
Sat, Mar 21, 2026 17:45-18:15 CET	Cloud Native Rejekts: Achieving Platform Engineering Multi-Tenancy with kcp and Crossplane	Simon Bein, Lovro Sviben	Miro HQ Room 2	link
Mon, Mar 23, 2026 13:40-13:45 CET	Project Lightning Talk: kcp: Scaling The Kubernetes Control Plane For The Multi-Cluster Era	Jan Willies	Elicium 2	link
Tue, Mar 24, 2026 17:00-17:30 CET	When Multitenancy Goes Wrong: A Deep Dive Into Kcp’s First CVE	Marko Mudrinić, Marvin Beckers	Elicium 2	link
Wed, Mar 25, 2026 13:00-13:10 CET	CNCF Platform Engineering Community: Why We Need a Universal Platform Engineering API-Layer and How kcp Unlocks It	Simon Bein	P-17B	link
Wed, Mar 25, 2026 14:00-17:00 CET	kcp Project Pavilion	kcp contributors	P-18B	link
Wed, Mar 25, 2026 14:15-14:45 CET	kcp Ecosystem: Platform Mesh: Breaking API Lock-In for True Multi-Cloud Service Portability	Mirza Kopic, Mangirdas Judeikis	Hall 8, Room G	link
Thu, Mar 26, 2026 11:00-12:15 CET	Contribfest: kcp: From Zero To Your First Pull Request	Karol Szwaj, Nelo-T. Wallus	G106	link

We hope that you’re as thrilled for KubeCon as we are! See you there!

Blog: Our Schedule at KubeCon + CloudNativeCon Europe 2025

Thu, 27 Mar 2025 00:00:00 +0000

KubeCon + CloudNativeCon Europe 2025 is just a few days away! The major European cloud native conference is set to kick off on Tuesday, April 1 in London, England!

The kcp project has prepared a lot of exiciting content and activites for this year’s KubeCon EU. Just like at KubeCon NA last year, you’ll have a chance to meet our maintainers at the Project Pavilion on Wednesday, April 2, from 15:30 to 19:45 BST at the Kiosk 5A. Feel free to drop by and talk anything about kcp or just say hi. 👋

We’re very excited to present our first hands-on workshop where attendees will have a chance to get familiar with multi-tenant Kubernetes APIs and controllers with kcp, while being guided by our maintainers and contributors. Join Robert Vasek, Nabarun Pal, Varsha Narsing, Marko Mudrinić, and Mangirdas Judeikis, on Wednesday, April 2, at 11:15 BST for tons of learning and fun!

But that’s not all, we’re having two more kcp talks at KubeCon:

Thrusday, April 3, 11:00 - 11:30 BST: Extending Kubernetes Resource Model (KRM) Beyond Kubernetes Workloads - Mangirdas Judeikis, Cast AI & Nabarun Pal, Independent
Thrusday, April 3, 15:00 - 15:30 BST: Dynamic Multi-Cluster Controllers With Controller-runtime - Marvin Beckers, Kubermatic & Stefan Schimanski, NVIDIA

We hope that you’re as thrilled for KubeCon as we are! See you there!

Blog: Our Schedule at KubeCon + CloudNativeCon North America 2024

Sun, 20 Oct 2024 00:00:00 +0000

KubeCon + CloudNativeCon North America 2024 will kick off in Salt Lake City on November 12, in less than a month.

After a very successful KubeCon Europe in Paris, we’re happy to share that kcp maintainers will also be around in Salt Lake City. This time, kcp will also be at the Project Pavilion and maintainers will be around at a project kiosk on Wednesday, November 13 from 3:15pm to 8:00pm. Feel free to drop by to chat about kcp, ask questions or just say hi!

We are also excited to share the following sessions involving kcp. This time, we are happy to see talks coming from the wider community and utilizing kcp for their use cases.

Nov 13, 3:25pm: Deep Dive Into Generic Control Planes and kcp at KubeCon + CloudNativeCon – Stefan Schimanski (Upbound), Mangirdas Judeikis (Cast AI)
Nov 15, 4:55pm: Best of Both Worlds: Integrating Slurm with Kubernetes in a Kubernetes Native Way at KubeCon + CloudNativeCon – Eduardo Arango Gutierrez (NVIDIA), Angel Beltre (Sandia National Laboratories)

A special shoutout goes to the talk Kubernetes Workspaces: Enhancing Multi-Tenancy with Intelligent Apiserver Proxying by James Munnelly and Andrea Tosatto (both Apple), which is not presenting kcp but leverages some of the language and concepts that originated in the kcp project. We’re excited to see what they’ve built!

Blog: Our Schedule at KubeCon + CloudNativeCon Europe 2024

Wed, 06 Mar 2024 00:00:00 +0000

KubeCon + CloudNativeCon Europe 2024 is around the corner and we can’t wait to see you in Paris!

We are happy to tell you that kcp and several of its maintainers will be present and hope to chat a lot about the project. This will be kcp’s first KubeCon + CloudNativeCon as CNCF Sandbox project and we couldn’t be more excited about joining KubeCon + CloudNativeCon as a CNCF project.

Currently, the following sessions will cover kcp (schedule might be subject to change):

Mar 18, 5:40pm: Unlocking New Possibilities: Bridging Linux and Kubernetes at Cloud Native Rejekts – Mangirdas Judeikis
Mar 19, 11:05am: Building a Platform Engineering API Layer with kcp at CNCF-hosted co-located event Platform Engineering Day – Marvin Beckers
Mar 19, 3:00pm: Kubernetes-style APIs for SaaS-like Control Planes with kcp (Project Lightning Talk) at KubeCon + CloudNativeCon – Mangirdas Judeikis, Marvin Beckers
Mar 21, 3:25pm: Why Kubernetes Is Inappropriate for Platforms, and How to Make It Better. at KubeCon + CloudNativeCon – Stefan Schimanski, Mangirdas Judeikis, Sebastian Scheele

We hope to meet you all in Paris and discuss building the control plane of the future!

Blog: Joining the CNCF Sandbox

Wed, 24 Jan 2024 00:00:00 +0000

With the new year still fresh, we have big news to share. We are thrilled to announce that kcp has joined the CNCF and completed onboarding as a CNCF Sandbox project. A huge thanks to the sponsors of our application. It is an honor to be among the greatest open source projects that our ecosystem has to offer!

If you haven’t checked in with the kcp project in a while, let us bring you up to speed on the last few months. In April this year, Red Hat announced that kcp won’t have its immediate focus and extended an invitation to the community to take over the project.

A group of committed organizations and individuals decided to respond to the call for action and established a new project governance and bootstrapped a new list of maintainers to lead kcp as a community project. Since then, more people have joined the list of maintainers to drive the kcp project forward. We relaunched kcp.io in a new design recently to commemorate the “new” kcp project.

From the inception of the new project governance, it was clear that kcp does not exist in a vacuum. It is a citizen of the Kubernetes ecosystem and as such, joining the CNCF to formalize that citizenship was the obvious and natural road to take. Eventually, after evaluating our application, the Technical Oversight Committee (TOC) decided to accept us into the CNCF Sandbox program.

Obviously, we are beyond excited about this decision and about the amazing community of open source projects we are joining. It is incredibly humbling to become a part of the CNCF community - in a way, it feels like coming home.

We have big plans for 2024, and for the time beyond. Adding functionality vital to the mission of kcp, improving the experience of running kcp on top of Kubernetes, spreading the word about building scalable control planes for SaaS-like services, growing the community - You name it. We hope to see you on our bi-weekly community meetings or on our GitHub repositories soon!

Blog: Launch of kcp.io – Talk to us at KubeCon!

Thu, 20 Oct 2022 00:00:00 +0000

Welcome to the website of the kcp project. We have come a long way from the first commit to the kcp project on July 7 2020, to the project we see today. We started with an experiment to add logical clusters to kube-apiserver, and we’ve evolved into a tool that enables large scale multi-tenant services based on the Kubernetes API.

Today we are proud to announce the kcp website:

We love collaboration. Together, we can change the world.

Join us at the KubeCon NA 2022 in Detroit. A number of people from the community will be there and we are happy to hear feedback or the next exciting idea kcp will enable. Here is a list of where you can find us:

Oct 25, 11am OpenShift Commons: The Future of Kubernetes is Control Planes – Andy Goldstein, Stefan Schimanski, Tushar Katarki
Oct 25, 1pm OpenShift Commons: Multicluster OpenShift Community Meet-Up – Andy Goldstein, Stefan Schimanski, Alberto Garcia Lamela, Tushar Katarki
Oct 26, 5:25pm KubeCon Talk: KCP towards 1,000,000 clusters, Stefan Schimanski
Oct 26, 5:25pm KubeCon Talk: Like Peas And Carrots: Argo CD And Crossplane For Infrastructure Management – Viktor Farcic, Jesse Suen
Oct 27, 11:55am KubeCon Talk: Towards Something Better Than CRDs In a Post-Operator World – Stefan Schimanski
Oct 27, 2:30pm Virtual KubeCon Red Hat Booth: Virtual Office Hours: KCP – Andy Goldstein, Nolan Brubaker, Steve Kuznetsov – Login to the KubeCon virtual platform and navigate to the Red Hat booth to join
Oct 28, 11am KubeCon Talk: Crossplane Intro And Deep Dive - The Cloud Native Control Plane Framework – Jared Watts, Matthias Luebken & Nic Cope, Upbound; Bob Haddleton, Nokia

For many more details about what kcp is and how we arrived where we are today, please enjoy reading the second blog post: kcp: the journey.

Blog: kcp - the journey

Wed, 19 Oct 2022 00:00:00 +0000

One and a half years ago at KubeCon 2021 in Amsterdam, Clayton Coleman sent us on a journey:

What if we took Kubernetes – as we had created it as a community over 7 years ago – and removed all Pod-related resources and everything that is not clearly of generic use, resulting in a generic control plane?

What if we further split clusters hosting many applications into very small logical clusters with one application each, and each application owner just chooses and picks the additional APIs necessary for that application? And what if a logical cluster is cheap, super cheap, and super quick to create, as cheap and quick as a namespace creation?

These are two foundational and yet technically small changes in the architecture of Kubernetes. Today everybody takes for granted that Kubernetes is tightly coupled with a large number of built-in APIs, the API monolith we all know, and that clusters must be shared because of the large overhead of creating and running one more cluster, both in resource cost and management overhead.

While prototyping the system over the past 15 months, we quickly realized that the small size but the large number of logical clusters opens up a green field for innovation: a logical cluster alone, even if we re-add the well-known workload APIs, is not a very exciting idea. Projects in the ecosystem like k3s, vcluster or service offerings like Civo have pioneered small, personal clusters for years. With logical clusters we are trying to go farther by reducing the control plane cost by another magnitude or two, giving these companies a tool for optimizing their services even more. But the real value and the actual innovation happens when re-connecting those new logical clusters into something bigger.

This “something bigger” can have different shapes. Let’s look at the use-cases we encountered.

Hierarchies and other Relationships

If we have hundreds or thousands of clusters as one company, we will start thinking about how to organize them. One model we explored early on is a logical cluster hierarchy, like a traditional file system with a directory tree, logical clusters organized in a tree. We call the logical clusters here workspaces, and workspaces are nested, as file system directories are nested.

Similarly to file systems, the workspaces have no shared logic, other than the fact that workspace access somehow depends on access to a parent workspace. As outlined in Clayton’s original prototype, every workspace, nested or not, has an independent set of resources.

Another option for logical cluster organization could be that established by Google with their Docs office suite, where a folder structure exists, but most users actually just share links to documents or invite collaborators to existing documents. With that model, documents are not much inter-connected in reality in an organized way, but rather form an organic web with references by global ID (URL). Even such a model is totally compatible with the logical cluster concept.

With thousands of workspaces in a platform, each starting out with only a small set of generic APIs that are not very useful on their own, we realized that we need an easy mechanism for users to choose additional APIs and add them to their workspace.

CustomResourceDefinitions are provided by Kubernetes and kcp supports them as well. We knew that managing CRDs can already become a nightmare with a few handful of Kubernetes clusters. With a number in the thousands that’s likely not a good approach. Hence, we started wondering whether there aren’t ways to share resources between workspaces. This sounds a lot like forcing workspaces and their owners to agree on APIs, i.e. the big inconvenience of big clusters that all users must agree on the operator versions or other extensions to the cluster.

So what if we want shared APIs, but give a user still the choice which API version or service version to choose? What we have implemented is a model where APIs are published through an APIExport by a service provider in one workspace, and consumers may add the exported APIs to their workspaces through the creation of APIBindings pointing to the export.

Some readers might be scared: “the kcp project is building proprietary APIs here and diverge from Kube”. We can assure: everything we are building with APIExports and APIBindings is heavily based on CRDs and all its technology and ecosystem around. APIExports and APIBindings are a higher level API that eventually, further down, creates (technically invisible) CRDs. All the features and the tooling of CRDs can be used. Existing CRDs can be exposed with APIExports.

We like to say that Kubernetes is at the core of kcp. And this is the perfect example: APIExport/APIBinding-based resources are served through apiextension-apiserver and with that are 100% compatible to Kubernetes API conventions. That’s one of the rules we set in stone in the project:

A workspace is Kubernetes. No compromises.

with the nuance that we intentionally disable workload APIs to start fresh as a generic control plane.

Towards a new Extension Model for Service Providers

We have mentioned one subtle, innocently looking detail where APIExports/APIBindings differ from normal CRDs, and this has a giant consequence for the philosophy of how people think of APIs in kcp:

In a workspace that is bound to an API of e.g. widgets, provided by an API service provider in another workspace, the user can do kubectl get widgets as expected, but a kubectl get crd widgets.group.com will not show anything.

This detail suggests that the CustomResourceDefinition, the life-cycle of it, is completely in the hands of the service provider. Classically in Kubernetes, a custom resource is defined by a CRD, and an operator both provides the CRD (= manages its life-cycle), and at the same time also runs controllers to implement the actual logic of the CustomResources, e.g. widgets in our example.

And now the final technical step: if the CRD is managed by a service provider, why not let the service provider run the controllers too.

This is a powerful thought! It has the potential to disrupt how we think about custom resources in Kubernetes as a whole!

Think about it: in this model the user, for the first time, can really pick & choose just the API. No thought about where it comes from, who operates it, which operator adds the logic and whether the operator is still maintained in a year from now, or whether there is even an operator involved to add behaviour to custom resources. The API, and only the API becomes the interface. Call it the contract between user and service provider. This is a change in philosophy.

And there we are: we have built an extension mechanism for multi-tenant services. Workspaces give us isolation for logical clusters, i.e. multi-tenancy and APIExport+APIBinding allow a service provider to publish an API to many tenants and run controllers to act on the resource. This is a persona the Kubernetes ecosystem has not known.

Of course, there are many more details about how a multi-tenant controller actually looks like. How can the service provider access tenant data both securely and efficiently? How does this scale? But this is a topic for another post.

Massive Multi-Tenancy

Some readers at this point will argue that multi-tenancy on Kubernetes has been solved, even for operators and APIs. Red Hat’s Operator Life-Cycle Operator (OLM) for example allows to delegate operator installation to users and it explores ways for multi-tenant operators. Also OpenShift and others have implemented multi-tenancy on-top of Kubernetes for a long time.

Furthermore, projects around the vcluster idea found other ways to implement multi-tenancy. In a vcluster setup users can even install their own CRDs.

What all these approaches have in common is that they are somewhere on a spectrum between strength of isolation and being cheap. You cannot have both. Cheap here means the resource overhead (cpu & memory & administration) per tenant. Running multiple real Kubernetes clusters gives perfect isolation, but scores poorly on the cost and administrative complexity scale. vcluster gives pretty good isolation, but is still kind of heavy, and needs administrational tools to keep that part of the story under control. What these solutions do is that they do kube, more kube, sometimes many more kube. But they use kube mostly unmodified.

Part of Clayton’s mandate was to think outside of the box, to question foundational choices we have made in kube 7 or 8 years ago.

Already in Clayton’s original prototype, he had basically added namespacing to kube-apiserver, i.e. something similar to namespacing in the Linux kernel which eventually made Docker and containers per se possible. Technically, Clayton’s prototype did the same thing, to eventually allow it to serve isolated clusters under /clusters/user through a shared kernel, the Kubernetes control plane.

What if we build a system that can be deployed with many apiservers, all behind a load-balancer, and each serves a subset, a partition of the logical clusters under /clusters/<logical-cluster-name>. Then we could scale up horizontally as much as we want.

Well, of course there is lots more to think about here. But that thought fundamentally is correct. That’s what we have done. The complications here are that we are talking about cross-workspace logic like APIExports and APIBindings (and other APIs we are building). An apiserver (we call them shards) needs certain knowledge about the global state. In this case, every shard must know about APIExports, and a multi-tenant controller must know about APIBindings and how to access shards.

So a large focus of the kcp project is to explore and implement API patterns that allow this horizontal scaling. An intentional trick here is that every logical cluster aka workspace is 100% Kubernetes API convention conformant. Cross-workspace we have more freedom. Clearly, this is a crucial insight to scale up horizontally without trying to solve the CAP theorem on that path.

What have we Built?

Very early on, we figured that

kcp is an ideal platform for massively multi-tenant service providers.

This eventually became the slogan on our website kcp.io. We have seen

how APIExports and APIBindings allow a service provider extension model.
how small, mostly independent clusters allow horizontal scaling.
how the secret sauce (actually not so secret as everything we are doing here is open) is to combine (1) and (2) by coming up with API abstractions that don’t conflict with horizontal scaling, e.g. that can survive network splits and network latency across the globe.

On this road, we have repeatedly observed colleagues realizing the power of (1) and (2), switching their head from that of a product developer to that of a service provider developer, seeing people inspired by the power for a service provider platform for them.

Our vision is that – with a globally running instance of kcp – one engineer can bring a service idea from inception to billing the customers down from many many months of work to a few weeks at max. Empower the engineers.

With Kubernetes, 7 or 8 years ago we got a multi-machine compute platform. It turned running workloads planet-scale from super complex into a commodity functionality of an open-source project. With kcp we aim at making building multi-tenant APIs boring. A next step on this journey. Multi-tenant APIs that can be shared. APIs that can be composed. APIs that are not caught in individual clusters. With that we hope to contribute to an ecosystem that can

innovate faster,
collaborate more,
and most importantly: can bring value to our users in a shorter time.