 Hello everyone. We're very happy to be here. This is MJ. My name is Marvin. We are two of the maintainers for KCP. And today we would like to talk about building a Kubernetes style API. Well, using Kubernetes style APIs for building is just like control plane. First of all, Kubernetes is first and foremost a workload orchestrator for containers. But Kubernetes, those CDs and operators has become a fantastic way to provide additional APIs to developers. The Kubernetes API is declarative. It is very easy to understand. It is clear about inputs and outputs. It has a lot of good patterns like the status subresources. And it makes it very easy and consistent to interact with the Kubernetes API. Because of that, we as a community have long moved past just orchestrating containers with it. Just look at all the great CNCF projects that are on stage today. We have cross-plane coming up as an example. A lot of amazing tools have been built on top of an API that was meant to be a service, sorry, a container workload orchestrator. Because of all this greatness in the API, the reason for KCP, that was the reason for starting KCP. KCP was established as an open source project in 2021. So we have a couple of years under our belts. In 2023, it transitioned to a community governance model and was later accepted into the CNCF sandbox or late into last year. Therefore, this is our first KubeCon. We're very excited to be here as a CNCF sandbox project. And because, well, it's our first one, we didn't want to give a status update, we wanted to show you why KCP might be interesting to you. The question at the beginning of KCP was what if the Kubernetes API moved past just the role as a container workload orchestrator? What if it became a platform for building generic APIs and serve them at scale? And we want to show you what KCP as a control plan for that has to offer. So first thing, KCP implements something that is called logical clusters. So logical clusters are a way to provide Kubernetes APIs as a commodity. And they are implemented to something called workspaces. Each workspace has its own Kubernetes API. And they are organized in a tree structure. And you can basically easily navigate them with a KubeCTL plugin we have written. And each of them has its own API types, resources, and AirBug. And now MJ will tell you about how to manage APIs in these logical clusters. Cool. So KCP has way more features than this. But this is just one example of use case how you can do solve certain problem. Normally, when you operate Kubernetes clusters based platforms, you have two personas in a mix. It's a user and user developer who uses Kubernetes API, develops certain products, if it's cross-plane or something else. Or in this case, MongoDB as a service. And they use basically MongoDB as a service provided by some other team. And that other team usually is a platform team. But when the platform scales to the point of hundreds of thousands of users, you get to the point where you need a third persona as a service provider. So your platform team deals with the platforms. Your service provider teams deals with MongoDB as a service. So your service team defines an API, MongoDB. Shout out to the guys from Mongo if you are around. They define it as API export. And they provide it as an API as a service within KCP. And consumers, they just bind to these APIs. So what you end up, you end up to the one-to-many relationship where now you can have multiple consumers consuming certain API v148. So now your MongoDB team, service team are doing only versioning their APIs on their own. They can provide multiple versions of CRDs to the different logical clusters. So by default, you get this built in API as a service inside of KCP. So we try to decouple those two personas, the platform operator team and the service provider's teams. So everything what's there, all the APIs, they are existing ecosystem compatible. So when you customers bound database as a service API to their workspace, to a virtual Kubernetes API server, they can use all the existing tooling out there from SDKs to Qubectl. It looks like and feels like Kubernetes API server from their perspective. It's just horizontally scalable, web-sharding. And all the things you want from Kubernetes when you're building SaaS-based offering on top of it and what currently Kubernetes doesn't provide. If you want to know more, here's our page. We have bi-weekly community meeting. We have one more talk today, Thursday. And because we're in France, here's the picture of a French bulldog. For any social media post, my wife will give him a treat. So I appreciate if you tag him at KCP. And thanks for listening. And if you want to know more, find us. We hang out around here. Look for the logos on the badges or jumpers. And yeah, we have stickers if you come up with your questions. Thank you.