Users may be using tools such as helm, argocd, github actions to deploy the cloud-native applications (creating helm releases). KubePlus should be able to subsume such helm releases and retrofit them with multi-tenancy policies.
One way to implement this will be via a kubectl plugin.
Say we implement the following plugin: kubectl-subsume-release
kubectl-subsume-release will create KubePlus objects for the input helm release.
One assumption we will have to make is that helm releases are created in their own namespaces. If this is not being done, then the CICD workflow should be modified to implement this. Suppose an application (like WordPress) has been deployed in a namespace wp1. The plugin will do the following:
- Add KubePlus Network policies to the namespace
- Create a ResourceComposition with some Kind name. The helm chart used for deploying the application will be referenced as part of the ResourceComposition definition
- Create an instance of this Kind with the Spec property values inferred from the installed Helm release's (values). Note that when creating this instance, we want to prevent KubePlus from handling this instance. If KubePlus tries to create the instance, it will get instance already exists error. (We should verify if KubePlus does anything additional, like deleting an instance, if an instance with that name already exists. If KubePlus is not actively doing anything when it encounters this error then we don't need to actively prevent KubePlus from handling the instance. Otherwise, we should. And one way to do this will be to use an annotation (say, "skip-processing").
- Add the helm release name and namespace name in the status of the instance (Is it possible to create a Kubernetes object with both spec and status fields filled in at the same time? If not, then we will have to first create the object and then update it to fill the status fields).
Verification:
We will know if the plugin works as expected if we are able to access the application instance as if it were created by KubePlus. For instance, we should be able to retrieve metrics for the helm release, we should be able to get appurl, applogs, we should be able to even update the helm release via KubePlus.
Users may be using tools such as helm, argocd, github actions to deploy the cloud-native applications (creating helm releases). KubePlus should be able to subsume such helm releases and retrofit them with multi-tenancy policies.
One way to implement this will be via a kubectl plugin.
Say we implement the following plugin: kubectl-subsume-release
kubectl-subsume-release will create KubePlus objects for the input helm release.
One assumption we will have to make is that helm releases are created in their own namespaces. If this is not being done, then the CICD workflow should be modified to implement this. Suppose an application (like WordPress) has been deployed in a namespace wp1. The plugin will do the following:
Verification:
We will know if the plugin works as expected if we are able to access the application instance as if it were created by KubePlus. For instance, we should be able to retrieve metrics for the helm release, we should be able to get appurl, applogs, we should be able to even update the helm release via KubePlus.