Part 1: Introduction and Installation

Series Navigation: ← Back to Series Overview | Part 2: Creating Your First Chart →

Introduction

When I first started deploying applications to Kubernetes, I maintained separate YAML files for each environment—development, staging, and production. Each file was a near-identical copy with small variations in replica counts, resource limits, or image tags. It was tedious, error-prone, and didn't scale. One forgotten change in staging could break production deployments.

That's when I discovered Helm. Instead of managing dozens of YAML files, I could define my application once as a template and use values to customize deployments. Helm became my package manager for Kubernetes—similar to how npm manages Node.js packages or apt manages Debian packages.

In this first part of the series, I'll share what I've learned about Helm's fundamentals, architecture, and how to get started. We'll use a TypeScript Node.js application as our example throughout the series.

What is Helm?

Helm is the package manager for Kubernetes. It helps you define, install, and upgrade Kubernetes applications. At its core, Helm manages Charts—packages of pre-configured Kubernetes resources.

Think of a Helm Chart like a recipe. The recipe (chart) defines the ingredients (Kubernetes resources) and instructions (templates) needed to create a meal (deployed application). You can customize the recipe by adjusting values—more servings, different spices—without rewriting the entire recipe.

Key Concepts

From my experience working with Helm, these concepts are fundamental:

1. Charts A Chart is a bundle of information necessary to create an instance of a Kubernetes application. It contains:

• Template files (Kubernetes YAML with placeholders)

• Default configuration values

• Dependencies on other charts

• Metadata and documentation

2. Releases When you install a Chart into Kubernetes, it creates a Release. A Release is a specific instance of a Chart running in your cluster. You can have multiple Releases from the same Chart—for example, one for your web app and another for a worker service.

3. Repositories Chart repositories are locations where Charts can be stored and shared. Artifact Hub hosts thousands of community Charts. You can also host private repositories for internal Charts.

4. Values Values are the configuration parameters that customize a Chart. Instead of hardcoding settings in templates, you use placeholders that get replaced with values at deployment time.

Helm Architecture

Understanding Helm's architecture helped me design better deployment workflows. Helm v3 (the current version) simplified the architecture significantly from v2.

How Helm Works

Here's what happens when you run helm install:

1. Template Rendering: Helm takes your Chart templates and merges them with values

2. Manifest Generation: Produces valid Kubernetes YAML manifests

3. API Communication: Sends manifests to Kubernetes API server

4. Resource Creation: Kubernetes creates the resources (Pods, Services, etc.)

5. Release Tracking: Helm stores release information as Kubernetes Secrets for tracking

Helm v3 vs Helm v2

If you're new to Helm, you only need to worry about v3. But if you've heard of Tiller, here's what changed:

Helm v2 required a server-side component called Tiller running in your cluster. This created security concerns and added complexity.

Helm v3 (released November 2019):

• ✅ No Tiller - client-only architecture

• ✅ Improved security with namespace-scoped releases

• ✅ Release information stored as Kubernetes Secrets

• ✅ Better upgrade strategies with three-way merge

• ✅ Chart dependency management improvements

Always use Helm v3 for new projects.

Installing Helm

Installing Helm is straightforward. I'll show you multiple methods based on your operating system.

macOS

Using Homebrew (my preferred method):

# Install Helm
brew install helm

# Verify installation
helm version

Expected output:

version.BuildInfo{Version:"v3.14.0", GitCommit:"...", GitTreeState:"clean", GoVersion:"go1.21.5"}

Linux

Using script (recommended):

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

# Verify
helm version

Using package managers:

# 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-get update
sudo apt-get install helm

# Fedora/CentOS/RHEL
sudo dnf install helm

Windows

Using Chocolatey:

choco install kubernetes-helm

Using Scoop:

scoop install helm

Binary Download

For any platform, you can download binaries directly:

# Visit https://github.com/helm/helm/releases
# Download the appropriate binary for your OS
# Extract and move to your PATH

# Example for Linux
wget https://get.helm.sh/helm-v3.14.0-linux-amd64.tar.gz
tar -zxvf helm-v3.14.0-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm

Helm Configuration

After installation, Helm stores configuration in your home directory:

# View Helm environment variables
helm env

# Configuration directory (usually ~/.config/helm or %APPDATA%\helm on Windows)
# Cache directory for charts
# Data directory for plugins and starters

Shell Completion

I highly recommend setting up shell completion—it saves significant typing:

# Bash
helm completion bash > /etc/bash_completion.d/helm

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

# Fish
helm completion fish > ~/.config/fish/completions/helm.fish

After setting up, reload your shell and you can use Tab to autocomplete Helm commands and flags.

First Steps with Helm

Let's verify everything works and explore basic commands.

Adding a Chart Repository

Chart repositories are like npm registries—they host published Charts. Let's add the official Bitnami repository:

# Add Bitnami repository
helm repo add bitnami https://charts.bitnami.com/bitnami

# Update repository index
helm repo update

# List repositories
helm repo list

Output:

NAME    URL
bitnami https://charts.bitnami.com/bitnami

Searching for Charts

# Search Artifact Hub
helm search hub nginx

# Search added repositories
helm search repo nginx

# Get chart information
helm show chart bitnami/nginx
helm show values bitnami/nginx

Installing a Chart

Let's install a simple chart to test our setup:

# Install nginx chart
helm install my-nginx bitnami/nginx

# List releases
helm list

# Check deployment
kubectl get all -l app.kubernetes.io/instance=my-nginx

Inspecting a Release

# Get release status
helm status my-nginx

# Get manifest of what was deployed
helm get manifest my-nginx

# Get values used for the release
helm get values my-nginx

Cleaning Up

# Uninstall the release
helm uninstall my-nginx

# Verify removal
helm list

Understanding Chart Structure

Before we create our own Chart in the next part, let's look at what's inside a Chart:

# Download a chart without installing
helm pull bitnami/nginx --untar

# Explore the structure
tree nginx/

A basic Chart structure:

my-chart/
├── Chart.yaml          # Chart metadata (name, version, description)
├── values.yaml         # Default configuration values
├── charts/             # Dependency charts
├── templates/          # Kubernetes manifest templates
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl   # Template helpers
│   └── NOTES.txt      # Post-install notes
└── README.md          # Documentation

Chart.yaml

Metadata about the Chart:

apiVersion: v2
name: my-app
description: My TypeScript application
type: application
version: 1.0.0        # Chart version
appVersion: "1.0.0"   # Application version

values.yaml

Default configuration values:

replicaCount: 1

image:
  repository: my-registry/my-app
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 3000

Templates

Template files use Go templating with special functions:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app: {{ .Chart.Name }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: {{ .Values.service.port }}

Common Helm Commands

Here are the commands I use daily:

# Repository management
helm repo add <name> <url>     # Add repository
helm repo update               # Update repository indexes
helm repo list                 # List repositories
helm repo remove <name>        # Remove repository

# Chart operations
helm search hub <keyword>      # Search Artifact Hub
helm search repo <keyword>     # Search added repositories
helm show chart <chart>        # Show chart metadata
helm show values <chart>       # Show default values
helm pull <chart>              # Download chart

# Release management
helm install <name> <chart>    # Install chart as release
helm upgrade <name> <chart>    # Upgrade release
helm rollback <name> <rev>     # Rollback to revision
helm uninstall <name>          # Uninstall release
helm list                      # List releases
helm status <name>             # Get release status
helm history <name>            # Show release history

# Development
helm create <name>             # Create new chart
helm lint <chart>              # Lint chart
helm template <name> <chart>   # Render templates locally
helm package <chart>           # Package chart as .tgz

Helm vs. kubectl

You might wonder: "Why use Helm when I can use kubectl?"

Here's my perspective from managing production deployments:

Aspect	kubectl	Helm
Complexity	Apply individual YAML files	Manage complete applications
Templating	None (requires external tools)	Built-in with Go templates
Versioning	Manual Git tags	Chart and release versions
Rollback	Manual kubectl commands	Single helm rollback command
Configuration	Multiple files or tools	Centralized values files
Reusability	Copy-paste YAML	Package and share Charts
Dependencies	Manual ordering	Automatic dependency management

Both tools are essential. I use:

• kubectl: For ad-hoc operations, debugging, and simple deployments

• Helm: For managing complex applications, multi-environment deployments, and team collaboration

What's Next?

Now that you have Helm installed and understand the basics, you're ready to create your first Chart. In the next part, we'll:

• Create a Helm Chart for a TypeScript Node.js application

• Learn about Chart structure and organization

• Write templates for Deployment and Service

• Customize deployments with values

• Test and debug our Chart

The hands-on approach in Part 2 will solidify these concepts and prepare you for more advanced topics.

---

Series Navigation: ← Back to Series Overview | Part 2: Creating Your First Chart →

Key Takeaways

• ✅ Helm is the package manager for Kubernetes, managing Charts, Releases, and Repositories

• ✅ Helm v3 simplified architecture by removing Tiller

• ✅ Charts are packages of Kubernetes resources with templates and values

• ✅ Installation is straightforward with package managers

• ✅ Understanding basic commands is essential for daily workflows

• ✅ Helm complements kubectl for production deployments