...
Kubernetes Participant performs the helm chart installation and LCM for k8s microservices that take part in Control loop. It implements Participant-Intermediary API to receive events from DMaap and interact then interacts with Helm CLI.
It acts as a wrapper around Helm Cli to manage helm charts and K8s pods deployed in the cluster.
...
In Helm3, helm cli acts as an interface for Kubernetes cluster to deploy and manage helm charts. It also supports configuring multiple chart repositories to the helm client and access the charts from those repos for installation. The repositories can be a local chart server running on the same machine as well a third party chart server running elsewhere. The URL of the chart server can be configured on the helm repo list to access the hosted helm charts. User can add a repository and push helm charts under the repository via helm cli commands.
...
- Kubernetes cluster running.
- Helm cli running.Helm charts are either stored in the local storage via k8s-participant's exposed REST interface or pushed to any of the helm repos that are configured on the helm cli
- Operator is expected to store the helm charts in any of the configured helm repository via helm cli command (or) the charts should be kept on the local storage directory of kubernetes-participant. (This directory is a preconfigured path on the participant config that acts as a local chart repository).
Note: Incase of containerization of kubernetes participant in upcoming release, the kubeconfig file of the required kubernetes cluster should be copied to the k8s-participant's docker container in order to make helm cli work with the cluster outside.
In Istanbul release, Kubernetes participant in control loop supports installation of helm charts in below ways:
...
.
...
When the k8s-participant receives event update from DMaap , it
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The K8s participant exposes rest end points through which below operations can be performed.
- Onboard a helm chart to the local directory. (A helm chart can be passed to the rest end point of k8s participant, it then stores the chart under the path /<pre-configured directory>/<chart name>/<version>/
- Delete a helm chart from the local storage.
- Install a helm chart in to the k8s cluster.
- Uninstall a helm chart in to the k8s cluster.
- Get all the charts available in the local chart storage directory.
It also implements participant-Intermediary APIs to interact with DMaap topic for control loop. When the Control loop element update event is received from DMaap, it invokes the helm client to install the corresponding chart based on the name and version of the chart.
|
In Istanbul release, Kubernetes participant in control loop supports installation of helm charts in below ways via control loop:
- Install a helm chart that is present in the local file system where the kubernetes participant is hosted.
- Install charts from the helm repositories that are configured on the helm client.
Kubernetes-participant acts as an interface between DMaap and Helm Client.
While commissioning the control loops, the helm chart parameters are passed via TOSCA template to the control loop runtime. And when the control loop is instantiated, kubernetes-participant receives control loop element update event from DMaap, it then invokes the helm client on the host machine to install the corresponding helm charts associated with the control loop elements.
The k8s-participant gets the parameters (chart name, version, release name , and namespace) of the chart from the control loop runtime. If the repository is not passed of the chart had not been specified in the TOSCA, it does a lookup of the specified chart in performs "chart lookup" on all the configured repositories in of the helm client as well as on the local chart directory where the helm charts are manually onboarded visa RESTby the operator. It fetches the appropriate repository info and installs the chart via helm cli.
The k8s-participant takes care of creating namespace on the cluster if required, fetching the helm chart from the available repositories, installing and uninstalling the chart in to the cluster.
In the upcoming release, additional options will be supported in control loop for onboarding the helm charts to the repositories via TOSCA (both configured helm repos and local chart directory) before instantiation. (Under discussion)
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...