What is Helm?
Helm helps you manage Kubernetes applications. Helm Charts help developers and operators easily define, install, and upgrade even the most complex Kubernetes application.
Below are the three big concepts regarding Helm.
1. Chart – A chart is a Helm package. It contains all resource definitions necessary to run an application, tool or service inside the Kubernetes cluster.
2. Repository – A repository is a place where charts can be collected and shared.
3, Release – Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times in the same cluster, and each time it is installed, a new release is created.
Registry – Helm Registry stores Helm charts in a hierarchy storage structure and provides a function to orchestrate charts from the existing charts. To deploy and configure registry, refer to this.
Why Helm?
- It helps find and use popular software packaged as Kubernetes charts
- Shares your own applications as Kubernetes charts
- Manages releases of Helm packages
- Creates reproducible builds of your Kubernetes applications
Changes since Helm2
Helm3 includes following major changes:
1. Client-only architecture
Helm 2 is a client-server architecture with the client called as Helm and the server called as Tiller. The client interacts with the Tiller and the chart repository. Tiller interacts with the Kubernetes API server. It renders Helm template files into Kubernetes manifest files, that it uses for operations on the Kubernetes cluster through the Kubernetes API.
Helm 3 has a client-only architecture with the client still called as Helm. It operates similar to Helm 2 client, but the client interacts directly with the Kubernetes API server. The in-cluster server Tiller is removed in Helm 3.
2. No need to initialize Helm
Initializing Helm is obsolete in version 3. i.e. Helm init was removed and you don’t need to install Tiller in the cluster and set up a Helm state before using Helm. A Helm state is created automatically, whenever required.
3. Chart dependency updated
In Helm 2, chart dependencies are declared in requirements.yaml, as shown in the following example:
dependencies:
– name: mysql
version: “1.3.2”
repository: “https://example.com/charts/mysql“
Chart dependencies are consolidated in Helm 3, hence moving the dependency definitions to Chart.yaml.
4. Chart value validation
In Helm 3, values passed to a chart during any Helm commands can be validated against a JSON schema. This validation is beneficial to help chart consumers avoid setting incorrect values and help improve chart usability. To enable consumers to avoid setting incorrect values, add a schema file named values.schema.json in the chart folder.
Following commands call the validation:
- helm install
- helm upgrade
- helm template
5. Helm test framework updates
Helm 3 includes following updates to the test framework (helm test):
- Users can define tests as job resources
- The test-failure hook was removed
- The test-success hook was renamed to test, but the alias remains for test-success
- You can dump logs from test pods with –logs flag
Helm 3 is more than just removing Tiller. It has a lot of new capabilities. There is little or no difference from CLI or usage point of view in Helm 3 when compared with Helm 2.
Prerequisites
- A running Kubernetes cluster.
- The Kubernetes cluster API endpoint should be reachable from the machine you are running Helm commands.
Installing Helm
- Download binary from here.
- Unpack it (tar -zxvf helm-v3.0.0-linux-amd64.tgz)
- Find the Helm binary and move it to its desired destination (mv linux-amd64/helm /usr/local/bin/helm)
From there, you should be able to run the client command: ‘helm help’.
Note: We will be using Helm version 3.0.0
Deploy a sample Helm Chart
Use below command to create new chart named mysql in a new directory
$ helm create mysql
After running above command, Helm creates a directory with the following layout:
velotiotech:~/work/mysql$ tree
.
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
3 directories, 9 files
It creates a Chart.yaml file containing global variables for the chart such as version and description.
velotiotech:~/work/mysql$ cat Chart.yaml
apiVersion: v2
name: mysql
description: A Helm chart for Kubernetes
# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application
# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
version: 0.1.0
# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application.
appVersion: 1.16.0
Then comes templates directory. There you put all the *.yaml files for Kubernetes. Helm uses Go template markup language to customize *.yaml files. Helm creates three default file types: deployment, service, ingress. All the files in this directory are skeletons that are filled with the variables from the values.yaml when you deploy your Helm chart. File _helpers.tpl contains your custom helper functions for variable calculation.
By default, Helm creates an nginx deployment. We will customize it to create a Helm Chart to deploy mysql on Kubernetes cluster. Add new deployment to the templates directory.
velotiotech:~/work/mysql$ cat templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "mysql.fullname" . }}
spec:
selector:
matchLabels:
app: {{ include "mysql.name" . }}
template:
metadata:
labels:
app: {{ include "mysql.name" . }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
env:
- name: MYSQL_ROOT_PASSWORD
value: {{ .Values.mysql_root_password }}
ports:
- containerPort: {{ .Values.service.port }}
name: mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: {{ .Values.persistentVolumeClaim }}
Also, let’s create PVC which is used in deployment by just adding below file to the templates directory.
velotiotech:~/work/mysql$ cat templates/persistentVolumeClaim.yml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: {{ .Values.persistentVolumeClaim }}
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
Helm runs each file in the templates directory through Go template rendering engine. Let’s create service.yaml for connecting to mysql instance.
velotiotech:~/work/mysql$ cat templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: {{ include "mysql.fullname" . }}
spec:
ports:
- port: {{ .Values.service.port }}
selector:
app: {{ include "mysql.name" . }}
clusterIP: None
Update values.yaml to populate the above chart’s templates.
velotiotech:~/work/mysql$ cat values.yaml
# Default values for mysql.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
image:
repository: mysql
tag: 5.6
pullPolicy: IfNotPresent
nameOverride: ""
fullnameOverride: ""
serviceAccount:
# Specifies whether a service account should be created
create: false
# The name of the service account to use.
# If not set and create is true, a name is generated using the fullname template
name:
mysql_root_password: password
service:
port: 3306
persistentVolumeClaim: mysql-data-disk
resources: {}
# We usually recommend not to specify default resources and to leave this as a conscious
# choice for the user. This also increases chances charts run on environments with little
# resources, such as Minikube. If you do want to specify resources, uncomment the following
# lines, adjust them as necessary, and remove the curly braces after 'resources:'.
# limits:
# cpu: 100m
# memory: 128Mi
# requests:
# cpu: 100m
# memory: 128Mi
After adding above deployment files, directory structure will look like:
velotiotech:~/work/mysql$ tree
.
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── NOTES.txt
│ ├── persistentVolumeClaim.yml
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
3 directories, 9 files
To render chart templates locally and display the output to check if everything is correct:
$ helm template mysql
Execute the following helm install command to deploy our mysql chart in the Kubernetes cluster.
$ helm install mysql-release ./mysql
velotiotech:~/work$ helm install mysql-release ./mysql
NAME: mysql-release
LAST DEPLOYED: Mon Nov 25 14:48:38 2019
NAMESPACE: mysql-chart
STATUS: deployed
REVISION: 1
NOTES:
1. Use below command to connect to mysql:
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql-release -ppassword
2. Try creating database in mysql using command:
create database test;
Now the chart is installed. Note that installing a Helm chart creates a new release object. The release above is named mysql-release.
To keep a track of a release’s state, or to re-read configuration information, you can use Helm status:
$ helm status mysql-release
Additionally, to create a package, use below command which requires path for chart (which must contain a Chart.yaml file) and then package that directory:
$ helm package <path_to_Chart.yaml>
This command creates an archive like mysql-0.1.0.tgz, with which you can share your chart with others. For instance, you can upload this file to the Helm repository.
You can also delete the sample deployment using delete command. For example,
$ helm delete mysql-release
Upgrade a release
Helm provides a way to perform an install or an upgrade as a single command. Use Helm upgrade with the –install command. This will help Helm to see if the release is already installed. If not, it will run an install. If it is, then the existing release will be upgraded.
$ helm upgrade --install <release name> --values <values file> <chart directory>
