Use Helm for package management

When your Kubernetes YAML grows from ten lines to thousands, you quickly understand why raw manifests don't scale. You need versioning, rollback, templating, and dependency management. Helm is the Kubernetes package manager that turns 500-line YAML into reusable, configurable charts. Let's learn how to use Helm for package management — the essential skill for shipping production-ready applications on Kubernetes.

The problem this lesson solves

Kubernetes doesn't ship with a built-in way to package, version, or template your resources. Every deployment is manual kubectl apply -f with duplicated YAML, environment-specific overrides, and no way to roll back safely. When you manage 10+ microservices, each with a Deployment, Service, ConfigMap, and Ingress, the complexity multiplies fast.

Helm solves three core issues:

• Repetition: You don't type the same YAML for every environment.
• Versioning: No myapp-v2-final-final.yaml nightmares.
• Lifecycle: Install, upgrade, rollback, and delete with one command.

Think of Helm as apt-get for Kubernetes. Charts replace .deb packages, and helm install does what apt install does — but for cloud-native apps.

Core concept / mental model

What is a Helm chart?

A Helm chart is a collection of files that describe a related set of Kubernetes resources. A single chart might deploy a WordPress site with a Deployment, Service, PersistentVolumeClaim, and Ingress — all from one command.

The chart structure looks like this:

wordpress/
├── Chart.yaml          # Metadata: name, version, description
├── values.yaml         # Default configuration values
├── charts/             # Subcharts (dependencies)
├── templates/          # Go templates → YAML
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl    # Reusable template helpers

Release = installed instance

When you run helm install my-release wordpress/, Helm creates a release — a tracked deployment. Later you run:

• helm upgrade — modify the release with new values or chart version.
• helm rollback — revert to a previous release revision.
• helm uninstall — delete everything without manual cleanup.

This lifecycle management is the killer feature. YAML alone cannot do this.

How it works step by step

Step 1: Install Helm

On macOS:

brew install helm
helm version

On Linux / WSL:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Step 2: Add a chart repository

A Helm repository (repo) is where charts are stored. The default stable repo is bitnami:

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

Step 3: Search for a chart

helm search repo bitnami/nginx

Output:

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

Step 4: Install a chart

helm install my-nginx bitnami/nginx --set service.type=NodePort

This creates a release named my-nginx using the default values but overrides service.type.

Step 5: Inspect the release

helm list               # Show all releases in current namespace
helm status my-nginx    # Show release details

Step 6: Upgrade or rollback

helm upgrade my-nginx bitnami/nginx --set replicaCount=3
helm history my-nginx
helm rollback my-nginx 1   # Rollback to revision 1

Hands-on walkthrough

Example 1: Install a Helm chart from scratch

Let's deploy Bitnami's NGINX chart with custom values:

# Add the repo
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Install with a custom NodePort and 2 replicas
helm install my-web bitnami/nginx \
  --set replicaCount=2 \
  --set service.type=NodePort \
  --set service.nodePorts.http=30080

# Check the release
helm list
kubectl get pods -l app.kubernetes.io/instance=my-web

Expected output:

NAME    READY   STATUS    RESTARTS   AGE
my-web-nginx-0   1/1     Running   0          12s
my-web-nginx-1   1/1     Running   0          12s

Example 2: Create your own chart

Helm can scaffold a chart for you:

helm create mychart
# A new directory 'mychart' appears with default templates

cd mychart
helm lint .        # Validate chart syntax
helm package .     # Create mychart-0.1.0.tgz
helm install demo ./mychart --set service.port=8080

Use helm create as a starting point — then modify values.yaml and templates to match your app.

Example 3: Using values files for environments

# prod-values.yaml
replicaCount: 5
image:
  tag: "prod-1.2.0"
service:
  type: LoadBalancer

# Install with the values file
helm install prod-app ./mychart -f prod-values.yaml

This keeps environment-specific configs separate from the chart — DevOps best practice.

Compare options / when to choose what

When to use Helm:

• You need to manage multiple environments with different configs.
• You want reliable rollbacks for every deployment.
• You're packaging reusable components for your team or community.

When to avoid Helm:

• You only have 1–2 static YAML files.
• Your team is not yet Kubernetes-aware and prefers pure YAML.

Troubleshooting & edge cases

Chart not found after helm repo add

Solution: Always run helm repo update before helm install or helm search.

helm install hangs with no pods

Check the Deployment selector match your labels. Helm uses app.kubernetes.io/instance — override with --labels if needed.

kubectl describe deployment my-web-nginx
kubectl logs -l app.kubernetes.io/instance=my-web

Rollback fails because of breaking schema changes

If you upgrade a CRD (Custom Resource Definition) that doesn't support downgrade, rollback may produce errors. Solution: pin Helm chart version and use --version when installing.

Different releases with same name in different namespaces

Helm allows this as of Helm 3. Use --namespace to scope releases:

helm install my-web bitnami/nginx --namespace staging
helm install my-web bitnami/nginx --namespace production

Helm template debugging

Use helm template to see the rendered YAML without deploying:

helm template my-release ./mychart -f prod-values.yaml | less

What you learned & what's next

You now understand how to use Helm for package management: from installing Helm, adding repos, creating charts, deploying releases, upgrading and rolling back. You've compared Helm with raw YAML, Kustomize, and Operators. You can troubleshoot common issues like missing repos, stuck pods, and failing rollbacks.

Next lesson: In "Use Helm for package management — advanced patterns," you'll learn how to create reusable chart libraries, manage dependencies, and build a stable release pipeline with Helm.

Now push a real chart to production — start with helm create and deploy your first application with environment values files.