Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow ClusterLink to run when CRDs are not installed in a cluster #351

Open
elevran opened this issue Feb 26, 2024 · 0 comments
Open

Allow ClusterLink to run when CRDs are not installed in a cluster #351

elevran opened this issue Feb 26, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@elevran
Copy link
Collaborator

elevran commented Feb 26, 2024

"Unprivileged mode" can be interpreted as a continuum. A simpler case is running and configuring ClusterLink the context of a single namespace deployment ("cluster" admin and application admin are the same principle). A more complex solution is needed if CRDs can't be installed at all. This could mean that CL runs in two management modes (with and without CRDs) that have considerable code changes and duplication between them, increasing maintenance effort.

A possible workaround is to run a minimal k8s distribution as the management place solely for CRD's. For example, k3s in agentless mode (embedded no CNI, Kubelet, etc.). The pod(s) can run as a deployment in HA mode or single node mode. We don't expect this to be a common use case so minimizing code investment is beneficial. An alternative would run the API (k3s) as another container in the ControlPlane Pods.
The additional API endpoint runs and is available in the local namespace only and used by the CL controllers. The customer would need to set up a network path to the internal API endpoint (e.g., kubectl proxy or Ingress) so they can set up CRDs directly). This can be hidden behind a CLI that does the set up and knows to dispatch commands.

Each controller would then have two k8s clients: one for CRDs (in the local namespace) and one for objects for the real cluster (e.g., Services, Pods, Secrets, ...)
For regular mode (with cluster installed CRDs) we would have both clients point to the cluster API endpoint. In namespace installed CRDs each client runs with a different kubeconfig.

CC: @praveingk

@elevran elevran added the enhancement New feature or request label Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants