Kubernetes standard way of deploying application (deployment, service, ingress etc.) is using yaml manifests. It is very tedious and error prone to manage yaml manifests. This is not the only problem with using yaml manifests. Imagine if you have multiple environments aka dev, staging and production. You need to implement different resource limits or download docker images from different repositories (which is often the case in almost all organisations). Managing all these with yaml manifests means you need to manage multiple manifests for an application, one for each environment. Imagine how error prone it could be, if anyone missed changing production manifests makes production configuration drift away from other environments. So, we need a better way to manage deployments.
Enter helm. “Helm is package manager for kubernetes” as per official documentation. Helm Charts help you define, install, and upgrade even the most complex Kubernetes application. Next comes the question, what is helm chart. Helm packages are called charts, and they consist of a few YAML configuration files and some templates that are rendered into Kubernetes manifest files. Looking at this definition, helm also uses yaml manifests, but it allows you to template these files so that you can use same chart for deploying across all environments.
Helm Chart Structure
Here is basic structure of helm chart.
Charts/ — This directory contain charts of dependencies
templates/ — This directory contain various yaml manifests templates.
Chart.yaml — It contains information about chart, name, version, maintainer etc.
LICENSE — License of chart
README.md — Readme file that contains information for users of chart
requirements.yaml — This file contains list of chart dependencies
values.yaml — This file contains configuration values of chart. This combined with templates render kubernetes manifests. The values here are default values and can be overridden while deploying.
Looking at the helm chart structure, once can have a helm chart (for a product) with all dependencies listed. This makes it easy to version product with associated components.
Helm Chart Creation
One can create helm chart using helm create <chartname>. This method is useful to create one-off chart. If you want this process to be part of your CI/CD pipeline, we need a better method. Helm supports various functions like range, conditional statements like if, loops like for. One could leverage these to create template that encompasses all your service requirements (like environment values, configmaps, secrets, persistentdisks, affinity/antiaffinity rules etc.). This helm service template can be used in your CI/CD pipeline to create helm charts.
Here is an example on how this can be done.
Let’s say we have helm service templates stored under git. Storing these in in git enables revision control and central location to modify and propagate changes. Each service will have it’s own values.yaml file with customised values for each environment. During CI/CD process, just copy helm service templates from git, copy values.yaml and Chart.yaml from service repo. With proper documentation and training, your engineering team can create values.yaml and Chart.yaml themselves without any help from DevOps team. This reduces time to bring new applications for testing as users don’t need to know nuances of creating helm chart.
Helm Chart Repository
Just like docker registry that stores docker images, helm charts also need central location from which users can share charts with others. This is called helm repository. There are few open source products that can be used as helm repositories like Chartmuseum, harbor (harbor can act as docker registry and helm repository).
Helm has two components, tiller and helm. Tiller is server component of helm and needs to be installed on kubernetes cluster. Helm is client component, should be installed on the machine or laptop that interacts with kubernetes and deploy applications. Tiller component performs privileged operations for co-ordinating deployments with API server and require permissions for the same. Installing it adds one more service to manage and since this needs additional privileges, it should be secured enough. To avoid this, helm community voted for tiller-less helm and we will see this in helm v3. However, there is a plugin called tiller that enables one to install, delete, upgrade (all operations that one can do with tiller and helm) without installing server component onto cluster.
Above, we have discussed how flexible it is to use helm for deployments. However, this is not the only advantage of using helm. Helm chart default values can be overridden during deployment to suit the needs. After deployment, in case one need to verify the values used, it is very easy to get them using
helm get values <release> Not only that, same helm chart can be deployed multiple time with unique release name in scenarios like deploying multiple databases etc.
Helm releases can be upgraded on the fly using
helm upgrade This looks for corresponding release and upgrades it. During this operation, it preserves the values and information about previous release. If some one want to roll back to previous release, it can be done quickly and easily as the information is already stored by helm. Another advantage of using helm which everyone should use (especially for persistent disk) is delete protection. This is done through annotation on the resources that should be protected and helm takes care of not touching those even during
helm delete operation. This is very useful in preserving resources from accidental deletion which is recipe for most outages.
All in all, helm is becoming de-facto standard for kubernetes deployments and we really encourage everyone to take advantage of all functionality provided by helm and hope helm 3 is going to be having lot more useful features.
We will meet you in another post and until then have a nice time.