Skip to main content
Kubernetes Introduction
CHAPTER 16 Intermediate

Helm Charts Basics

Updated: May 15, 2026
25 min read

# CHAPTER 16

Helm Charts Basics

1. Introduction

As your Kubernetes architecture matures, you will realize that managing raw YAML files becomes an absolute nightmare. A single enterprise application might require a Deployment YAML, a Service YAML, an Ingress YAML, two ConfigMaps, and a Secret. If you want to deploy that exact same application to Staging and Production, you have to copy/paste 6 files and manually find-and-replace variables. To solve this chaos, the industry adopted Helm: The official Package Manager for Kubernetes.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define Helm and its role as a Kubernetes Package Manager.
  • Understand the anatomy of a Helm "Chart".
  • Understand how Helm utilizes Go Templating to inject variables.
  • Install, upgrade, and uninstall applications using the helm CLI.
  • Add remote Helm Repositories to download community software.

3. Beginner-Friendly Explanation

Imagine installing software on a Windows computer.
  • Without Helm (Raw YAML): You want to install a web browser. You have to manually create the C:\Program Files\Browser folder, manually copy 500 individual .dll files into the folder, manually edit the Windows Registry, and manually create a desktop shortcut. It takes hours.
  • With Helm: You double-click a single .exe file. An installer wizard pops up, asks you a few preference questions, and installs everything flawlessly in 5 seconds.

Helm is the "Installer Wizard" (The Package Manager) for Kubernetes. It bundles dozens of complex YAML files into a single, installable package called a Chart.

4. The Anatomy of a Helm Chart

A Helm Chart is simply a folder with a highly specific structure:
text
123456
my-app-chart/
  Chart.yaml          # Metadata about the package (Name, Version)
  values.yaml         # The "Settings" file (Variables you can change)
  templates/          # The actual Kubernetes YAML files
    deployment.yaml
    service.yaml

5. Go Templating (The Magic)

Inside the templates/deployment.yaml file, you won't see hardcoded values like replicas: 3. Instead, you will see strange double-curly braces:
yaml
12345
spec:
  replicas: {{ .Values.replicaCount }}
  containers:
    - name: my-app
      image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

When you run helm install, Helm reads your values.yaml file, grabs your specific settings, injects them into the double-curly braces, generates standard Kubernetes YAML, and sends it to the API Server. This allows one Chart to be deployed infinite times with infinite configurations!

6. Public Helm Repositories

You do not have to write Charts from scratch! The global Kubernetes community has authored thousands of perfect Charts for standard software. If you need to install a complex Prometheus/Grafana monitoring stack, you do not write the 50 YAML files manually. You simply search the Artifact Hub, add the community repository, and type helm install prometheus.

7. Mini Project: Install Software via Helm

Let's install Helm and use it to deploy an application from a public repository.

Step-by-Step Tutorial:

  1. 1. Install the Helm CLI on your laptop (Follow instructions on helm.sh, usually brew install helm on Mac or winget install Helm.Helm on Windows).
  1. 2. Let's add the wildly popular "Bitnami" public repository to our Helm client:

bash
12
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
  1. 3. Let's install a production-grade Redis cache into our cluster. It takes exactly one command:
bash
1
helm install my-redis bitnami/redis
  1. 4. *The Magic:* Run kubectl get pods. You will see Helm automatically provisioned Master nodes, Replica nodes, and attached PVCs. It deployed thousands of lines of YAML for you instantly.
  1. 5. Check your Helm installations:
bash
1
helm list
  1. 6. When you are finished, uninstall the entire Redis stack cleanly:
bash
1
helm uninstall my-redis

8. Real-World Scenarios

A company has three environments: Dev, Staging, and Prod. They maintain exactly ONE Helm Chart for their core API. When deploying to Dev, they run: helm install api my-chart -f dev-values.yaml (Which sets replicas to 1 to save money). When deploying to Prod, they run: helm install api my-chart -f prod-values.yaml (Which sets replicas to 50 and enables autoscaling). The underlying YAML templates never change, drastically reducing human error.

9. Best Practices

  • Chart Versioning: A Helm Chart has its own version number (e.g., v1.2.0), which is completely separate from the Application's version number (e.g., Node.js v18). Always strictly pin your Chart versions when installing software in production. If you don't, helm upgrade might pull a radically redesigned community Chart and break your architecture.

10. Common Mistakes

  • Directly Editing Helm Pods: If you use kubectl edit deployment my-redis to manually change a setting on an application that was installed via Helm, you have created "Configuration Drift." The next time an engineer runs helm upgrade, Helm will blindly overwrite your manual changes to match the Chart's values.yaml file, erasing your work! Always make changes inside the values.yaml file.

11. Exercises

  1. 1. What is the fundamental purpose of the values.yaml file within a Helm Chart directory structure?
  1. 2. Explain the process of Go Templating. How does Helm bridge the gap between static YAML files and dynamic environment configurations?

12. FAQs

Q: Is Helm the only way to manage YAMLs? A: No. Kustomize is a highly popular alternative built directly into kubectl (kubectl apply -k). While Helm uses templates (variables injection), Kustomize uses an "Overlay" model (patching and merging static YAML files). Many enterprises use a combination of both!

13. Interview Questions

  • Q: Describe the architectural advantages of utilizing Helm as a Kubernetes package manager versus managing dozens of raw YAML manifests. How does Helm facilitate environment parity between Staging and Production?
  • Q: A developer manually scales a Deployment installed via Helm from 2 replicas to 5 using kubectl scale. The following day, a CI/CD pipeline runs helm upgrade on that release. What will the resulting replica count be, and why? Describe the concept of Configuration Drift.

14. Summary

In Chapter 16, we conquered YAML fatigue. We introduced Helm as the indispensable package manager for Kubernetes, elevating our workflow from managing granular, static manifests to deploying holistic, parameterized applications. We explored the directory structure of a Helm Chart, witnessed the dynamic injection capabilities of Go Templating via the values.yaml file, and successfully tapped into global community repositories to deploy a complex, production-grade Redis cluster with a single terminal command.

15. Next Chapter Recommendation

We know how to deploy applications with Helm manually. But typing helm install on your laptop is still manual labor. We need robots to do it for us. Proceed to Chapter 17: CI/CD with Kubernetes.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·