epic: kube-bind client controller and kubectl plugin extension for kcp

[mirzakopic]

Description

While #2 is an alternative implementation of the kube-bind backend, I believe we also need an alternative client implementation. The current one (which is kubectl-bind, a kubectl plugin) installs a component called "konnector" into the cluster that is supposed to use a kube-bind-aware backend (i.e. a "client" cluster). Since that doesn't work with kcp (you cannot create a Deployment in kcp to run the konnector), kcp needs a separate client implementation to consume remote services as well.

There is no clear "sketch" for how this would look like, but the rough idea would be to have a kcp-aware controller with its own APIExport to create "KubeBindBindings" (?). A kubectl plugin (a fork/adaption of kubectl-bind) has a similar flow to the existing one, but it creates a custom resource which is processed by the kcp-aware controller, which then starts the handshake with the kube-bind backend, exposes a URL via the resource status. This would be picked up by the kubectl plugin for the same "interactive" experience of kubectl-bind (if possible!)

The kcp-aware controller would subsequently spin up syncer processes/controllers/pods (maybe even konnector?) for the configured sync.

Objectives

•  Consumers should be able to install a kube-bind client controller into their kcp environment.
• Consumers should be able to trigger binding an API via a kubectl plugin.
• Consumers should be able to consume kcp-based APIs from a remote kcp instance in their own kcp instance.

Stories

• Work out the conceptual design of an alternative kube-bind client in the form of controllers working on kcp. This includes the workflow of creating a remote binding (which APIs to call, what feedback to wait for, etc).
• Write a KCP Enhancement Proposal and submit it to the community for review. Make clear this is an optional extension to kcp. Your goal is to host the code on github.com/kcp-dev.
• Create MVP implementation of kube-bind client controllers and APIs.
• Demo implementation, gather feedback, adapt design and code as appropriately.
• Clean up code, implement e2e tests, write documentation.

Demo Required

Yes

Demo Steps

1. Set up a remote kcp instance with the kube-bind backend (feature: make order of authorizers configurable #2).
2. Install local kcp instance with kube-bind client controllers and APIs.
3. Use kubectl plugin to bind a remote API.
4. Create API objects that get synced via kube-bind to the remote kcp.

Migrated from openmcp/kcp-upstream#3

[mirzakopic]

@ntnn please reach out to @embik and @mjudeikis

[mjudeikis]

Some work was done here:
kbind-dev/kbind#231
But it was put on ice until we do wider kube-bind refactor

[ntnn]

Looking at the current plans for CRDs I think we could get away with implementing a single controller that just reacts to the resources; no need for consumer/local- and provider/remote-specific controllers.

The kubectl plugin would then only need to setup the linking between the clusters for the specific bind that is requested and deploy the initial resources (so APIServieExportRequest).

That'd make it easy to import in KCP as a feature and would naturally allow every combination of kcp or kube+controller as either provider or consumer.

[ntnn]

For reference the CRD plans for kube-bind: https://docs.google.com/document/d/1pWFaJbEyBJVERkpm-saFMsGs9WEPYEIX2jFtusR5-do/edit?tab=t.0#heading=h.6prhylq8dd7w