Unlocking the Power of Helm: Advanced and Essential Tips for Kubernetes Enthusiasts
We all know about Helm and why it’s essential in the Kubernetes ecosystem. In this blog, we’ll delve into some important Helm features to give you a clear overview. You may be familiar with some of these features, and we’ll also introduce you to some that you might not have come across before. Let’s get started:
- Automate restart of Pods
ConfigMap ans Secrets are injected your configuration, in case of modification those resources, the container should restart in order to consume new changes. Simplest way to automate it is using sha256sum function. Essentially its comparing sha256sum of ConfigMaps and Secrets, if they does not match, Helm will restart the pods.
I.e in deployment.yaml template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "fmt-app.fullname" . }}
labels:
{{- include "fmt-app.labels" . | nindent 4 }}
spec:
{{- if not .Values.autoscaling.enabled }}
replicas: {{ .Values.replicaCount }}
{{- end }}
selector:
matchLabels:
{{- include "fmt-app.selectorLabels" . | nindent 6 }}
template:
metadata:
{{- with .Values.podAnnotations }}
annotations:
{{- toYaml . | nindent 8 }}
{{- end }}
#checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
labels:
{{- include "fmt-app.selectorLabels" . | nindent 8 }}
...As soon as the configmap.yaml has changed, the Deployments Pods will restart.
2. Accessing global values in range loop.
Looping throug values line environment variables or maps is we use often range function to iterate through items. While you iterate through variables some cases you might need to access global variable.
{{- $global := . }}
{{- range $schedule := .Values.schedules }}
apiVersion: batch/v1
kind: CronJob
metadata:
name: cronjob-cas-{{- $schedule.name }}
labels: {{ $labels | nindent 4 }}
spec:
... #omitted
restartPolicy: Never
{{- with $global.Values.nodeSelector }} #access global value
nodeSelector:
{{- toYaml . | nindent 12 }}
{{- end }}
---
{{- end }}3. Library Charts
Unlike regular Helm charts, it doesn’t include deployment specifics. It’s used to share common templates, promoting code reuse and consistency across charts. If you have many in-house helm charts to maintain, library chart might be your friend. For instance all Bitnami helm charts based on this library chart.
Let’s also use common library chart from Bitnami.
$ helm create myapp
$ rm -rf myapp/template/* # delete all generated templates bcz we will use from lib chart
$ vim myapp/Chart.yml # add dependency
apiVersion: v2
name: myapp
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.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0
appVersion: "1.16.0"
# Add the Bitnami library chart as dependency
dependencies:
- name: common
repository: oci://registry-1.docker.io/bitnamicharts
tags:
- bitnami-common
version: 2.x.x
In this scenario, you have individual Helm charts for each application, but these charts are essentially empty and rely on a shared Library Chart for their templates and configurations. The Library Chart contains the common templates and utilities used by all the application charts, allowing for a modular and reusable approach to Helm chart development.
4. Manipulating Values
You can manipulate strings using the built-in functions and operators provided by Helm’s templating engine, which is based on Go templates.
{{ .Values.string1 }}{{ .Values.string2 }} # concatenate two string
{{ .Values.param | squote }} # single quote strings ('')
{{ slice .Values.originalString 0 5 }} # Use the slice function to extract a substring from a string.
{{ .Values.param | quote }} # quote strings ("")
{{ .Values.param | b64enc }} # Base64 encoding i.e for secrets
{{ .Values.param | upper }} # Uppercase everything
{{ .Values.param | lower }} # Lowercase everything
{{ .Values.param | indent 16 }} # Print with additional 16 leading spaces
{{ .Values.param | nindent 16 }} # Ensure total indentation is 16 (useful when template code is indented)5. Verify Templates
Helm has following commands:
# this will template and check syntax etc
$ helm template myapp mychary
# will also validate generated resources with Kubernetes API
$ helm install myapp mychart --dry-run helm template is mainly for rendering Helm templates into Kubernetes manifests that you can inspect or use in various ways, while helm install --dry-run is for simulating the installation process to verify that it would succeed without making any actual changes to your Kubernetes cluster. For debugging both commands are interchangeably useful.
Disclaimer: The newest version of Helm, 3.13.0, brings the -dry-run=server argument to the helm template command, which also allows for API validation. I tried but could not see the effect of the new argument. I will give it another try.
6. Helm Keep the Resources, do NOT delete!
In some scenarios, you may need to retain resources even if a Helm release is uninstalled. Helm allows you to achieve this via annotations:
annotations:
"helm.sh/resource-policy": keepThe resources associated with the annotation mentioned above will remain in place.
If you also know some hidden feature of Helm, let me know!
Resources:
