Helm →The ship controller

What is Helm →

Helm is the packaging manager of Kubernetes just like we use apt or yum in linux to install or unpack anything here we use helm to unpack the predefined packages (i.e deployment file , service file etc….) of kubernetes which is written by someone else what we need to do just get that package using helm stored in helm hub and start using our application

why we use Helm →

Writing and managing Kubernetes manifest for all the required K8S needs objects can be a time consuming and tedious tasks for a simplest of deployments you would need at least 3 yaml manifest with duplicated and hard coded values

Helmet simplifies this process and create a single package that can be advertised to your cluster

Helm 3 was released in November 2019 helm k8s automatically maintain a database of all versions of your release so whenever something goes wrong during deployment rolling back to the previous version is just one command away

Important Terms in HELM →

1. Chart → In the above definations we discussed about the packages of yaml files of kubernetes these packages is called helm charts. Helm charts are simply k8s yaml manifest combined into a single package that can be advertised to your cluster
2. Release → A release is an instance of a chart running in a k8s cluster one chart can often be installed many times into the same cluster and each time it is installed a new release is created…. consider a mysql chart , if you can install that chart twice each one will have it’s own release , which in turn have it’s own release name

Helm keep tracks of all chart execution (install/upgrade/rollback)

3. Repository →Location where packaged chart can be stored and shared

Architecture of Helm 3 →

1. Helm 3 is a single service architecture one executable is responsible for implementing helm there is no client server split nor is the core processing logic distributed among components
2. Implementation of helm 3 is a single service CMD line , client with no in cluster server or controller this tool exposes command line operation and unilaterally hands the package management process
3. Helm client and library Written in ‘go’ language

Architecture of helm 3

Helm 2 Vs Helm 3 →

Imagine you’re building a castle. In this castle, you want to have different rooms, like a kitchen, a bedroom, and a library. Now, think of Helm as a magical tool that helps you build these rooms in your castle, but in a smarter way.

• Helm 2 is like having a genie who can grant you wishes, but sometimes it gets confused because it can’t remember which wishes it granted before. So, it might mix up things, like using the wrong size furniture in your rooms or forgetting where it put the doors.
• Helm 3, on the other hand, is like having a super organized architect who keeps track of everything perfectly. It knows exactly what you asked for and makes sure everything is in the right place. It’s like having a blueprint for your castle that’s clear and easy to understand.

So, while both Helm 2 and Helm 3 help you build your castle (or in tech terms, manage your applications), Helm 3 does it in a much smarter and organized way, making it easier to manage and understand what’s going on

Let’s delve deeper into the specifics of Helm 2 and Helm 3.

Helm 2:

1. Tiller Component:

• Helm 2 relies on a server-side component called Tiller to manage installations, upgrades, and deletions of charts. Tiller interacts directly with the Kubernetes API server to make changes to the cluster.
• The presence of Tiller poses security concerns because it has broad permissions within the Kubernetes cluster.

2. Release Management:

• In Helm 2, releases (instances of installed charts) are tracked within the cluster by Tiller.
• Tiller keeps track of all installed releases in its release history, which can sometimes lead to inconsistencies or conflicts.

3. Chart Repository:

• Helm 2 uses a centralized Chart Repository to store and distribute Helm charts.
• Chart repositories can be hosted anywhere, but the default public repository is maintained by the Helm project.

4. Dependency Management:

• Helm 2 supports managing dependencies between charts using a separate requirements.yaml file.
• Dependencies are resolved and downloaded by Helm during chart installation.

5. Configuration Overrides:

• Values for chart configurations are typically provided via values.yaml files or through command-line flags during installation.
• Values can be overridden using environment variables or templating functions.

Helm 3:

1. Removal of Tiller:

• Helm 3 removes the Tiller component entirely, eliminating the security concerns associated with it.
• All Helm operations in Helm 3 interact directly with the Kubernetes API server using the Kubernetes client libraries.

2. Release Management:

• Without Tiller, Helm 3 stores release information as Kubernetes objects within the cluster, removing the need for a separate release-tracking component.
• Helm 3 introduces a more robust release management system, improving reliability and consistency.

3. Chart Repository:

• Helm 3 maintains compatibility with Helm 2 chart repositories but introduces improvements for managing repositories.
• Helm 3 provides better support for OCI (Open Container Initiative) registries, enabling the use of OCI artifacts as charts.

4. Dependency Management:

• Helm 3 simplifies dependency management by integrating it directly into the Helm core.
• Dependencies are managed using the helm dependency command, and the requirements.yaml file is no longer needed.

5. Configuration Overrides:

• Helm 3 retains the ability to override chart configurations using values.yaml files or command-line flags.
• Values can also be provided inline using the --set flag during installation or upgrade.

Summary:

• Helm 2 relies on Tiller for managing releases, which introduces security and scalability concerns.
• Helm 3 removes Tiller, improving security and simplifying release management.
• Helm 3 introduces enhancements for chart repository management, dependency handling, and configuration overrides.
• Overall, Helm 3 offers a more streamlined and secure experience for managing Kubernetes applications compared to Helm 2.

Helm Commands →

1. helm install:

• This command is used to install a chart onto your Kubernetes cluster.
• Syntax: helm install [RELEASE_NAME] [CHART] [flags].

2. helm uninstall:

• Uninstalls a named release.
• Syntax: helm uninstall [RELEASE_NAME] [flags].

3. helm upgrade:

• This command is used to upgrade a release to a new version of a chart.
• Syntax: helm upgrade [RELEASE_NAME] [CHART] [flags].

4. helm rollback:

• Rolls back a release to a previous revision.
• Syntax: helm rollback [RELEASE_NAME] [REVISION] [flags].

5. helm list:

• Lists all releases.
• Syntax: helm list [flags].

6. helm show:

• Displays information about a chart.
• Syntax: helm show [chart/chart_name] [flags].

7. helm search:

• Searches for charts in repositories.
• Syntax: helm search [keyword] [flags].

8. helm package:

• Packages a chart directory into a chart archive.
• Syntax: helm package [CHART_PATH] [flags].

9. helm repo add:

• Adds a chart repository to Helm.
• Syntax: helm repo add [NAME] [URL] [flags].

10. helm repo remove:

• Removes a chart repository from Helm.
• Syntax: helm repo remove [NAME] [flags].

11. helm repo update:

• Updates the local repository cache.
• Syntax: helm repo update [flags].

12. helm dependency build:

• Builds the dependencies for a chart.
• Syntax: helm dependency build [CHART_PATH] [flags].

13. helm dependency list:

• Lists the dependencies for a chart.
• Syntax: helm dependency list [CHART_PATH] [flags].

14. helm lint:

• Checks a chart for issues.
• Syntax: helm lint [CHART_PATH] [flags].

15. helm create:

• Creates a new chart with the given name.
• Syntax: helm create [CHART_NAME] [flags].

16. helm get:

• Gets the details of a named release.
• Syntax: helm get [VALUES] [RELEASE_NAME] [flags].

17. helm template:

• Renders the template files locally.
• Syntax: helm template [RELEASE_NAME] [CHART] [flags].

18. helm completion:

• Generates autocompletions for the specified shell.
• Syntax: helm completion [SHELL] [flags]

Installation of helm →

curl https://baltocdn.com/helm/signing.asc | gpg — dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null

sudo apt-get install apt-transport-https — yes

echo “deb [arch=$(dpkg — print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main” | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list

sudo apt-get install helm

Points to remember →

1. Helm introduced first time in 2015
2. Helm is the K8S equilvalent of yum or apt
3. Helm is now an official k8S Project and is part of CNCF
4. The main building block of helm based deployments are help charts these charts describe a configurable set of dynamically generated k8s resourses
5. The chart can either be restored locally or fetched from remote chart repository called helm hub just like for git there is github and for docker there is dockerhub