When building a scalable, multi-tenant platform like Kubermatic Kubernetes Platform, we think a lot about APIs. How users programmatically interact with our platform is a central key consideration and defines a significant part of the user experience.
We have been leveraging custom resources (as defined in CRDs) from the inception of our platform. With recent KKP releases, we brought more direct usage of our custom resources to KKP users to further automate cluster management and integrate KKP into an existing platform stack based on standard Kubernetes mechanisms. However, we heard from our users that they hope we push these concepts even further and bring even more multi-tenancy capabilities to our platform.
We experimented with multiple approaches and built tools like Bulward. During development we realized that the problem we are solving is not specific to Kubermatic and its products.
As a company with a strong Open Source and community focus we were looking around if we could not find like-minded people and companies who are trying to solve the same problem and join forces. Searching for a suitable solution, we found kcp.
What is kcp?
kcp extends the Kubernetes API we all know and love by adding advanced isolation and API management concepts to the core Kubernetes experience. It is not a fork but a citizen of the Kubernetes ecosystem, built upon the latest Kubernetes releases and simply optimizing it for the use case in question — Massive scalability, API management, strong multi-tenancy.
kcp decouples the high quality of Kubernetes’ API concepts and its purpose as container orchestrator and allows building API platforms without the workload management parts. It also introduces a new multi-tenancy concept called “Workspaces” that helps enforce boundaries between different teams or organizations using the same kcp instance.
Workspaces are essentially “logical” Kubernetes clusters, each of them acting like a dedicated Kubernetes API server. This means that resources are not shared across workspaces and the types of resources differ from workspace to workspace. kcp’s API exports allow workspaces to consume a set of APIs and is a crucial building block to building an as-a-service experience.
Diving into Workspaces
If you are interested in trying out kcp, a quickstart guide is available on the project website. Taking kcp for a test drive is really easy and can help understand what kcp actually offers.
Let’s quickly explore workspaces together, using a kubectl plugin provided by kcp — When you start kcp from scratch only one workspace exists, and it is called “root”. This is — as the name suggests — the root of our workspace tree, since workspaces can be arranged in a hierarchy (i.e. you can create workspaces within workspaces and they become children of that workspace). Creating new workspaces (if you have the necessary permissions) is as easy as:
$ kubectl ws create kubermatic --type=organization --enter
Workspace "kubermatic" (type root:organization) created. Waiting for it to be ready...
Workspace "kubermatic" (type root:organization) is ready to use.
Current workspace is "root:kubermatic" (type root:organization).
A few workspaces later, the workspace tree could look something like this:
$ kubectl workspace tree
.
└── root
└── kubermatic
├── department-a
│ ├── team-a
│ ├── team-b
│ └── team-c
└── department-b
├── team-a
└── team-b
Switching back and forth between workspaces is as easy as passing their paths to the kubectl plugin:
$ kubectl workspace root:kubermatic:department-a:team-b
Current workspace is "root:kubermatic:department-a:team-b".
$ kubectl workspace root:kubermatic:department-b:team-a
Current workspace is "root:kubermatic:department-b:team-a".
The important bit — and this is where the power of kcp starts to shine through — is that each workspace acts like a separate Kubernetes API to the user accessing it. This means creating namespaces, CustomResourceDefinitions, or other kinds of resources in one of the team workspaces will only affect that workspace and custom resources created by CRDs will be confined to that specific workspace. That being said, each workspace can be accessed by normal kubectl — the plugin is only a helper to discover API endpoints.
For managing API resources across workspaces, kcp offers APIExports/APIBindings. The kcp documentation has a quickstart on the whole process of managing APIs at scale and we recommend walking through it to get a feeling for what is possible with it.
Community Governance
In May 2023, the previous stewards of kcp decided to step down from their role and started the search for a new home for kcp. Kubermatic, among other organizations and individuals, had the idea to continue kcp in a fully community-driven approach. As part of the new community new community governance was established and Sebastian Scheele became one of the three initial maintainers after the governance transfer. You can find the current governance document here.
We are thrilled to be part of the community that is now pushing kcp ahead. One of the first big challenges for the project was moving to a new Continuous Integration (CI) infrastructure to resume testing and validating contributions.
Kubermatic stepped up and provided a new Prow instance that is used for CI/CD in the kcp-dev GitHub organization. Kubermatic is proud to sponsor such an important project by providing the necessary infrastructure.
Just a few days ago, the first kcp release (0.20.0, available on GitHub) under the new governance model has been released. It is one of the biggest kcp releases since its start and proves to us that the project is alive and kicking.
CNCF Sandbox Application
We strongly believe kcp is the control plane of the future and enables building cloud native platforms that cannot be rivaled in scalability and user experience.
Because of that, Kubermatic is proud to sponsor the application to let kcp join the CNCF Sandbox and become a part of the Cloud Native landscape, unlocking organizations’ ability to build and manage large-scale APIs that feel like you are operating a Kubernetes cluster without the overhead of actually running Kubernetes.
We hope this proposal will be accepted and will help foster adoption of and contributions to kcp.
If you are interested in joining the growing kcp community, join us in the #kcp-dev Slack channel on the Kubernetes Slack or on the bi-weekly community calls on Thursdays.
About Kubermatic
Kubermatic empowers organizations worldwide to fully automate their Kubernetes and cloud native operations across multi-cloud, edge and on-prem As the top European committer to the Kubernetes project, Kubermatic is a trusted provider of enterprise-grade software solutions, professional services, and support to help organizations safely navigate and accelerate their cloud native transformation.
With the Kubermatic Kubernetes Platform (KKP), organizations can easily operate thousands of Kubernetes clusters on any infrastructure, empowering them to achieve their goals with greater speed and efficiency. Renowned enterprises such as Lufthansa, Bosch, Siemens, and T-Systems rely on Kubermatic to lead their cloud native journey.
Headquartered in Hamburg, Germany, Kubermatic is well-positioned to support organizations worldwide in achieving their digital transformation goals.
Find us at: www.kubermatic.com
