In 5G, RAN and Core the whole telecom is moving toward cloudification based on CNFs (Container Network Function) based deployment using Kubernetes (k8s) and MNOs are implemented CI/CD with every piece as automatable. K8s is a powerful container-orchestration system for application deployment. To automating creation, packaging, configuration, and deployment of microservices with in a Kubernetes clusters we need a tool to make our life easy and that tool is know as Helm.
We have being using apt in Ubuntu and yum in CentOS, similar functionality helm provides in Kubernetes enviornment. Helm helps in deploying the applications (microservices pods) to Kubernetes and structures them into charts. These charts contain all pre-configured application resources along with all the versions into one easily manageable package. Helm helps in streamling the installation, upgrades, getting dependencies, and deployments configuration on Kubernetes with simple CLI commands. This Helm CLI command can be easily used with Automation.
Book definition for Helm, It is an Operator that describes a method of packaging and deploying Kubernetes applications that take human operational knowledge of managing the application and encode it into the package itself, which can then be shared with users.
Key Pointer about Helm:
- Helm is similar to apt in Ubuntu and yum in CentOS
- Helm helps in managing Kubernetes applications
- Helm uses a packaging format called charts
- A chart is a collection of files that describe a related set of Kubernetes resources
- Helm Charts helps in defining, installing, and upgrading the most complex Kubernetes application
- Helm allows software developers to deploy and test an environment in the simplest possible way and helps in maintaining CI/CD pipeline for development to testing to production
- Helm provides a convenient/easy way for developers to pack and send applications to end users for installation
- Helm keeps track of the versioned history of every chart installation and change
- There are two types of Helm, Helm2 and Helm3
- People do use Go or Ansible scripts as an alternative of Helm
Why do we require Helm?
It is very challanging to manage Kubernetes objects. With the help of tools like helm, the Kubernetes learning curve becomes smooth and manageable. Helm can automate the maintenance of YAML manifests for Kubernetes objects by packaging information into charts and advertises them to a Kubernetes cluster.
Helm keeps track of the versioned history of every chart installation and change. Starting from Rolling back to a previous version or upgrading to a newer version can be acheived with simple commands.
Following is the list of operation can be performed with the help of Helm commands.
Helm Operational Architecture
Helm has a very simple client-server architecture which includes a CLI client and an server named as Tiller running in the Kubernetes cluster as shown in following figure. The Helm client pushes resources to the Kubernetes cluster using the gRPC (Remote Procedure Call) framework.
This architecture is depend on the Helm 2 or Helm 3. Helm 2 uses Tiller while Helm 3 got rid of Tiller and entirely relies on the Kubernetes API Server.
- Helm Client: It provides the developer to use it a command-line interface (CLI) to work with Charts, Config, Release, Repositories. Helm Client will interact with Tiller Server, to perform various actions such as install, upgrade and rollback with Charts, Release.
- Tiller Server: It is an in-cluster server in the Kubernetes cluster, ther accept the Helm Client and execute them on Kubernetes Cluster with the help of Kubernetes API server. This is essentially a pod
- Chart(s): It is a collection of yaml files of (deployment, service, configmap, etc) for now. These can be customized as required during installation.
- Chart repository : This is an optional component. It’s a server that would store the charts. helm client can search and fetch these charts for installation/upgrade on a kubernetes cluster. Example: Harbor
Helm Chart Structure
Following picture shows the structure for Helm Chart. It contains some folders and files required for managing the CNFs in Kubernets Clusters.
- charts/: It is a directory/folder to manually managed chart dependencies.
- templates/: It is a directory/folder contains template files written in Golang and combined with configuration values from the values.yaml file to generate Kubernetes manifests.
- Chart.yaml: It is a file having metadata about the chart, such as the version, name, search keywords, etc.
- values.yaml: It is a file ving default configuration values for the chart.
- LICENSE (optional): It an optional plain text file having License information for the chart
- README.md (optional): It an optional plain text file having readable information for the users of the chart.
- requirements.yaml (optional): It is a yaml file List of chart’s dependencies
- Heml Sh
- Kubernetes Helm arcitle by Huy Du
- Kubernetes – Kubectl working and Common Commands
- Open Stack, its components and deployment models
- Open Stack Undercloud and Overcloud
- Network Function Virtualization (NFV)