Implement a CLI command to bind a user workspace to some compute.

[davidfestal]

We should implement a KCP CLI command that allows "bind" a user workspace to some compute.
More precisely this command would allow providing:

• at least the location workspace that contains locations and sync targets the user workspace resources should be synced to
• optionally the location selectors, namespace selectors
• optionally a list of workload APIExports of resources we want to sync.

Command line could something like:

kubectl-kcp bind compute <locationWorkspace name> --location-selector=<locationSelector1> --location-selector=<locationSelector2> --apiexport=<apiExport1> --apiexport=<apiExport2> --namespace-selector=<namespaceSelector> 

Based on these provided information:

• a Placement would be created,
• APIBindings would be created in the user workspace to the corresponding APIExports (if they don't already exist). We should check that the every requested APIExport is effectively part of the supportedAPIExports list of at least one SyncTarget of the location Workspace.

If no APIExport is mentioned, then for both the local kubernetes and global kubernetes APIExports, if it is supported in at least one SyncTarget of the location Workspace, automatically create a binding to it (if it doesn't already exist).
When creating an APIBinding, set the apis.kcp.dev/kind label to the workload value, in order to identify this binding as a workload-related APIBinding later on.

In this task we should also remove the defaultplacement_controller.go, since this command would replace it.

[stevekuznetsov]

Creating the APIExport - not sure. I could see a flow like:

1. oh, I have a workspace
2. cool, let me add in k8s 1.24 + whatever else
3. great, now let's see which locations I can schedule to

We might also think about what happens when someone upgrades their export from k8s-1.24 to k8s-1.25 - a CLI that can handle existing exports & do validation for you might help there too.

[davidfestal]

@stevekuznetsov I understand your point, and I don't think that implementing this command would prevent the flow you're proposing. It wouldn't prevent you to create a binding without running this CLI command.
Similarly it wouldn't prevent additional (future) code to present you all the locations compatible with a given APIExport, and use the result of such a search when applying this CLI command. However the code that present available & compatible locations is part of the EPIC stretched goals, but is not required in the context of this issue.

For now users know what locationWorkspace they plan to use: it is the one inside which they (or some admin user) ran the workload sync command (In the currently flow, users always explicitly bind to the local kubernetes APIExport in this location workspace).

So the purpose of this issue is to provide, with a CLI command, the simplest and most straightforward way to bind to this already-known location Workspace. It makes it :

• simpler because it manages both the Placement and the Workload-related APIBindings, with appropriate defaults.
• safer since it also checks that at least one SyncTarget of this locationWorkspace supports the bound workload-APIExports.

[qiujian16]

should it be kubectl kcp workload bind? we currently do not have a kubectl kcp bind command, or should there be a common bind command that will also be used for other bind related functions?

[ncdc]

We do now 😄 #2027

[davidfestal]

should it be kubectl kcp workload bind? we currently do not have a kubectl kcp bind command, or should there be a common bind command that will also be used for other bind related functions?

From a user POV it should be kubectl kcp bind workload (== a subcommand of the bind command).
But implementation-wise it might also have been a kubectl-kcp-bind-workload binary.
However based on the just-merged PR @ncdc mentioned, adding a sub-command to the bind command, and completing the bind command help with the workload use-case would probably provide a better UX.