07-10-2021
Defined as an application package manager in the Kubernetes orchestrator – Helm is, as its creators themselves emphasize, the best way to find, share and use software developed for Kubernetes. What’s worth noting is that Helm allows you to deploy applications in a pretty simple, basically with a single click. This makes things much easier, especially if you don’t have much experience with containers.
Helm vs. charts
Deploying an application on a Kubernetes cluster is related to the definitions of various types of objects. They represent the components needed for the application to run properly on that orchestrator environment.
Depending on what type of application we are working with, the number of files can be more or less. But when we think about many environments, it already becomes overwhelming for the person who needs to make modifications.
Helm allows you to define so-called charts which are packages containing file templates and values that define a given application. As a result, it helps you install and update even the most complex applications.
As in the case of Docker, it’s not just the tool but a large community (https://artifacthub.io/) providing ready-made configurations, so deploying them to a cluster is a matter of just a few minutes.
Each chart/application implementation saves in Kubernetes secrets of a given namespace, thanks to which we can version, share, host, or do a rollback.
With Helm, we can share charts of our applications and prepare playable compilations of those applications. We can also manage Helm package releases. We can reuse the created and tested charts in many groups within and outside the organization.
Architecture
Helm is based on several components. These are:
- Charters – that is, preconfigured Kubernetes resources – are required to run the application;
- Release – an instance of a chart running in a Kubernetes cluster;
- Repository – the place where charts are collected and shared.
In Helm 3, the Helm client interacts directly with the Kubernetes API server (in Helm 2, the intermediary between the client and the API was Tiller).
Given the development, charts in Helm 3 are easy to maintain and secure. On the operational side, we gain, among other things, automatically updated deployments and protection of resources against deletion.
Client installation locally
Windows:
choco install kubernetes-helm
MacOS:
brew install helm
Linux (Debian/Ubuntu):
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
Initializing the first chart
helm create test-chart
After executing the above command, we should get a folder structure like the below:
First – Chart.yaml – describing the chart as name, version.
Then – Charts – an empty folder, which may contain other charts, on which will depend.
Also – Templates, which contain the definition of Kubernetes objects in the form of Helm and are crucial in its creation
At the end – Values.yaml. Values that will be substituted to templates, so we don’t have to create, for example, separate k8s objects for a given environment.
Example template for the service object
apiVersion: v1
kind: Service
metadata:
name: {{ .Release.Name }}
spec:
type: {{ .Values.service.type }}
ports:
– port: {{ .Values.service.port }}
targetPort: http
protocol: TCP
name: http
selector:
{{- include „test-chart.selectorLabels” . | nindent 4 }}
All elements from Helm are enclosed in {{ }} – Golang syntax.
The values that we define in values.yaml are referenced via the.Values variable. e.g.:
values.yaml
service:
type: ClusterIP
port: 80
References in template service.yaml…
{{ .Values.service.type }}
{{ .Values.service.port }}
will be substituted in place of their definition.
The whole syntax, as well as examples, are well described on the official site https://helm.sh/docs/chart_template_guide/getting_started/.
by