Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

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 then interacts with Helm CLI.


It acts as a wrapper around Helm Cli to manage helm charts and K8s pods deployed in the cluster.

Helm 3 overview:

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.

Example: configured chart repos and the available charts are listed via helm cli:


Kubernetes Participant Architecture in Istanbul:

Prerequisites for kubernetes participant:

  • Kubernetes cluster running.
  • Helm cli running.
  • Operator is expected to store the helm charts in any of the configured helm repositories via helm cli command (or) the charts should be kept on the local storage directory of kubernetes-participant. (This directory is a preconfigured path specified 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 :

  • 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 database. And when the control loop is instantiated, kubernetes-participant receives control loop element update event from DMaap, it then invokes the helm client running on the host machine to install the corresponding helm charts associated with the affected 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 of the chart had not been specified in the TOSCA, it performs  "chart lookup"  on all the configured repositories of the helm client as well as on the local chart directory where the helm charts are manually onboarded by 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)

                                                                           


                                         



Sample TOSCA  template passed during commissioning of control loops. Below are the ways , the charts can be commissioned via TOSCA. 

Chart parameters: name, version, release_name and namespace are mandatory in TOSCA.

Repository can be specified with either configured helm repository name or any local directory where the helm charts are available.

(Note: Repository name is an optional parameter in control loop TOSCA template. If not specified, the k8s-particpant will do a look-up on the available repos)

Tosca template
org.onap.domain.database.HelloWorld_K8SMicroserviceControlLoopElement:
# Chart from any chart repository configured on helm client.
version: 1.2.3
type: org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement
type_version: 1.0.0
description: Control loop element for the K8S microservice for Hello World
properties:
provider: ONAP
participant_id:
name: org.onap.k8s.controlloop.K8SControlLoopParticipant
version: 2.3.4
chart:
release_name: helloworld
chart_name: hello
version: 0.1.0
repository: chartMuseum
namespace: onap

org.onap.domain.database.PMSH_K8SMicroserviceControlLoopElement:
# Chart from local file system 
version: 1.2.3
type: org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement
type_version: 1.0.0
description: Control loop element for the K8S microservice for PMSH
properties:
provider: ONAP
participant_id:
name: org.onap.k8s.controlloop.K8SControlLoopParticipant
version: 2.3.4
chart:
release_name: pmshmicroservice
chart_name: pmsh
version: 0.1.0
repository: /home/oom/helm-charts/PMSH
namespace: onap

org.onap.domain.database.Local_K8SMicroserviceControlLoopElement:
# Chart installation without passing repository name 
version: 1.2.3
type: org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement
type_version: 1.0.0
description: Control loop element for the K8S microservice for any chart
properties:
provider: ONAP
participant_id:
name: org.onap.k8s.controlloop.K8SControlLoopParticipant
version: 2.3.4
chart:
release_name: nginxms
chart_name: nginx-ingress
version: 0.9.1
namespace: onap








  • No labels