| 2:00 PM | Opening/Intro | kcp maintainers welcoming attendees to our first edition of the virtual kcpCON. |
| 2:05 PM | Project Status Update - kcp maintainers | kcp maintainers sharing the latest updates from the kcp project. |
| 2:15 PM | Building an Enterprise Control Plane for Platform APIs with kcp - Amine Hadri & Florian Blampey, SNCF | How do you offer one enterprise platform API to hundreds of teams without exposing clusters, infrastructure, or multi-tenancy mechanics?
In this case study, we present an internal developer platform that uses kcp as its API control plane for 300+ Kubernetes clusters. Team onboarding, Kubernetes as a Service, Namespace as a Service, and enterprise assets become first-class APIs in kcp workspaces.
Using a "Namespace as a Service request", we will trace the workflow end to end. An API-export syncagent owns authoritative publication, execution syncagents deliver resources only to responsible clusters, and Crossplane materializes each stage. As an automated platform API consumer, Crossplane composes a graph of resources: some are materialized in the management cluster, while others are written back into kcp as intermediate platform API resources, allowing the workflow to continue across workspaces and execution planes.
We show how a thin API wrapper lets users consume the APIs without having to understand workspace or tenancy mechanics, while Kyverno enforces admission policy. We will close with lessons on observability, lifecycle, API evolution, and capabilities still needed in kcp. |
| 2:50 PM | My First Date with kcp: Boundaries, Shared Spaces, and Healthy API Relationships - Aaileen Sarwar Syed, LEWIS UNIVERSITY | kcp can sound intimidating at first: horizontally scalable control planes, multi-tenancy, workspaces, APIExports, logical isolation, and Kubernetes Resource Model language all show up very quickly. This lightning talk takes a beginner-friendly and lighthearted approach to understanding kcp through the metaphor of a “first date.”
I will break down what kcp is, why it matters, and how concepts like workspaces, logical isolation, and APIExports help platform teams move beyond individual Kubernetes clusters. The goal is not to cover every deep technical detail, but to make kcp approachable for newcomers, students, early-career technologists, and anyone curious about platform engineering or Kubernetes-style APIs.
Attendees will leave with a simple mental model of kcp as a way to create shared platform services, safe boundaries, and organized API spaces across teams, tenants, or customers. |
| 3:10 PM | Logical Cluster Migrations - What, Why and How - Nelo-T. Wallus, SAP SE | So far Logical Clusters were always bound to the shard they were provisioned on. Recently the feature of Logical Cluster migrations was implemented.
In this talk I want to dive into why we need logical cluster migrations, possible alternatives, how migrations are implemented and how we can use them in production - as well as their drawbacks and pitfalls. |
| 3:45 PM | Building an Agentic IAM SaaS with kcp and Kubebuilder - Philipp Strube, Auweia | This talk discusses why the speaker's agentic IAM SaaS prototype is built on a kcp generic-controlplane, Kine, NATS, and Kubebuilder based stack.
The talk will discuss the day-to-day engineering experience and highlight the key benefits of using this specific architecture for self-service provisioning and access management.
The session will discuss:
* The architecture and components of how this stack powers the application.
* Why and how NATS is used as the main datastore via Kine.
* Adapting and extending the standard Kubebuilder repository layout for a SaaS application.
* The approach to local development, building, and deploying.
* Authenticating system components using OIDC and RBAC.
* An API design approach using namespaced kinds plus "linked namespaces".
* Engineering lessons learned, like dealing with the missing namespace controller and handling garbage collection. |
| 4:20 PM | Stop Giving Every Team a Cluster: Building a Self-Service IDP with kcp - Pritesh Kiri, Harness | Most internal developer platforms solve multi-tenancy the expensive way: a cluster per team, RBAC on top, and a growing bill for control planes nobody asked for. kcp offers a different answer: workspaces that behave like full Kubernetes API servers but cost nothing to run, and an APIExport mechanism that lets a platform team publish an API once and have every tenant team consume it on its own terms.
A new team needs "a cluster." What they need is isolation and self-service, not another control plane to patch. Cluster-per-team solves isolation and creates new problems: cost, upgrade fatigue, inconsistent environments.
This talk covers:
- Why namespaces, vcluster, and cluster-per-team fall short as IDP foundations
- How kcp workspaces give cluster-like isolation with zero compute overhead
- How APIExport and APIBinding let one team publish an API, and others self-serve it
- A concrete example: one shared service exported, two tenants consuming it
- Where kcp fits, and doesn't fit, in a real IDP stack
This talk is for platform engineers building internal tooling and anyone tired of justifying a new cluster every time a team asks for isolation. |
| 4:32 PM | Structuring a Platform on top of kcp - Lessons learnt the hard way - Robert Vasek, Clyso GmbH | While building a platform with kcp we learned a lot about not just developing but also about using kcp - knowledge that I want to share in this talk. |
| 4:45 PM | GPU as a Platform Service: Multi-Tenancy with kcp - Adit Modi, Lauren Group | Twelve teams. Eight A100s. One Slack channel nobody wanted to open on Mondays.
We tried namespace ResourceQuotas, time-slicing, priority classes — even a shared spreadsheet. Nothing worked. Quotas
were too coarse, preemption caused surprise evictions, and the spreadsheet became a political battlefield.
The breakthrough: stop treating GPUs as hardware to schedule. Start treating them as a platform service to offer.
Using kcp workspaces, we gave each team a logical cluster with a curated GPU API. Teams request capacity through
APIBindings — no fighting over node selectors on a shared cluster.
This talk covers: how namespace-level GPU quotas broke down, the shift from resource scheduling to API contracts,
workspace-per-team topology with APIExports for GPU capacity tiers, and where kcp's primitives still have gaps.
You'll leave with a replicable pattern for offering GPU capacity as a managed service using kcp — Kubernetes APIs all
the way down. |
| 4:55 PM | Closing Remarks | |
