Helm is a package manager for kubernetes. It manages Kubernetes “charts”, which are “preconfigured packages of Kubernetes resources.” Helm enables you to easily install packages, make revisions, and even roll back complex changes and it provides functions that are like a package manager for an operating system:
- Helm follows a common format and directory structure for packaging your Kubernetes resources, known as a Helm chart.
- The Helm client software offers commands for: listing and searching for charts by keyword, installing applications to your cluster from charts, upgrading those applications, removing applications, and other management functions.
- Helm also provides a public repository of charts for common software. You can also retrieve charts from third-party repositories, author and contribute your own charts to someone else’s repository, or run your own chart repository.
Helm 3
Here are the major changes for Helm 3. If you like to get complete list of changes, see the FAQ.
- The most notable change in Helm 3 was tiller removed. With role-based access controls (RBAC) enabled by default in Kubernetes 1.6+, Tiller became unnecessary and was removed.
- Upgrading a chart is better than ever. Helm 3 introduces a 3-way merge patch, an improvement over Helm 2’s 2-way approach. Helm is now able to consider the old manifest, the current state, and the new manifest, instead of just the most recent manifest and the proposed changes. The 3-way merge patch helps to ensure that a user can roll back changes regardless of how they’re applied.
- Release names in Helm 3 are scoped to the namespace and have a sh.helm.release.v1 prefix.
- Secrets are used as the default storage driver for releases.
- The Go import path has changed from k8s.io/helm to helm.sh/helm/v3.
- A JSON Schema can now be imposed upon chart values. This ensures that values provided by the user follow the schema laid out by the chart maintainer, providing better error reporting when the user provides an incorrect set of values for a chart. Validation occurs when any of the following commands are invoked:
- helm install
- helm upgrade
- helm template
- helm lint
- The .Capabilities built-in object available during the rendering stage has been simplified.
- requirements.yaml has been folded into Chart.yaml as the dependencies field.
- Helm 3 now supports Library charts. These are shared by other charts and are intended to be reused to avoid redundancy.
- Removal of helm serve
- Helm 3 has moved to XDG Base Directory Specification. This means instead of Helm 2’s $HELM_HOME location, you will find information stored in the following:
- XDG_CACHE_HOME
- XDG_CONFIG_HOME
- XDG_DATA_HOME
- Helm Hub – Helm 3 does not come with chart repositories loaded out of the box. Instead, there is now a central hub for charts called Artifacthub.
Details about Migrating from Helm 2 to Helm 3
Helm has provided a plugin to migrate your projects from Helm 2 to Helm 3 called helm-2to3 plugin. This plugin works in three stages. First it migrates the configuration, then the release, then it cleans up the configuration, release data, and Tiller.
Charts
The components of a Kubernetes application–deployments, services, ingresses, and other objects–are listed in manifest files (in the YAML file format). Kubernetes does not tell you how you should organize those files, though the Kubernetes documentation does offer a general set of best practices.
Helm charts are the software packaging format for Helm. A chart specifies a file and directory structure that you follow when packaging your manifests. The structure looks as follows:
Now let’s see in detail about each file or directory,
| File or Directory | Description |
| Chart.yaml | General information about the chart, including the chart name, a version number, and a description. Charts can be of two types, application, or library. Set this with the type field. Application is the default. You can also set a chart to be deprecated with the optional deprecated field. Note the apiVersion field for Helm 3 will be v2. v1 charts can still be installed by Helm 3 but the dependencies field is in a separate requirement.yaml file for v1 charts. Note also that the appVersion field is different from the version field, where version references the chart version and appVersion references the application version. |
| LICENSE | A plain-text file with licensing information for the chart and for the applications installed by the chart. Optional. |
| README.md | A Markdown file with instructions that a user of a chart may want to know when installing and using the chart, including a description of the app that the chart installs and the template values that can be set by the user. Optional. |
| templates/NOTES.txt | A plain-text file which will print to a user’s terminal when they install the chart. This text can be used to display post-installation instructions or other information that a user may want to know. Optional. |
| charts/ | A directory which stores chart dependencies that you manually copy into your project, instead of linking to them from the Chart.yaml file’s dependencies field. |
| values.yaml | Default values for the variables in your manifests’ templates. |
| templates/ | Your Kubernetes manifests are stored in the templates/ directory. Helm will interpret your manifests using the Go templating language before applying them to your cluster. You can use the template language to insert variables into your manifests, and users of your chart will be able to enter their own values for those variables. |
| Custom Resource Definitions (CRDS) | In Helm 3 CRDS are a special type of global object and are installed first. They should be placed in the crds/ directory inside of the chart. You can have multiple CRDs in the same file if they are separated by YAML start and end markers. Note, these are only installed once and will not be upgraded or rolled back. Additionally, deleting a CRD deletes all that CRD’s contents across all namespaces in the cluster. Therefore, Helm does not do this. You can do it manually, carefully. Alternatively, you can skip with the –skip-crds option. |
Helm Client
The Helm client tool helps you to run the commands in CI/CD pipeline, which simplifies your deployments.
Note: This post assumes you have installed and configured kubernetes already. If not please follow, Below link for setup on ubuntu and centos/Redhat
Ubuntu: https://foxutech.com/how-to-setup-kubernetes/
Centos/Redhat: https://foxutech.com/how-to-setup-kubernetes-on-centos-redhat/
Install Helm
Here is the steps to install helm client,
Linux – need to run the client installer script that Helm provides:
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 > get_helm.sh chmod 700 get_helm.sh ./get_helm.sh
macOS – Use Homebrew to install:
brew install helm
Windows – Use Chocolatey to install:
choco install kubernetes-helm