There are scenarios where importing the hosting cluster as Workload Description Space can be beneficial. For example, in the KubeStellar-MCAD integration there is a wrapped resource (AppWrapper) and no requirements to handle native workloads such as jobs or deployments. This approach may actually simplify the integration when KubeFlow is adopted with MCAD, as it would remove the need to copy the AppWrapper CR from the hosting cluster (where KubeFlow is installed) to the WDS.
Proposed Solution
Add a new type of control plane to the exiting ones (k8s, ocm, vcluster) - e.g. host. The ControlPlane instance for this scenario would look like:
The implementation of this type of control plane is much simpler than k8s or vcluster. The KubeFlex controller still creates a namespace for this control plane, which can be used for example to host controllers created using the post-create-hooks templates. One example is the kslight controller. Note that for this type of control plane, we do not need a service, ingress or route, DB backend etc. As for the Kubeconfig secret, it may be not necessary to have the off-cluster kubeconfig in the secret (this is already available to the admin user in his own kubeconfig file). However, it may be better to have at least the in-cluster config, so that controllers launched as post-create-hooks can use the same mechanism to interact with the hosting cluster API server.
Feature Description
There are scenarios where importing the hosting cluster as Workload Description Space can be beneficial. For example, in the KubeStellar-MCAD integration there is a wrapped resource (AppWrapper) and no requirements to handle native workloads such as jobs or deployments. This approach may actually simplify the integration when KubeFlow is adopted with MCAD, as it would remove the need to copy the AppWrapper CR from the hosting cluster (where KubeFlow is installed) to the WDS.
Proposed Solution
Add a new type of control plane to the exiting ones (k8s, ocm, vcluster) - e.g.
host. The ControlPlane instance for this scenario would look like:The implementation of this type of control plane is much simpler than k8s or vcluster. The KubeFlex controller still creates a namespace for this control plane, which can be used for example to host controllers created using the post-create-hooks templates. One example is the kslight controller. Note that for this type of control plane, we do not need a service, ingress or route, DB backend etc. As for the Kubeconfig secret, it may be not necessary to have the off-cluster kubeconfig in the secret (this is already available to the admin user in his own kubeconfig file). However, it may be better to have at least the in-cluster config, so that controllers launched as post-create-hooks can use the same mechanism to interact with the hosting cluster API server.
Want to contribute?
Additional Context
No response