Helm overview

1. What is Helm
2. Helm chart structure
3. Helm repositories
4. Helm template files
5. Deploying Helm charts

• Helm is a CLI that runs on top of kubectl and interacts with the cluster defined for the current context.
• It provides package management features for kubernetes. In Helm terminology, packages are called charts.
• A Helm chart stores definitions (templates) and configuration (values) for Kubernetes objects.

• A Helm chart is stored in a dedicated directory whose name is the name of the chart.

• In order to be Helm compliant, a chart directory must adhere to the Helm chart structure.

• The required subdirectories and files for a minimal chart are :

  files	usage
  .helmignore	Paths to ignore when packaging charts
  Chart.yaml	General informations about the current chart
  values.yaml	Objects configuration values file
  templates/*.yaml	Objects definition template files
  files/	Any file that may be read by templates during rendering
  charts/	Directories storing subcharts for the current chart

• Using Helm charts to generate manifest files streamlines the process by :

  • Centralizing configuration values for any workload, thus avoiding verbosity and repetition.
  • If needed, organizing large workloads into small chunks through the use of subcharts

• Available commands :

# writes the generated manifest file to stdout (doesn't require cluster access)
helm template nil "$repo_name/$chart_name"

# view chart general information (version etc)
helm show chart "$repo_name/$chart_name"

# view chart configuration values
helm show values "$repo_name/$chart_name"

# pull and uncompress chart directory from repository
helm pull --untar "$repo_name/$chart_name"

• A Helm chart can also be stored in a Helm repository :
  • Helm repositories are HTTP servers from which packaged Helm charts can be pulled.
  • The chart directory is packaged and compressed to a *.tgz file using helm package <chart>.
  • It is then uploaded to the repository using helm push <chart> <repo>.
• The Helm project maintains a publicly accessible repository called the Artifact Hub.
• Available commands :

# searches artifact hub for charts matching expression
helm search hub "$expression"

# list all locally installed repositories
helm repo list

# install chart repository locally
helm repo add "$repo_name" "$repo_url"

• The following top-level objects are available when crafting template files :

  object	usage
  .Capabilities	Basic information about the current cluster
  .Release	Basic information about the current release
  .Template	Basic information about the template itself
  .Chart	Templating values read from Chart.yaml
  .Values	Templating values read from values.yaml
  .Files	Provide read access to contents of files stored in files/
  .Subcharts	Dependencies for the current chart

• The following built-in template functions are also available for manipulation and formatting.

• However, providing guidance on how to write template files with Helm is beyond the scope of this document.

• The Helm website has a detailed guide on how to write template files using the Helm template language.

Notes :

• Built-in template values always begin with a capital letter.
• The Helm template language is actually a subset of the Go template language.

• Using a chart to update a cluster's desired state is called installing a Helm release :
  • Helm applies values to templates to render a K8s manifest file containing a set of objects.
  • It then uses the manifest file to update the cluster's desired state with the new objects.
• Each time this process happens, Helm adds a new revision number to the release.
• If a release was already installed for the chart, it is said to be superseded by the new revision.
• Newly created objects are then labeled to be identified as part of the last revision for the release.
• This way, installed releases may be upgraded, rolled back or uninstalled at a later stage.
• Available commands :

# list all releases installed on the cluster, display uninstalled ones as well
helm list --all -A

# lists all revisions for a release
helm history "$release_name"

# install release using basic mode
helm install "$release_name" "$repo_name/$chart_name"

# install release using alternative modes, auto generate release name
helm install --generate-name chart/directory
helm install --generate-name chart.archive.tgz
helm install --generate-name https://helm.repo.com/charts/chart.archive.tgz

# override values.yaml by passing a new file (supports merge)
helm install --generate-name "$repo_name/$chart_name" --values overrides.yaml

# override values.yaml by replacing properties in values.yaml (supports merge)
helm install --generate-name "$repo_name/$chart_name" --set mapValue.valueToUnset=null

# override values.yaml defined value for a map key using a JSON path and install the release (supports merge, preferred)
helm install --generate-name "$repo_name/$chart_name" --set-json "mapValue.keyStoringValueToOverride=\"valueToOverrideWith\""

# creates a new release for an already deployed chart (writes diff to cluster desired state, adds a revision)
helm upgrade "$release_name" "$repo_name/$chart_name"

# rollbacks the latest 2 releases for an already deployed chart
helm rollback "$release_name" "$repo_name/$chart_name" 2

# uninstalls current release as well as releases history for an already deployed chart
helm uninstall "$release_name"

Notes :

• Release names are limited to 53 characters.
• The version field in values.yaml should be updated before each upgrade since the upgrade creates a new revision of the release.