100 Days Of Kubernetes

Helm Commands

Updated September 2026: Helm 4 flags, where charts are stored, and working bitnami/wordpress examples.

100Days Resources

• Video by Anais Urlichs

Learning Resources

• Using Helm — the official guide to the commands covered below
• Introduction to Helm — how the client and library divide the work
• Helm command reference

Example Notes

Primary features of the Helm client

The Helm client is a command-line tool. It handles local chart development, manages repositories and releases, and hands charts to the Helm library to be installed, upgraded or uninstalled. The library does the actual work by talking to the Kubernetes API server. Helm keeps release information in Kubernetes Secrets inside the cluster, so it needs no database of its own.

How does Helm interact with your Kubernetes cluster?

It interacts with the same configuration files that kubectl uses: the kubeconfig at ~/.kube/config by default, or the file named in $KUBECONFIG. You can pick a context with --kube-context.

What repository can you use to store your Helm Artifacts?

Charts are stored either in a chart repository (any HTTP server that serves an index.yaml plus the packaged charts, e.g. GitHub Pages, S3, GCS or ChartMuseum) or in an OCI registry such as Docker Hub, GitHub Container Registry, Amazon ECR or Harbor. The Artifact Hub does not store charts itself; it lists charts from many publishers' repositories so you can find them.

A Helm chart is an individual package that can be installed into your Kubernetes cluster. Source

Adding a chart repository to your Helm client

helm repo add bitnami https://charts.bitnami.com/bitnami

You can find the URLs here https://artifacthub.io/. Note that when you install a chart without --version, Helm takes the latest stable version of that chart.

We can then view all of our repositories through

helm repo list

If we have added multiple repositories, we could use the following command to look for specific charts in them

helm search repo wordpress

Looking at the Helm Chart, there are two very important distinctions:

A chart version is the version of the Helm chart. The app version is the version of the application packaged in the chart.

You can find these (and set them) in the Chart.yaml file within your chart, as version and appVersion.

Furthermore, you can install the exact same chart multiple times — e.g. if you want to run multiple applications in parallel.

An installation of a chart is a specific instance of the chart. One chart may have many installations.

Note that a release name can be used only once per namespace. If you use the name myname, you cannot install another release with that exact name within the same namespace.

On each installation, the configurations of the Helm chart get installed again.

You can use the following command to see the values that have been used in the previous installation:

helm get values <name of the chart>

The following commands first install a chart, then you can upgrade the installation

helm install mysite bitnami/wordpress --values values.yaml 
helm upgrade mysite bitnami/wordpress --values values.yaml

You would want to upgrade your Helm chart when you are using different values or your application has changed.

The helm template command can be used similarly to the helm install --dry-run command explored in

Helm Part 1

helm template mysite bitnami/wordpress --values values.yaml --set [email protected]

However, this command separates the installation logic from the helm upgrade logic.The helm template command does not contact the Kubernetes server. Resulting, this command does not provide us with a complete validation of our Helm Chart. The helm template command is mainly used to access the YAML files and then use those within other tools.

If you would like to reuse the same values within your Helm Chart, you could use the --reuse-values flag:

helm upgrade mysite bitnami/wordpress --reuse-values

We call also pass new values into our chart upon installing the chart

1. Using the --set flag and override a certain variable. However, you should avoid injecting custom values into the Helm Chart as much as possible since this will make it difficult to keep observability of your Helm resources. For example,

   helm install mysite bitnami/wordpress --set wordpressUsername=admin
   

2. Using a custom YAML file that specifies the values for (some) parameters can be provided while installing the chart using --values or -f flag. For example,

   helm install mysite bitnami/wordpress -f my-custom-value.yml
   

Whenever you install a new Helm chart, Helm creates a secret that tracks the previous version of the installation; you can view all the secrets with

kubectl get secret

Every time a release is installed, upgraded or rolled back, Helm increments its revision number by 1. By default helm upgrade keeps only the last 10 revisions; change this with --history-max (0 means no limit).

A release can be in several different stages

pending-install Before sending the manifests to Kubernetes, Helm claims the installation by creating a release (marked version 1) whose status is set to pending-install.

deployed As soon as Kubernetes accepts the manifest from Helm, Helm updates the release record, marking it as deployed.

pending-upgrade When a Helm upgrade is begun, a new release is created for an installation (e.g., v2), and its status is set to pending-upgrade.

superseded When an upgrade is run, the last deployed release is updated, marked as superseded, and the newly upgraded release is changed from pending-upgrade to deployed.

pending-rollback If a rollback is created, a new release (e.g., v3) is created, and its status is set to pending-rollback until Kubernetes accepts the release manifest. Then it is marked deployed and the last release is marked superseded.

uninstalling When a helm uninstall is executed, the most recent release is read and then its status is changed to uninstalling.

uninstalled If history is preserved during deletion, then when the helm uninstall is complete, the last release’s status is changed to uninstalled.

failed Finally, if during any operation, Kubernetes rejects a manifest submitted by Helm, Helm will mark that release failed.

To access information on our installed Charts, we can use

helm ls

This will provide us with a list of installed Helm Charts.

With the

helm get

command, we can access further information of some part of the information that is tracked by a helm release.

To print the release notes

helm get notes mysite

Note that mysite in this case is the name of my Helm chart.

To print the values of a chart

helm get values mysite

If we add the --all (or -a) flag at the end, we can see all of the values that have been used within the Helm Chart.

To print the YAML manifests used for the deployment

helm get manifest wordpress

List all you charts

helm list

You can view the details of a specific chart by

helm history <chart name>

You can also rollback to a previous release

helm rollback wordpress 2

In this case, we specify the name of the Helm Chart and the Version that we want to rollback to.

We can remove a chart with the

helm uninstall <chart name>

command. However, that will delete the history of our deployments.

If we want to keep the history of our deployments, we can use the fllowing

helm uninstall <chart name> --keep-history

The great thing about reading the book itself is actually that I learn a lot about Kubernetes as well. The authors draw several comparisons between the way Kubernetes has been developed and how those properties translate to Helm.