KubePlus Architecture Details

The main components are: mutating-webhook, platform-operator, helm-pod, kubeconfiggenerator. The helm-pod folder is inside platform-operator. kubeconfiggenerator is written in Python and is inside the deploy folder. Other components are written in Go.

First, regarding the names of various components. I acknowledge that the names are not very intuitive. You know how it goes, right? We start out with some names and then the names stick, but the functionality evolves over time. That is what has happened with following components: platform-operator, helm-pod, kubeconfiggenerator. In today's incarnation of KubePlus, more appropriate names for these components would have been: platformcontroller, helmer, crd-helper, respectively. So just keep in mind that the names are slightly off from the responsibilities of each of these components.

The starting point of the workflow is in platform-operator. It implements CRUD operations on ResourceComposition CRD instances. When a create of ResourceComposition is received, platform-operator makes a call to kubeconfiggenerator to register the new CRD. mutating-webhook builds and maintains the mapping of ResourceComposition to the new CRD defined inside of it. CRUD operations for the new CRD are implemented using combination of mutating-webhook and helm-pod. mutating-webhook intercepts CRUD calls for any CRDs that are in the platformapi.kubeplus/v1alpha1 apiGroup. Then it calls helm-pod to do helm actions. Note that any new CRD that we register through ResourceComposition has to be under platformapi.kubeplus/v1alpha1 API Group.