Flexible API server, API resource, and controller composition for KCP

[karolz-ms]

Problem statement

While experimenting with KCP as a building block for local workload orchestration on a dev machine I realized that I would like to limit KCP composition to just what I need for this scenario. That is, I want local API server with a few standard API resources and controllers. Right now I just need namespaces and custom resource definitions plus associated controllers, really--I do not need multi-cluster capability.

Unfortunately, as KCP is implemented today, it is not easy to pick what is included in the composition. Most of the code that sets up the composition is not accessible from outside of the package where it lives. That applies to 2 of the 3 API servers (API extensions server and aggregator server). For each server, the set of associated API resources and controllers cannot be changed. I tried copying a bunch of code that forms the bulk of API server chain creation, but even after pretty intense hacking I could not really figure out how to have CustomResourceDefinition API installed without bringing in the API aggregator server, which I probably don't need.

Desired solution

I would like to be able to create my own KCP executable, and as part of its startup code, express what capabilities, API resources, and controllers I would like to include. Ideally, if there are dependencies between components (e.g. Namespace API resource requires namespace controller), the dependencies should be automatically included in the composition.

We could start with something very simple (minimal, standalone KCP API server with CRD and RBAC support vs full KCP like it is today) and move towards more flexible/declarative composition. I am open to collaboration on this.

I also think/hope this request is in line with the minimal API server vision.

@imjasonh @davidfestal @smarterclayton please share your thoughts ☺️

[karolz-ms]

I guess I am asking for #48 😆

[pweil-]

Since it looks like this is a dupe of #48 I'll go ahead and close this issue. Please feel free to reopen if you disagree. Thanks!