Cloudify Support For Helm – The Kubernetes Package Manager

Introduction

Package management is an important aspect in any large system that ensures packages are installed, upgraded, configured, uninstalled, etc in a consistent manner. It is only natural that Kubernetes would require its own package manager. And Helm has taken the proverbial helm on this one.
Now, in order to give users a Kubernetes-native experience when orchestrating their environments with Cloudify, we like to ensure that our software offers native integration with all elements of the Kubernetes ecosystem as they become more mature and commonly used. This is why we have built out support for Helm – and you can find the code here.
In this post, we will present this Helm integration, which offers the ability to use existing Helm Charts and to deploy it on a Kubernetes cluster.

Try the Free Multi-Cloud Kubernetes Lab!   

Cloudify and Kubernetes

Cloudify integrates with Kubernetes on many levels:
As a Kubernetes Provider, Cloudify acts as the IaaS layer for Kubernetes – allocating compute, network and storage resources. One Cloudify provider can interact with multiple clouds (AWS, Azure, OpenStack, etc).
As a Workload Provisioner on top of Kubernetes, Cloudify can create workloads, either defined using TOSCA (Topology and Orchestration for Cloud Applications) or Kubernetes native YAML file templates.
As a Kubernetes Provisioner, Cloudify can provision and manage multiple Kubernetes clusters on many clouds and manage advanced, post-deployment workflows.
As a Kubernetes Broker, Cloudify can present Kubernetes with a Service Catalog and act as a Service Broker to access external resources natively from within Kubernetes.

Multi-cloud Kubernetes deployments

Using Cloudify and TOSCA, one can deploy workloads to multiple clouds as well as to multiple Kubernetes clusters. TOSCA defines the workload topology, what is deployed where. It serves several hybrid use cases like cloud bursting, resource allocation, or workload migration from one cloud to another. There are also more complex use cases where workloads span multiple clouds and multiple Kubernetes clusters.

What is Helm and what are Charts?

Helm is the Kubernetes package manager, responsible for installing and managing Kubernetes applications. This is similar to apt and yum. As per the website:

“[Helm] Charts describe even the most complex apps; provide repeatable application installation, and serve as a single point of authority.”

Helm charts have become very popular and are the de-facto standard for deploying applications on top of a Kubernetes cluster.

Why do we need Helm support in Cloudify?

The combination of TOSCA and Helm is very powerful and provides the flexibility to natively deploy Kubernetes workloads on a cluster as part of a TOSCA topology. The Cloudify/TOSCA blueprint describes both Kubernetes and non-Kubernetes environments as part of the TOSCA topology which serves popular hybrid cloud use cases.
You can provision and manage the lifecycle events of bare metal, VMs, containers and serverless  services using Cloudify and TOSCA. Moreover, TOSCA serves as the “Service Management” layer where business decisions can be made and then executed at the lower layers such as with Helm Charts.

How is Helm deployed with Cloudify?

With Cloudify you define workloads described as TOSCA nodes. Nodes could be VMs, containers, application software components, and, in our case, Helm Charts. Software packages can be installed utilizing Helm, which in turn will install the Helm Chart on top of a Kubernetes cluster.
Here you can find the definition of the TOSCA Helm node type. As you can see, there are a couple of parameters, ‘cwd’ and ‘args’, and a couple of lifecycle events, ‘start’ and ‘stop’.
The ‘cwd’ parameter points to where the Helm Charts reside and are invoked by the TOSCA node, while the ‘args’ parameter adds additional info regarding how the Helm package is installed.
The lifecycle events, ‘start’ and ‘stop’, install and delete the Helm Chart respectively.
To utilize the new TOSCA Helm node type and deploy Helm packages on a Kubernetes cluster, use the below:

A new TOSCA node named ‘msb’ from type cloudify.nodes.Helm is created. It gets additional inputs on the relevant namespace and application to install and points to the relevant Kubernetes master, utilizing TOSCA relationships.
The Helm plugin is based on our Fabric plugin and can install any Helm Chart on any given Kubernetes cluster. This is done by pointing to a Kubernetes cluster Master IP address or node that can run kubectl and is connected to the appropriate Kubernetes Master.
In many cases vanilla Kubernetes comes without Helm installed. Cloudify can automate the ‘Helm init’ process and install the Tiller server side pod as well, as Kubernetes 1.7 and onwards also requires the creation of a service account for the Tiller server.

How Cloudify enhances Helm’s capabilities

Cloudify works in tandem with Helm to install existing Helm Charts as well as augment global inputs from Cloudify and populate them as Helm Values. As seen in the figure below, Cloudify can be used to override local Helm Values with cross-system, cross-application Global values. Using TOSCA, users can manage multiple clusters and hybrid environments, and set Global variables that can be populated to a specific deployment.

Moreover, this mechanism allows the Service Orchestrator, at the service layer, to decide what Values to use where, based on a service policy, e.g. what services to run, which environments to use, which clusters it runs on, etc. These types of decisions need to be made at the service layer, not at the Helm Chart layer which is an execution package that runs on a local cluster and carries the service layer orders.

Deploying a simple application using Cloudify and Helm

For simple applications, you can deploy any given Helm Chart using Cloudify and the newly introduced Helm node type as long as you follow the basic rules – ‘cwd’ pointing to the Helm Chart location and pointing that to a given Kubernetes Master or a node running kubectl.
For example, take the following Helm Chart and run it using Cloudify/TOSCA and the new Helm node type.

Deploying a complex application using Cloudify and Helm

Cloudify deploys ONAP applications (there are more than twenty of them) on top of a Kubernetes cluster or multiple clusters. See the ONAP wiki page that explains this process in detail. It utilizes the new TOSCA Helm node type and if you look at the blueprint each ONAP application definition is very simple.
The figure below shows the TOSCA blueprint snippet, the helminstall.sh script, the directory structure, and the Makefile that creates a Helm repo artifact.

Conclusion

The worlds is moving to containers architecture pretty rapidly and Kubernetes is seen as the best way forward. We are building out our Kubernetes integration, such as with Helm, for three main reasons:
1. We want Kubernetes users to get the K8s-native experience when using Cloudify to orchestrate their workloads.
2. Cloudify connects Kubernetes with the rest of the non-container world and ensuring projects like Helm are supported is an important part of helping organizations with mixed container-based, multi-cloud, and even non-cloud, environments.
3. Lastly, Cloudify works as a sort of cloud-native app store for any templates, images, and other packages. With integrations for Helm Charts, Kubernetes templates, Docker images, and more, Cloudify is able to be a single point of aggregation for all of your organization’s pre-built applications and can readily orchestrate them from deployment to scaling and beyond.