What is Helm?

1. Helm is a Package Manager for Kubernetes.

a. Helm is a tool for managing Kubernetes Packages called Charts.
b. A chart is a collection of files that describe a related set of Kubernetes resources.
Eg: Install mysql Package
helm install mysql stable/mysql – like apt install mysql
helm upgrade mysql stable/mysql - apt update

Note: Helm Compares Old Chart, New Chart and Live State and creates a new Patch that updates the cluster.
2. Helm is a Templating Engine.
a. We can define a common blueprint (template) for multiple YAML files.
b. In a template file, dynamics values replaced their placeholders. The values come from a file called
values.yaml.

3. Helm is used for Release Management

a. A release is a running instance of a chart, combined with a specific config.
b. The config contains configuration information that can be merged into a packaged chart to create
a releasable object.
c. Helm also keeps a release history of all deployed charts, so you can go back to a previous release if
something went wrong.

Helm can do the following:

 Create new charts from scratch.
 Package charts into chart archive (tgz) files.
 Interact with chart repositories where charts are stored.
 Install and uninstall charts into an existing Kubernetes cluster.
 Manage the release cycle of charts that have been installed with Helm.

Why to use Helm?

1. Find prepackaged software (charts) to install and use.
2. Easily create and host your own packages.
3. Install packages into any Kubernetes cluster.
4. Query the cluster to see what packages are installed and running.
5. Update, delete and rollback or view the history of installed packages.
6. Helm makes it easy to run applications inside Kubernetes.

Helm versions.

 Helm client will send YAML files to Tiller.

 Tiller then runs these YAML files in Kubernetes cluster to create Kubernetes components.
 Whenever you create or change deployment, tiller will store a copy of each configuration. Tiller keeps history
of charts executions. This will help in applying changes to existing deployment instead of creating a new one.

Downside of this setup:

Tiller has too much power inside the Kubernetes cluster – Security issue.
 Installing Helm
https://helm.sh/docs/intro/install/

Installing on Windows

choco install kubernetes-helm

Installing on Linux
curl https://get.helm.sh/helm-v3.8.2-darwin-amd64.tar.gz
tar -zxvf helm-v3.0.0-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm
helm version --short

To add existing Packages - Installing Official Helm Charts Repository

helm repo add stable https://charts.helm.sh/stable

Working with Helm Charts

Charts allow you to version your manifest files too, just like we do with Node.js or any other package. This lets you
install specific chart versions, which means keeping specific configurations for your infrastructure in the form of
code.
To create a Helm Chart:
helm create mywebchart
mywebchart/
Chart.yaml # A YAML file containing information about the chart
values.yaml # The default configuration values for the templates in the chart.
charts/ # A directory containing any charts upon which this chart depends.
templates/ # A directory of templates that, when combined with values, will generate valid
Kubernetes manifest files.
crds/ # Custom Resource Definitions
README.md # OPTIONAL: A human-readable README file
LICENSE # OPTIONAL: A plain text file containing the license for the chart
templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes
values.schema.json # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file
Note: Helm reserves use of the charts/, crds/, and templates/ directories, and of the listed file names. Other
files will be left as they are.

Overview Chart.yaml

 apiVersion – Helm API Version (V2 is for Helm3)

 appVersion – Application Version
 version – Chart Version
Chart Types:
 There are two types: application and library.
 Application is the default type and it is the standard chart which can be operated on fully.
 The library chart provides utilities or functions for the chart builder.
 A library chart differs from an application chart because it is not installable and usually doesn't contain any
resource objects.

Note: Helm does not wait until all of the resources are running before it exits. Many charts require Docker
images that are over 600M in size, and may take a long time to install into the cluster.

Notes:
 Chart is the definition of our Application
 Release is the instance of the chart running in the Kubernetes cluster.
 Release revision: Change the existing YAML files and update the chart.
 Chart Version refers to the change in chart file structure. You may add new YAML files to chart.

Helm Commands
 helm create [chart]
 helm install [release] [chart] Install a Release
 helm upgrade [release] [chart] Upgrade a Release version
 helm rollback [release] [version] Rollback to a Release version
 helm history [release] Print Release history
 helm status [release] Display Release status
 helm get all [release] Show details of a release
 helm uninstall [release] Uninstall a Release
 helm list List Release

Install chart into Kubernetes Cluster:

 helm create mywebappchart
 helm install --dry-run demo-mywebapp mywebappchart
 helm install demo-mywebapp mywebappchart
 helm list --short
 helm get manifest demo-mywebapp
 helm get all demo-mywebapp
Version updates:
1. helm status demo-mywebapp
Note the REVISION=1
2. Change the App Version in Chart.yaml
3. Change the Image to new version in deployment.yaml
4. helm upgrade demo-mywebapp mywebappchart
5. helm status demo-mywebapp
Note the REVISION=2 and kubectl

Rollback:
1. helm history demo-mywebapp
2. helm rollback demo-mywebapp 1
3. helm history demo-mywebapp

Uninstall:
helm uninstall demo-mywebapp

Helm Templates
Helm Template Engine:
It works on client side.

Replacing place holders with their values from different sources:

Using values from Values.
Build-In values as per Release

From Kubernetes Cluster:

Values and Sub-charts

Deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-{{.Release.Name}}-{{.Chart.Name}}
spec:
replicas: {{.Values.replicaCount}}
selector:
matchLabels:
app: nginx-{{.Release.Name}}-{{.Chart.Name}}-app
template:
metadata:
 name: nginx-{{.Release.Name}}-{{.Chart.Name}}-pod
labels:
app: nginx-{{.Release.Name}}-{{.Chart.Name}}-app
spec:
containers:
- name: nginx-{{.Release.Name}}-{{.Chart.Name}}-con
image: {{.Values.image.repository}}:{{.Values.image.tag}}
ports:
- containerPort: 80

Service.yaml
apiVersion: v1
kind: Service
metadata:
name: nginx-service-{{ .Release.Name }}-{{ .Chart.Name }}
spec:
type: {{.Values.service.type}}
selector:
app: nginx-{{ .Release.Name }}-{{ .Chart.Name }}-app
ports:
- protocol: TCP
port: {{ .Values.service.port }}
targetPort: 80

Values.yaml
replicaCount: 2

image:
repository: nginx
tag: "1.17.0"

service:
type: LoadBalancer
port: 8090
Test the template using
 helm template mywebapp
 helm install demo1 mywebapp --dry-run
Run the chart
 helm install demo1 mywebapp
Upgrade the chart
 change the image tag in values.yaml
 helm upgrade demo-mywebapp mywebapp

Override Values in values.yaml:

 helm install demo-mywebapp .\mywebappchart\ --values my-values.yaml

You can also override the values in Values.yaml using the below command

 helm upgrade demo1 mywebapp --set service.port=8091

Functions and Pipelines

 Function Pipe
default default_value value value | default default_value
quote value value | quote
upper value value | upper
trunc value 63 value | trunc 63
trimSuffix "-" value value | trimSuffix "-"
b64enc value value | b64enc
randAlphaNum 10 value | randAlphaNum 10
toYaml value value | toYaml
printf format value list value … | join " -"

Values.yaml
service:
type: NodePort
name: myservice-with-a-very-long name-that-will-be truncated-by-trunc and-trimsuffix-and which-is-too-long for-
Kubernetes
labels
port: 80
mongodbRootPassword: T9rYGFAMGE

Examples:
 {{ Values.service.name | default .Chart.Name }} #Chart Name will be used as default value for
Values.servce.name doesn’t exist
 {{ .Values.service.name | trunc 63 | trimSuffix "-" }}
 {{ .Values.mongodbRootPassword | b64enc | quote }}

Modifying Scope using With and Indentation

Example1: Scoping using With
apiVersion: v1
kind: Service
metadata:
name: nginx-service-{{ .Release.Name }}-{{ .Chart.Name }}
spec:
selector:
app: nginx-{{.Release.Name}}-{{.Chart.Name}}-app
{{ with .Values.service}}
type: {{ .type }}
ports:
- protocol: TCP
port: {{ .port | default "8080"}}
targetPort: 80
{{ end }}

Example2: Trimming NewLine and Adding Indentation

apiVersion: v1
kind: Service
metadata:
name: nginx-service-{{ .Release.Name }}-{{ .Chart.Name }}
spec:
selector:
app: nginx-{{.Release.Name}}-{{.Chart.Name}}-app
type: {{ .Values.service.type }}
ports:
- protocol: TCP
port:
{{- with .Values.service -}}
 {{ indent 1 .port | default "8080"}}
{{- end }}
targetPort: 80

Formatted Output:
apiVersion: v1
kind: Service
metadata:
name: nginx-service-{{ printf "%s-%s" .Release.Name .Chart.Name }}
spec:
selector:
app: nginx-{{.Release.Name}}-{{.Chart.Name}}-app
{{ with .Values.service}}
type: {{ .type }}
ports:
- protocol: TCP
port: {{ .port | default "8080"}}
targetPort: 80
{{ end }}

Logical Operators

Examples:
{{- if and .adminEmail (or .serviceAccountJson .existingSecret) }}
{{- if (and (eq .Values.service.type "NodePort") (not (empty .Values.service.nfsNodePort))) }}
{{- if or .Values.rbac.pspEnabled (and .Values.rbac.namespaced (or .Values.sidecar.dashboards.enabled
.Values.sidecar.datasources.enabled)) }}

Conditions:

Loops:

Variables
apiVersion: v1
kind: Service
metadata:
 name: nginx-service-{{ printf "%s-%s" .Release.Name .Chart.Name }}
spec:
{{- $serviceSelector := printf "%s-%s" .Release.Name .Chart.Name }}
{{- with .Values.service}}
type: {{ .type }}
selector:
app: nginx-{{ $serviceSelector }}-app
ports:
- protocol: TCP
port: {{ .port | default "8080"}}
targetPort: 80
{{ end }}
OR
use $ for accessing Global Built-in Variables
apiVersion: v1
kind: Service
metadata:
name: nginx-service-{{ printf "%s-%s" .Release.Name .Chart.Name }}
spec:
{{ with .Values.service}}
type: {{ .type }}
selector:
app: nginx-{{$.Release.Name}}-{{$.Chart.Name}}-app
ports:
- protocol: TCP
port: {{ .port | default "8080"}}
targetPort: 80
{{ end }}

Calling Helper Functions and Sub-templates

Mywebapp/templates/_helpers.tpl
{{- define "mychart.fullname" -}}
{{- if .Values.fullnameOverride -}}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}}
{{- else -}}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}}
{{- end -}}
{{- end -}}

Deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-{{ include "mychart.fullname" . }}-dep
spec:
replicas: {{.Values.replicaCount}}
...

Note: Files prefixed by ‘_’ are not rendered as Kubernetes object

Working with Helm Repositories

Registry
Repository
Packages/charts

Using Helm Repository

1. helm repo list
Note: No repository by default in Helm 3
2. Goto https://hub.helm.sh
3. Search nginx and select the first result.
4. helm repo add bitnami https://charts.bitnami.com/bitnami
5. helm search mysql
6. helm inspect chart bitnami/mysql #Inspect values [all | readme | chart | values ]
7. helm pull bitnami/mysql
a. pull and fetch are alias
8. helm install demo-mysql bitnami/mysql

Helm Dependency
 list: list the dependencies for the given chart
 update: update charts/ based on the contents of Chart.yaml
 build: rebuild the charts/ directory based on the Chart.lock file

1. Update Chart.yaml
apiVersion: v2
name: mywebapp
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"
dependencies:
- name: mysql
version: ~8.9.0
repository: https://charts.bitnami.com/bitnami
2. helm dependency list mywebapp
3. helm dependency update mywebapp
Note: Chart.lock file is added to chart with hardcoded versions.

Install Chart along with dependency

4. helm install demo-mywebapp mywebapp
5. kubectl get pods
Note: the pods related to mysql are created along with our custom pods

Semver 2.0 Versions

Publishing in a Repository
1. Create the index.yaml
 helm package mywebapp
 helm repo index .
2. Upload charts’ archives and index file to an http server: Nginx, Apache, Cloud or use Chartmuseum
ChartMuseum is an open-source Helm Chart Repository server written in Go (Golang), with support for cloud
storage backends, including Google Cloud Storage, Amazon S3, Microsoft Azure Blob Storage, Alibaba Cloud
OSS Storage and Openstack Object Storage.
3. Run the Chartmuseum repository locally from a Docker Image.
 docker run --rm -u 0 -it -p 8080:8080 -e DEBUG=1 -e STORAGE=local -e
STORAGE_LOCAL_ROOTDIR=/charts -v charts:/charts ghcr.io/helm/chartmuseum:v0.14.0
4. Upload the package to Repository
 curl --data-binary "@mywebapp-0.1.0.tgz" http://localhost:8080/api/charts