10.1 Helm

Abstract

Helm is a package manager and release manager for Kubernetes.

It lets us install, upgrade, rollback, and uninstall complete Kubernetes applications as a single package instead of managing many YAML files one by one.

Why Helm?

Kubernetes applications are usually not a single object.

A production application may include:

Deployments
Services
Secrets
ConfigMaps
PersistentVolumes
PersistentVolumeClaims
Jobs
CronJobs
Ingress resources
ServiceAccounts
RBAC objects

For example, a WordPress deployment may need:

Kubernetes Object	Purpose
Deployment	Runs WordPress or MySQL pods
Service	Exposes WordPress or database internally/externally
Secret	Stores passwords and credentials
PVC	Requests persistent storage
PV	Provides actual storage
ConfigMap	Stores application configuration

Note

Kubernetes manages each object individually. Helm understands that these objects together form one application.

Problem Without Helm

Without Helm, you usually manage applications using multiple YAML files.

Example:

kubectl apply -f wp-secret.yaml
kubectl apply -f wp-pv.yaml
kubectl apply -f wp-pvc.yaml
kubectl apply -f wp-deploy.yaml
kubectl apply -f wp-svc.yaml

This becomes difficult when you need to:

change storage size
update image versions
change passwords
upgrade the application
rollback changes
delete all related resources
keep environment-specific configs

Warning

Managing many YAML files manually increases the chance of mistakes during upgrades, rollbacks, and production changes.

What Helm Does

Helm groups related Kubernetes manifests into a reusable package called a chart.

Instead of applying many YAML files manually, you install the chart once.

helm install wordpress

Helm then creates all required Kubernetes objects for the application.

Success

Helm lets us treat Kubernetes applications as complete applications, not just separate YAML objects.

Helm as a Package Manager

Helm is often called the package manager for Kubernetes.

Just like an installer installs many files for an application, Helm installs many Kubernetes objects for an application.

Example comparison:

Traditional Software	Kubernetes with Helm
Installer package	Helm chart
Application files	Kubernetes manifests
Installation settings	`values.yaml`
Installed application	Helm release
Upgrade installer	`helm upgrade`
Uninstall app	`helm uninstall`

Example

Instead of micromanaging every Deployment, Service, Secret, and PVC, Helm manages them as one release.

Key Helm Concepts

Concept	Meaning
Chart	Package containing Kubernetes templates
Release	Installed instance of a chart
Values	Custom configuration passed to a chart
Repository	Location where charts are stored
Revision	Version history of a Helm release

Helm Chart

A chart is a package that contains Kubernetes YAML templates.

Typical chart structure:

wordpress/
  Chart.yaml
  values.yaml
  templates/
    deployment.yaml
    service.yaml
    secret.yaml
    pvc.yaml

File / Directory	Purpose
`Chart.yaml`	Chart metadata
`values.yaml`	Default configurable values
`templates/`	Kubernetes manifest templates

Tip

Templates allow the same chart to be reused across dev, test, staging, and production.

values.yaml

values.yaml stores customizable settings for the chart.

Example:

wordpressUsername: user
wordpressPassword: strong-password
wordpressEmail: user@example.com
wordpressBlogName: User's Blog

service:
  type: LoadBalancer
  port: 80

persistence:
  enabled: true
  size: 20Gi

Instead of editing many YAML files, you update values in one place.

Note

values.yaml is the main file used to customize Helm deployments.

Helm Release

When a chart is installed, Helm creates a release.

Example:

helm install wordpress bitnami/wordpress

Here:

Item	Meaning
`wordpress`	Release name
`bitnami/wordpress`	Chart name

You can install the same chart multiple times with different release names.

helm install wordpress-dev bitnami/wordpress
helm install wordpress-prod bitnami/wordpress

Common Helm Commands

Install

helm install wordpress bitnami/wordpress

Install with Custom Values

helm install wordpress bitnami/wordpress -f values.yaml

Upgrade

helm upgrade wordpress bitnami/wordpress -f values.yaml

Rollback

helm rollback wordpress 1

Uninstall

helm uninstall wordpress

Tip

Helm tracks release revisions, which makes rollback easier during failed deployments.

Helm Command Flow

helm install wordpress
        ↓
Helm reads chart templates
        ↓
Helm applies values.yaml
        ↓
Helm renders Kubernetes manifests
        ↓
Objects are created in the cluster
        ↓
Release history is stored

Helm Install Example

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

helm install wordpress bitnami/wordpress

Check release:

helm list

Check Kubernetes resources:

kubectl get all
kubectl get pvc
kubectl get secrets

Example

A single Helm install can create Deployments, Services, Secrets, PVCs, and other required objects.

Helm Upgrade Example

Update values.yaml:

persistence:
  size: 100Gi

Apply upgrade:

helm upgrade wordpress bitnami/wordpress -f values.yaml

Check history:

helm history wordpress

Warning

Always review chart upgrade notes before upgrading production releases.

Helm Rollback Example

List release revisions:

helm history wordpress

Rollback to a previous revision:

helm rollback wordpress 1

Verify:

helm status wordpress

Success

Rollback is one of Helm's biggest production benefits because it helps recover from failed upgrades quickly.

Helm Uninstall Example

helm uninstall wordpress

Helm removes the Kubernetes objects created by the release.

Warning

PersistentVolumes may not always be deleted automatically depending on reclaim policy and chart configuration.

Helm vs kubectl

Task	kubectl	Helm
Apply one YAML	Easy	Possible
Manage full app	Manual	Simple
Customize app	Edit YAML files	Use values
Upgrade app	Manual	`helm upgrade`
Rollback app	Difficult	`helm rollback`
Delete app	Delete many objects	`helm uninstall`
Track revisions	No built-in app-level history	Built-in release history

When to Use Helm

Use Helm when:

application has many Kubernetes objects
same app is deployed across multiple environments
upgrades and rollbacks are required
teams need repeatable deployments
configuration should be centralized
third-party applications need installation

Examples:

WordPress
Prometheus
Grafana
Argo CD
NGINX Ingress Controller
Cert Manager
External Secrets Operator

Production Best Practices

Recommended

Pin chart versions during production installs
Store custom values.yaml in Git
Review generated manifests before applying
Use separate values files per environment
Keep secrets out of plain text values files
Test upgrades in staging first
Use helm history before rollback
Monitor workloads after every upgrade
Use GitOps tools like Argo CD or Flux for controlled Helm deployments

Do's

Use meaningful release names
Use namespaces for environment isolation
Keep values files small and clear
Version-control Helm values
Use helm template to preview manifests
Use helm diff plugin before production upgrades
Document chart version and app version
Back up persistent data before major upgrades

Don'ts

Don't edit Helm-managed resources manually without understanding impact
Don't store passwords directly in Git
Don't use random chart versions in production
Don't upgrade production charts without reading release notes
Don't delete PVCs blindly
Don't rely on Helm rollback as a replacement for backups
Don't install everything into the default namespace

Danger

Helm can create or update many Kubernetes objects at once. A wrong values file or chart version can impact production workloads quickly.

Useful Helm Commands

Task	Command
Add chart repo	`helm repo add <name> <url>`
Update repos	`helm repo update`
Search charts	`helm search repo <keyword>`
Install chart	`helm install <release> <chart>`
Install with values	`helm install <release> <chart> -f values.yaml`
Upgrade release	`helm upgrade <release> <chart> -f values.yaml`
List releases	`helm list -A`
Check status	`helm status <release>`
View history	`helm history <release>`
Rollback	`helm rollback <release> <revision>`
Uninstall	`helm uninstall <release>`
Render templates locally	`helm template <release> <chart>`
Validate install	`helm lint <chart>`

Helm in Production Workflow

Developer updates values.yaml
        ↓
Pull request review
        ↓
Render and validate templates
        ↓
Deploy to dev/staging
        ↓
Test application
        ↓
Deploy to production
        ↓
Monitor release
        ↓
Rollback if required

Tip

In production, Helm should be part of a controlled CI/CD or GitOps workflow.

Helm and GitOps

Helm works well with GitOps tools.

Common pattern:

Git repository
  ├── chart version
  ├── values-dev.yaml
  ├── values-staging.yaml
  └── values-prod.yaml
        ↓
Argo CD / Flux
        ↓
Kubernetes cluster

Note

Git becomes the source of truth, and Helm provides reusable packaging.

Troubleshooting Helm

Check Release

helm status wordpress

Check History

helm history wordpress

View Rendered YAML

helm template wordpress bitnami/wordpress -f values.yaml

Check Created Resources

kubectl get all -n <namespace>
kubectl get pvc -n <namespace>
kubectl get secrets -n <namespace>

Debug Install

helm install wordpress bitnami/wordpress --debug --dry-run

Bug

If a Helm release fails, check both Helm status and Kubernetes events.

kubectl get events -n <namespace> --sort-by=.lastTimestamp

Common Mistakes

Avoid These

Installing charts without checking default values
Forgetting to set namespace
Using default passwords
Not checking PVC retention behavior
Manually modifying Helm-managed objects
Upgrading without testing
Not pinning chart versions
Treating Helm as a backup solution

Simple Mental Model

Chart = Package
Values = Configuration
Release = Installed Application
Revision = Release Version
Repository = Chart Store

Quote

Helm lets you manage Kubernetes applications as applications, not as scattered YAML files.

Summary

Quote

Helm is a Kubernetes package manager
It groups many Kubernetes objects into one chart
A chart installed in a cluster becomes a release
values.yaml is used to customize deployments
Helm supports install, upgrade, rollback, and uninstall
Production usage requires version pinning, Git-based values, testing, and careful secret handling