Understanding Helm And Architecture
Introduction
Helm is a tool for managing Kubernetes packages which allows to create, scale and maintain complex applications easily.
Why do we need Helm?
To understand helm and its use, we must need to understand one of the underlying problem of managing complex application that Helm solves.
Imagine we have to create multiple applications having similar characteristics with few changes ( as of many applications that run today ), we would have write down same set of configuration files and install packages having only few value differences.
We would have many files and we would be repeating same set of procedures if we have to scale any of the application which would not be very D.R.Y.Consider a PostgreSQL database having following files.
postgres-config.yml
postgres-deployment.yml
postgres-service.yml
postgres-pvc.ymlA sample config.yml would look like this
apiVersion: v1
kind: ConfigMap
metadata:
name: postgres-config
labels:
group: db
data:
POSTGRES_DB: kanban
POSTGRES_USER: kanban
POSTGRES_PASSWORD: kanbanNow if we had to create multiple PostgreSQL instances we would have to copy and paste all these four files with just few changes like the database name or the user name or the password.
It would be nice if we had a blue print in which we would only specify the changing values and the kubernetes would do the work for us.
That’s where Helm comes in, as it takes all the repeating work away and allows us to write blueprint or download the existing blue print from the internet and embed it in the application.
Helm Architecture
Helm architecture is divided in to following category.
(1) Repository.
(2) Client.
(3) Chart.
Repository
Helm repository is where all the packages are stored. Helm repositories can be private and can be public like HelmHub.
Client
Helm client is the command line interface that facilitates communication between user and repository. The client is also called helm ( all letters in lower case ).
With the help of helm, we can
. List currently installed Charts.
. Search the available Charts.
. Retrieve the Chart and put it in a local working directory.
. Retrieve the Chart and install it into Kubernetes.
. Verifies that the chart can successfully enter the “Running” state.
. Uninstall the chart.
. Create a new chart.
. Edit a new chart.
. Publish a chart.
. Print information about a Chart.
. Refresh local metadata about available Charts.
. Print help.
Chart
Helm uses a packaging format to package a collection of files designed to carry out kubernetes related services in a well-defined directory structure called charts.
A single chart can be used to deploy a simple pod or deploy an entire application.When we create a chart, we are given with a set of files in a definite ordering such as
postgres/
Chart.yaml
LICENSE
README.md
values.yaml
values.schema.json
charts/
crds/
templates/
templates/NOTES.txtChart.yml contains all the information about the chart being created. There are two types of charts.
The Application chart is the default type which can be operated on fully.
The Library chart provides functions for the chart builder and it is not installable.The template folder contains all the manifest files, which are YAML-formatted resource descriptions that Kubernetes can understand. When Helm renders the charts, it will pass every file in that directory through the template engine by either of the two ways.
. values.yml file which contains all the default values.
. Through helm install command.The Chart folder contains all the dependencies that a package may contain. For instance a chart.yml contains the following dependency.
dependencies:
- name: nginx-ingress
version: 1.36.0
repository: https://kubernetes-charts.storage.googleapis.com/When we run the following command
helm dependency update ./, ingress folder will appear in the Charts directory.
