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:

  1. A Kubernetes cluster (can be local or on the cloud like AWS, GCP, or Azure).

  2. 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 release my-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:

  1. Chart.yaml – Metadata about the chart (name, version, description, dependencies, etc.).

  2. values.yaml – Default configuration values that can be customized.

  3. templates/ – Contains Kubernetes resource templates (e.g., Deployments, Services, ConfigMaps).

  4. charts/ – Any dependencies required by the chart.

  5. 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

  1. apiVersion:

    • Specifies the chart API version.

    • Helm 3 supports only v2.

    • This field does not exists in Helm 2.

  2. name:

    • The name of the chart.

    • Should match the directory name containing the chart.

  3. description:

    • A short description of the chart.
  4. type:

    • There are 2 type of charts:

      • application for deployable applications.

      • library for reusable charts (provides utilities that help in building charts).

    • Default: application.

  5. version:

    • The version of the chart itself.
  6. appVersion:

    • The version of the application being deployed (not tied to the chart version).

    • This field is for information purpose only.

  7. keywords:

    • A list of keywords to help users search for the chart.
  8. home:

    • The URL of the chart’s home page or project.
  9. sources:

    • A list of source URLs for the chart, such as a GitHub repository.
  10. 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).

  11. 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).

  12. icon:

    • A URL to an icon for the chart, displayed in UIs like Artifact Hub.

Working with Helm: Basics

  1. helm or helm --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.
  2. 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).

  3. 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.

  4. Once a chart is deployed, it is deployed as a release.

    • helm list: To list all existing releases.
  5. helm uninstall my-release: To remove/delete the application deployed (release).

  6. 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 the set option.

    helm install --set wordpressBlogName="Helm Tutorials" my-release bitnami/wordpress

  • With the --set option, we can pass in any field from the values.yaml file and set a value for it in a command line (this overrides the values set in values.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.

    1. helm pull bitnami/wordpress - Pulls the chart

      • This pulls the chart in an archive or compressed form (need to unarchive it manually).

OR

  1. helm pull --untar bitnami/wordpress - Pulls the chart and unarchive it.

    • This creates a directory with the name wordpress.
  2. helm install my-release ./wordpress - To install the chart with the modified values.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

  1. 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.

  1. 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
    
  1. 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
    
  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
    
  1. 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