The CR/CRD API server alone is worth pursuing as a separate concern

[mangelajo]

Hey!

Thanks for this amazing project, I really find it interesting. I'm looking at it from the point of view of the submariner.io project, where I believe it could be interesting in many ways:

1. As a standalone broker server deployed anywhere.
2. As a way to build an all-in-one submariner binary which could be used outside of k8s (to connect legacy workloads with k8s workloads). See the these scratch slides as some details on a workgroup we have on this topic, now we are use k3s, but we could make a single binary.

This makes me believe that it can be very interesting to keep the concerns of this project separate:

1. A kcp or kcp-api (I'm not good with names) which lives on it's own repo and can be used to build standalone k8s API servers where we can install CRDs and extend it with controllers embedded from our applications
2. a multi-cluster kcp controller (as I see it's evolving towards right now).

@imjasonh let me know what you think.

Best regards,
Miguel Ángel.

[imjasonh]

The answer is a resouding yes. 😄

A lot of the recent prototyping work has focused on the multicluster investigation, but we absolutely want to investigate other things we could build on a minimal API server, and what it would take to enable those.

---

Copy/paste from Slack:

Basically:

• We think a minimal, embeddable K8s-style API server is useful on its own, full-stop. Lots of things could be built on it.
• One of those things is something like Crossplane, where you can manage non-k8s infra declaratively using the controller pattern
• One of those things is a Cluster API bootstrapper, like detiber's badidea repo
• One of those things is transparent multicluster, which lots of people have tried to varying degrees of success, but so far nobody has tried by making a minimal, embedded API server