Welcome to the NZRT Wiki Podcast. Today we’re looking at Helm Reference.

So, what is Helm? Put simply, Helm is the package manager for Kubernetes. If you’ve used something like npm for Node or pip for Python, Helm plays a similar role — but for Kubernetes applications. It takes all the Kubernetes manifest files your application needs and bundles them into a single versioned, configurable unit called a chart. That makes it much easier to deploy, upgrade, and manage complex applications on your cluster.

Before we jump into commands, let’s cover four core concepts you’ll hear come up again and again. First, there’s the chart itself — that’s the package containing all your Kubernetes manifest templates. Second is a release, which is what you get when you actually run a chart in a cluster — it’s the live, running instance. Third is a repository, which is just a collection of published charts you can browse and pull from, kind of like a package registry. And fourth are values — these are the configuration overrides you supply to customise how a chart behaves when it’s deployed. Those four — chart, release, repository, values — are the building blocks of everything Helm does.

Now let’s walk through the common commands you’ll use day to day. The first thing you typically do is add a repository and update it. Think of this as registering a source so Helm knows where to find charts. Once you’ve added a repo, you can search it to find specific charts by name.

When you’re ready to deploy something, you use the install command. You give your release a name, point it at the chart you want from your repo, tell it which namespace to deploy into, and optionally tell Helm to create that namespace if it doesn’t already exist. You can also pass in a values file at this point to customise the deployment.

Once something is running, you’ll eventually want to update it — that’s where the upgrade command comes in. The syntax is very similar to install: you reference the release name, the chart, the namespace, and your values file. Helm handles rolling out the changes.

To see what’s currently deployed, you use the list command. You can scope it to a specific namespace, or ask Helm to show releases across all namespaces at once.

When you need to remove something, uninstall does the job — just give it the release name and namespace and Helm tears it all down cleanly.

One of the most useful features Helm offers is rollback. If an upgrade goes wrong, you can roll back to a previous revision — just reference the release name and the revision number you want to return to. To find out what revision numbers are available, the history command shows you a full list of past deployments for any given release.

Finally, there’s the template command. This is a dry-run tool that renders all the Kubernetes manifests Helm would generate — but doesn’t actually apply them to the cluster. It’s incredibly useful for debugging or reviewing exactly what Helm is going to do before you commit to it.

Now let’s talk about the values file, because this is where a lot of the real configuration lives. A typical values file is written in YAML and covers several key areas. You set a replica count — for example, two — to control how many instances of your application run. You define your image settings: the repository to pull from, the specific tag or version you want, and the pull policy, such as only pulling if the image isn’t already present locally. You configure your service — specifying the type, like ClusterIP for internal-only access, and the port it listens on. And you set resource constraints, which is important for cluster stability. On the requests side you declare the minimum CPU and memory your container needs to start. On the limits side you set the ceiling — the maximum it’s allowed to consume. CPU is expressed in millicores, so one hundred m is a tenth of a CPU core, and memory is in mebibytes.

Together, these values give you fine-grained control over your deployment without ever touching the chart templates themselves. You just override what you need, and Helm does the rest.

If you want to go deeper on the cluster side of things, check out the related wiki pages on kubectl and the NZRT Kubernetes Setup — both will give you context that pairs well with what you’ve just heard.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.