Learn Helm Chart - Helm Installation & CLI Basics

#Introduction

After dissecting the Helm 3 architecture in episode 2 — client-only without Tiller, releases stored in Secrets, and the three-way merge mechanism — it's time to climb into the cockpit. In this episode you'll actually use Helm: install the binary, make your terminal comfortable with completion, understand the command structure, manage chart repositories, find the right charts, and make your first deployment with Helm.

Why does this episode matter? Because chart distribution and management is the everyday language of a Kubernetes engineer. In the real world, teams rarely build every chart from scratch — they use community charts (Bitnami, ingress-nginx, prometheus-community, grafana), adjust the values, and deploy in minutes. The ability to find the right chart, evaluate its version, and add repositories safely is a skill that determines productivity. By the end of this episode, you'll have an nginx chart running in the cluster — the first of many deployments you'll make in this series.

#Main Discussion

#Installing Helm 3

Helm 3 is a single binary with no daemon — there's no service to run or enable. There are three common ways to install it:

Option 1: Official installer scriptOption 2: Package manager (apt/brew/choco)Option 3: Direct binary (GitHub release)

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

# Ubuntu/Debian
curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt update && sudo apt install -y helm

wget https://get.helm.sh/helm-v3.16.0-linux-amd64.tar.gz
tar -xzf helm-v3.16.0-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm

Verify the installation — a command that will become your reflex:

helm version
helm version --short

helm version --short shows only v3.x.y — the major number 3 must be there. If it isn't, don't continue: this entire series uses Helm 3, and its commands differ from Helm 2. After that, make sure Helm can talk to the cluster:

Make sure the cluster is reachable

kubectl cluster-info
helm env

helm env output shows the environment variables Helm uses — among them HELM_NAMESPACE (the default namespace, usually default) and the HELM_CACHE_HOME location. As long as kubectl cluster-info succeeds, Helm is ready.

#Shell Completion

Helm has many subcommands and flags — don't memorize them all. Install completion so tab-completion helps you and saves hundreds of keystrokes a day:

helm completion bash > ~/.bashrc.d/helm.bash
source ~/.bashrc.d/helm.bash

helm completion zsh > "${fpath[1]}/_helm"
compinit

For fish, use helm completion fish in a similar way. The effect is immediate: type helm in then tab → helm install; type helm repo a then tab → helm repo add. Completion also lists valid flags, so you don't have to open the docs every time you forget an option name.

#The Helm CLI Structure

The entire Helm CLI follows one pattern: helm <command> [subcommand] [flags]. First understand the command map:

• Core commands: install, upgrade, rollback, uninstall, list, status, history.
• Chart commands: create, package, pull, template, lint, dependency.
• Repository commands: repo add, repo list, repo update, repo remove, repo index.
• Information commands: version, env, search, show, get, completion, help.

helm help
helm install --help
helm list --help

Two habits to cultivate from the start:

1. helm <command> --help is your first documentation — the available flags, usage examples, and command notes are written there. Get used to reading it before asking Google.
2. Use structured output formats with -o / --output when you want to parse results. helm list -o json and helm list -o yaml turn table output into data that jq or scripts can process:

helm list -o json | jq '.[].name'
helm list -o json | jq '.[] | select(.status == "deployed") | .name'

#Managing Chart Repositories

Charts are fetched from repositories — servers that store .tgz archives and an index.yaml file. Before you can install from a repository, you must add it to Helm's local list:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo list

helm repo add only records the address — it doesn't download anything yet. To fetch the latest metadata (index) from all registered repositories, run:

helm repo update
helm repo list -o json
helm repo remove <nama-repo>

The four repositories above are the most widely used in the real world:

To visually explore thousands of other charts, visit Artifact Hub — the official chart aggregator of the Helm ecosystem. To download a chart without installing — for example, to inspect it offline or copy a dependency into your own chart — use helm pull:

helm pull bitnami/nginx
helm pull bitnami/nginx --untar
ls nginx/

Without a flag, helm pull saves the .tgz archive in the current directory; with --untar, it extracts the contents so you can inspect the chart structure — a good habit before using an unfamiliar chart.

#Finding Charts

There are two forms of helm search, and distinguishing them matters:

• helm search repo <name> — searches only the repositories already registered on your machine (data from the local index). Fast, offline, and shows only charts ready to install.
• helm search hub <name> — searches all of Artifact Hub (the global online database). Useful for finding charts from repositories you haven't registered yet.

helm search repo nginx
helm search repo bitnami/nginx
helm search hub nginx-ingress

Notice the two version columns in the search results — this is a classic source of confusion. A real example of helm search repo bitnami/nginx output:

NAME               CHART VERSION   APP VERSION   DESCRIPTION
bitnami/nginx      15.11.2         1.25.3        Chart for the nginx server

The two are independent: a chart version 15 can contain an app version 1.25, and the next chart version may keep the same application. When pinning a chart in production, what you pin is the chart version — not the app version. You can explore chart details before installing:

helm show chart bitnami/nginx
helm show values bitnami/nginx | head -40
helm show readme bitnami/nginx

helm show values displays every default value that can be overridden — this is the first document you must read before installing. helm show readme provides the official usage guide from the chart maintainers.

#Your First Deployment with Helm

Everything is ready. Let's chain the whole flow together: installation (done), adding a repository (done), finding a chart (done), and now — install. Here's the complete flow from zero to a running application:

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

helm search repo bitnami/nginx
helm show values bitnami/nginx | grep -i replicas

helm install web bitnami/nginx --namespace web --create-namespace
helm list -n web
kubectl get pods -n web

helm install web bitnami/nginx creates a release named web from the bitnami/nginx chart. The --namespace web --create-namespace flags place the release in the web namespace and create it if it doesn't exist. The final output shows NAME: web, STATUS: deployed, and access notes from the chart's NOTES.txt. Verify the real state with kubectl — remember the lesson from episode 0: Helm says deployed, kubectl proves it.

To access the application from your laptop, use port-forward:

Access the deployed application

kubectl port-forward -n web svc/web-nginx 8080:80

Open http://localhost:8080 — the nginx page will appear. You've just deployed a complete application (Deployment + Service + ConfigMap + Secret) to Kubernetes with one command. Imagine how many YAML files you'd have to write by hand for the same result.

#Reading the Installation Output

When helm install finishes, Helm prints a summary that's often skipped over — yet it contains information you'll need later:

NAME: web
LAST DEPLOYED: Sun Aug 02 14:03:21 2026
NAMESPACE: web
STATUS: deployed
REVISION: 1
TEST SUITE: None

The first four lines are worth remembering. NAME: web is the release name — not the chart name — and it's the identity used by every subsequent command (helm list, helm upgrade, helm uninstall). STATUS: deployed tells you the release was created successfully; other statuses like failed or pending-install will be dissected in episode 4. REVISION: 1 marks this as the first release — every upgrade increments this number, and it's the basis of the rollback mechanism. TEST SUITE: None means this chart doesn't define test hooks (a topic for episode 14).

Then, the NOTES: section at the end of the output shows access instructions specific to this release — for example, a port-forward command or a URL to open. Don't throw it away: it's bundled documentation generated directly from the values you used. If you want to show those notes again without reinstalling, use helm get notes web:

helm get notes web

A small habit that saves a lot of time: record the release name and namespace in your project README. When teams accumulate dozens of releases, no one remembers the names that were created — helm list -A becomes the starting point of any investigation.

#Common Mistakes

1. Using Helm 2. If helm version --short shows v2.x, the commands here don't apply — Helm 2 needs Tiller. Always make sure the major version is 3.
2. Forgetting helm repo update. helm install fails with no chart name found or a version not found because the local index isn't refreshed. Get used to updating after repo add.
3. Confusing chart version vs app version. Pinning the wrong version at install or upgrade time. Remember: what you pin is the chart version.
4. Ignoring helm show values. Installing with defaults that don't fit the environment and then debugging in production. Always read the values before installing.
5. Not using namespaces. All releases pile up in default, making identification and cleanup harder. Start the --namespace habit now.

#Conclusion

In episode 3 you've made a big leap: Helm is installed and verified (helm version → v3.x), your terminal is comfortable with shell completion, the CLI structure is understood (helm <command> [flags] plus -o json/yaml output), repositories are managed (repo add/list/update/remove), chart search is mastered (search repo vs search hub, the chart version vs app version difference), and — most importantly — the first release web was successfully installed from a Bitnami chart and verified running in the cluster.

Key takeaways:

• Helm 3 can be installed via the installer script, package manager, or binary — all are valid; make sure the major version is 3.
• Completion and --help are the fastest ways to boost CLI productivity.
• A repository is a chart registry; repo update is required after adding a new repository.
• Pin the chart version, not the app version, when managing releases.
• helm install <release> <chart> is your first deployment — always verify with kubectl.

Now you can use Helm to install charts. In the next episode, episode 4, we'll go deeper into release installation and management: the --wait, --timeout, and --atomic flags, dry-run and debugging, reading release status with helm list and helm status, exploring helm get, understanding the release status lifecycle, and deleting releases correctly. See you in episode 4!