HELM for Begineers
What is HELM?
Helm is a package manager for Kubernetes, designed to simplify the process of deploying and managing applications on Kubernetes clusters. It allows you to define, install, and upgrade complex Kubernetes applications using "charts".
A Helm chart is a collection of files that describe a related set of Kubernetes resources. These charts can define all aspects of an application, including configurations, deployments, services, and other resources required to run the application.
Installation and Configuration
Prerequisites for using HELM:
A Kubernetes cluster (can be local or on the cloud like AWS, GCP, or Azure).
kubectl
installed and configured to communicate with Kubernetes cluster.
Install Helm
Using Package Managers:
For systems with
snap
:$ sudo snap install helm --classic
For systems with
apt
(Ubuntu/Debian):$ curl https://baltocdn.com/helm/signing.asc | sudo apt-key add - sudo apt-get install apt-transport-https --yes echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm
Verify the installation:
$ helm version
Configure Helm
- Helm 3 does not require
helm init
because it doesn't use Tiller. Helm is ready to use immediately after installation.
HELM Components
Helm command line utility (
helm cli
) helps to perform helm actions, such as installing a chart, upgrading, rollback, etc.A chart is a collection of files. They contain all the instructions that helm need to know to be able to create the collection of objects that we need in the Kubernetes cluster.
By using charts, and adding the objects according to the specific instructions in the charts, helm in a way, installs applications into the cluster.
When a chart is applied to the cluster, a release is created. A release is a single installation of an application using a helm chart.
Within each release, we can have multiple revisions, and each revision is like a snapshot of the application.
Every time a change is made to the application such as an upgrade of the image or change of replicas or configuration objects, a new revision is created.
Just like we can find all kind of images on DockerHub, we can find, download and use a helm charts from a public repository to deploy the application directly on the cluster.
Finally, to keep the track of what helm did in the cluster, such as the releases that it installed, the charts used, revision state, etc. helm need a place to save this data. This data is know as metadata.
Helm does not save this data on our local computer, because if another person need to work with our releases through helm, they would need a copy of this data. Instead, helm this metadata directly in our Kubernetes cluster as Kubernetes Secrets.
This way the data survives and as long as the Kubernetes cluster survives, everyone (who is having access to the cluster and secrets) can access it.
HELM Charts
Charts are a collection of files.
They contain all the instructions that helm need to know to be able to create the collection of objects that we need in the Kubernetes cluster.
The
values.yaml
file in a Helm chart is a core component that allows to define configuration settings or inputs for the Kubernetes application.It contains default values that are used to customize the behavior of the resources defined in the Helm chart.
HELM Releases
When a chart is applied to the cluster, a release is created. A release is a single installation of an application using a helm chart.
Installing a helm chart:
# helm install [release-name] [chart-name] $ helm install my-first-site bitnami/wordpress
In above command, we are using a chart named
bitnami/wordpress
and named the releasemy-site
.Why not just use a shorter command like
helm install bitnami/wordpress
without specifying any name?The reason to have a release name based on a chart is that we can install multiple releases based on the same chart so we can launch other releases with different release names.
$ helm install my-second-site bitnami/wordpress
- Since there are two different releases, they can be tracked separately and changed independently (even though they are based on the same chart).
HELM Repositories
Thousands of charts are readily available at different Helm Repositories.
A Helm repository is a location where Helm charts are stored and can be shared, discovered, and downloaded.
There are different providers who are hosting helm repositories such as AppsCode, Community Operators, Truecharts, Bitnami, etc. But we don’t need to go to these repositories to search for the charts.
All of these repositories have listed their charts in a single location known as the Helm Hub or Artifact Hub (artifacthub.io).
HELM Charts
Charts are a collection of files.
They contain all the instructions that helm need to know to be able to create the collection of objects that we need in the Kubernetes cluster.
Components of a Helm Chart
A Helm chart consists of the following key components:
Chart.yaml
– Metadata about the chart (name, version, description, dependencies, etc.).values.yaml
– Default configuration values that can be customized.templates/
– Contains Kubernetes resource templates (e.g., Deployments, Services, ConfigMaps).charts/
– Any dependencies required by the chart.README.md
– Documentation about the chart and how to use it.
Helm Chart Structure
my-nginx-chart/
├── charts/
├── templates/
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── _helpers.tpl
├── Chart.yaml
├── values.yaml
Chart.yaml
The
Chart.yaml
file is a mandatory component of a Helm chart that contains metadata about the chart.It provides essential information such as the chart's name, version, description, and dependencies.
Structure of Chart.yaml
apiVersion: v2
name: my-chart
description: A Helm chart for deploying a web application
type: application
version: 1.0.0
appVersion: 2.3.4
keywords:
- web
- application
- nginx
home: https://example.com
sources:
- https://github.com/example/my-chart
maintainers:
- name: Jane Doe
email: jane.doe@example.com
url: https://example.com/jane
dependencies:
- name: redis
repository: https://charts.bitnami.com/bitnami
version: 6.0.0
condition: redis.enabled
tags:
- backend
- name: postgres
repository: https://charts.bitnami.com/bitnami
version: 11.0.0
condition: postgres.enabled
icon: https://example.com/icon.png
Key Fields in Chart.yaml
apiVersion
:Specifies the chart API version.
Helm 3 supports only
v2
.This field does not exists in Helm 2.
name
:The name of the chart.
Should match the directory name containing the chart.
description
:- A short description of the chart.
type
:There are 2 type of charts:
application
for deployable applications.library
for reusable charts (provides utilities that help in building charts).
Default:
application
.
version
:- The version of the chart itself.
appVersion
:The version of the application being deployed (not tied to the chart version).
This field is for information purpose only.
keywords
:- A list of keywords to help users search for the chart.
home
:- The URL of the chart’s home page or project.
sources
:- A list of source URLs for the chart, such as a GitHub repository.
maintainers
:A list of maintainers for the chart.
Each maintainer has:
name
: The name of the maintainer.email
: Their email address (optional).url
: A profile or homepage URL (optional).
dependencies
:A list of other charts this chart depends on.
Each dependency includes:
name
: The name of the dependency.repository
: The URL of the dependency’s repository.version
: The version of the dependency.condition
: A condition for enabling/disabling the dependency (optional).tags
: Tags used to group dependencies (optional).
icon
:- A URL to an icon for the chart, displayed in UIs like Artifact Hub.
Working with Helm: Basics
helm
orhelm --help
: Lists the helpful information.$ helm --help The Kubernetes package manager Common actions from this point include: - helm search: search for charts - helm pull: download a chart to your local directory to view - helm install: upload the chart to Kubernetes - helm list: list releases of charts Environment variables: | Name | Description | |------------------------------------|------------------------------------------------------------------------------------------| | $XDG_CACHE_HOME | set an alternative location for storing cached files | | $XDG_CONFIG_HOME | set an alternative location for storing Helm configuration | | $XDG_DATA_HOME | set an alternative location for storing Helm data | | $HELM_DRIVER | set the backend storage driver. Values are: configmap, secret, memory, sql | | $HELM_DRIVER_SQL_CONNECTION_STRING | set the SQL connection string, only applicable when $HELM_DRIVER is set to "sql" | | $HELM_NO_PLUGINS | disable plugins | | $KUBECONFIG | set an alternative Kubernetes configuration file (default "~/.kube/config") | | $HELM_REGISTRY_CONFIG | set the path to the registry configuration file (default "~/.config/helm/registry.json") | | $HELM_REPOSITORY_CACHE | set the path to the repository cache directory (default "~/.cache/helm/repository") | | $HELM_REPOSITORY_CONFIG | set the path to the repositories file (default "~/.config/helm/repositories.yaml") | Usage: helm [command] Available Commands: completion Generate the autocompletion script for the specified shell create Create a new chart with the given name dependencies Manage a chart's dependencies env Helm client environment information get Download extended information of a named release help Help about any command history Fetch release history install Install a chart lint Examine a chart for possible issues list List releases package Package a chart directory into a chart archive plugin Install and use plugins pull Download a chart from a repository and (optionally) unpack it in local directory repo Add, list, remove, update, and index chart repositories rollback Roll back a release to a previous revision search Search for a keyword in charts show Show information of a chart status Display the status of the named release template Locally render templates test Run tests for a release uninstall Uninstall a release upgrade Upgrade a release verify Verify a chart version Print the client version information Flags: --debug enable verbose output -h, --help help for helm --kube-apiserver string the address and the port for the Kubernetes API server --kube-as-group stringArray group to impersonate for the operation, this flag can be repeated to specify multiple groups. --kube-as-user string username to impersonate for the operation --kube-ca-file string the certificate authority file for the Kubernetes API server connection --kube-context string name of the kubeconfig context to use --kube-insecure-skip-tls-verify if true, the Kubernetes API server's certificate will not be checked for validity. This will make your HTTPS connections insecure --kube-token string bearer token used for authentication with the Kubernetes API server --kubeconfig string path to the kubeconfig file --namespace string namespace scope for this request --registry-config string path to the registry config file (default "~/.config/helm/registry.json") --repository-cache string path to the file containing cached repository indexes (default "~/.cache/helm/repository") --repository-config string path to the file containing repository names and URLs (default "~/.config/helm/repositories.yaml") Use "helm [command] --help" for more information about a command.
We can also use this help feature for subcommands:
helm repo --help
: Shows how we can add chart repository or list chart repository or remove chart repository, etc.
We can dig deeper and learn about what a subcommand does:
helm repo update --help
: Shows the command’s short description, usage and alias.
helm search wordpress
: To search for a chart. It expects an additional subcommand specifying where to search.helm search hub wordpress
:hub
refers to the Artifact hub (artifacthub.io).helm search repo wordpress:
To search in a specific repository (added already on local).
Once we have identified the chart to install, we can deploy the application using 2 commands:
helm repo add bitnami https://charts.bitnami.com/bitnami
: To add the repository to our local Helm setup.helm install my-release bitnami/wordpress
: To install or deploy the application to our cluster.
Once a chart is deployed, it is deployed as a release.
helm list
: To list all existing releases.
helm uninstall my-release
: To remove/delete the application deployed (release).helm repo
: To list, add, remove or update helm repositories.
Customizing Chart Parameters
When we install a chart, let’s say
wordpress
, we installed everything with its default value, but we may not want to do that all the times.When we install wordpress application with a Helm chart, we did it with a single command.
helm install my-release bitnami/wordpress
This command pulls the chart and deploys the application instantly, so there is no window to modify the values in
values.yaml
file.One way we could modify some of the default values is by passing in a command line parameter along with the
helm install
command using theset
option.helm install --set wordpressBlogName="Helm Tutorials" my-release bitnami/wordpress
With the
--set
option, we can pass in any field from thevalues.yaml
file and set a value for it in a command line (this overrides the values set invalues.yaml
file).If there are too many of these values, then another option is to move these to our own
custom-values.yaml
file and pass in this file using--values
options.helm install --values custom-values.yaml my-release bitnami/wordpress
To modify the built-in values, instead of running the
helm install
command, we can break it up into 2 commands.helm pull bitnami/wordpress
- Pulls the chart- This pulls the chart in an archive or compressed form (need to unarchive it manually).
OR
helm pull --untar bitnami/wordpress
- Pulls the chart and unarchive it.- This creates a directory with the name
wordpress
.
- This creates a directory with the name
helm install my-release ./wordpress
- To install the chart with the modifiedvalues.yaml
HELM Lifecycle Management
- Helm lifecycle management refers to the process of managing the full lifecycle of Kubernetes applications using Helm. This includes installation, upgrades, rollbacks, configuration, and uninstallation of applications deployed via Helm charts.
Key Stages of Helm Lifecycle Management
Install (Deploying a Helm Chart)
The first step is to deploy an application using a Helm chart.
Helm applies the Kubernetes manifests defined in the chart.
# syntax $ helm install my-release my-chart # example $ helm install my-nginx bitnami/nginx
my-release
: Name of the Helm release.my-chart
: The Helm chart being installed.
Upgrade (Updating an Existing Release)
When a new version of the application or configuration is needed, Helm allows upgrades.
Helm upgrades the release without downtime (if possible) while keeping track of previous versions.
# syntax $ helm upgrade my-release my-chart # example $ helm upgrade my-nginx bitnami/nginx
Rollback (Reverting to a Previous Version)
If an upgrade causes issues, Helm allows rolling back to a previous release version.
# syntax $ helm rollback my-release <revision_number> # example $ helm rollback my-nginx 1
Uninstall (Removing a Helm Release)
When an application is no longer needed, it can be uninstalled using Helm.
By default, Helm keeps the release history unless explicitly deleted.
# syntax $ helm uninstall my-release # example $ helm uninstall my-nginx
Deleting the Release History (Permanent Cleanup)
$ helm uninstall my-nginx --keep-history $ helm delete my-nginx
Helm Release Management (Tracking and Debugging)
Helm maintains the history of all releases and their revisions.
Check Helm Release Status
$ helm status my-release
View Helm Release History
$ helm history my-release
Check Values of a Deployed Release
$ helm get values my-release
View Kubernetes Manifests Applied by Helm
$ helm get manifest my-release
Debug a Helm Release
$ helm install --dry-run --debug my-release my-chart