Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: FAQ.md

kcp is a highly-multi-tenant Kubernetes control-plane, built for SaaS service-providers who want to offer a unified API-driven platform to many customers and dramatically reduce a) cost of operation of the platform and b) cost of onboarding of new services. It is made to scale to the order of magnitude of 10s of thousands of customers, offer a Kubernetes-like experience including execution of workloads, but with dramatically lower overhead per new customer. Check out our document and feel free to open an issue if something is not covered. kcp has a concept called which is installed on each . The negotiates, with kcp, a set of APIs to make accessible in the workspace. This may include things like or other resources you may explicitly configure the syncer to synchronize to kcp. Once these APIs are made available in your you may then create resources of that type. From there, the APIs help determine which your deployable resource lands on. No, the Kubernets conformance suites require that all Kubernetes APIs are supported and kcp does not support all APIs out of the box (for instance, Pods). Yes! All development is public and we have started discussions about what is mature enough to present to various interested parties. It is worth noting that not all of the goals of kcp are necessarily part of the goals of Kubernetes so while some items may be accepted upstream we expect that at least some of the concepts in kcp will live outside the Kubernetes repository. kcp depends on a of Kubernetes. Updating Kubernetes for the kcp project itself requires a rebase. We are actively following the releases of Kubernetes and rebasing regularly. Updating Kubernetes for clusters attached to kcp is exactly like it is done today, though you may choose to follow different patterns of availability for applications based on kcp's ability to cordon and drain clusters or relocate applications. Yes. We are in the early stages of . Please join in the conversation if you have opinions or use cases in this areas. We aren't quite there yet. Security controls are especially important at the multi-tenant level and we'd love to hear your use cases in this area. Controller patterns are something we are actively working on defining better. In general, operators and controllers from a service providing team would run on their provided compute (or shared compute) and point back to kcp in order to have a view of the resources being created that they need to take action upon. This view would be via a . Yes. We are tracking and as use cases we need to support. You can view a demo of the current work in our . can contain other workspaces and workspaces are typed. Please see the for more details. Yes. via an external URL are supported. They do, in the where the pods live and run. The control plane doesn't have pods (at least not by default, today). In kcp an application should be able to describe the constraints it needs in its runtime environment. This may be technical requirements like GPU or storage, it may be regulatory like data locality or FIPS, or it may be some other cool thing we haven't thought of yet. kcp expects the integration with APIs to handle finding the right placement that fulfills those requirements. Shards in kcp represent a single apiserver and etcd/db instance. This is how kcp would like to split workspaces across many kcp instances since etcd will have storage limits. You're in the right place. Clone this repo and run `make install WHAT=./cli/cmd/kubectl-kcp`.