Helm for Kubernetes Deployments

What Problem Does Helm Solve?

Imagine you need to deploy a web application to Kubernetes. Without Helm, you'd manually write dozens of YAML files for deployments, services, configmaps, secrets, and more. Then, if you need to deploy the same app in different environments (staging, production), you'd either duplicate all these files or manually edit them each time. This becomes messy and error-prone.

Helm is the package manager for Kubernetes—think of it like npm for Node.js or pip for Python, but for Kubernetes applications. It packages all your Kubernetes configuration files into a single reusable unit called a Chart, complete with built-in templating, version control, and configuration management.

Why Helm Exists

Kubernetes is powerful but verbose. Helm exists to:

Reduce repetition by using templates instead of duplicating configs
Enable reusability so you write once, deploy anywhere
Simplify updates with versioned, repeatable deployments
Manage complexity by organizing related resources together
Share applications with the community through public chart repositories

How Helm Works (Core Concepts)
Create a Chart
Understanding Chart.yaml
Understanding the Values File
Creating Deployment Templates
Installing and Upgrading Charts
Real-World Use Cases
Best Practices
Related Concepts to Explore
Conclusion

How Helm Works (Core Concepts)

Think of Helm as a templating system + package manager. Here's how it works:

Chart - A collection of files (templates + metadata + defaults) that describe a Kubernetes application
Values - Configuration values that customize the chart (like variables you pass to a function)
Templates - Kubernetes YAML files with placeholders that get filled in with values
Release - An instance of a chart with a specific set of values deployed to your cluster

Simple Analogy: A Helm Chart is like a recipe. The values.yaml is like a shopping list with default quantities. Templates are the cooking instructions. When you install a chart, you create a "Release"—the actual meal on your plate.

1. Create a Chart

To create a new Helm chart, use the following command:

helm create myapp

This generates a directory structure with all the files needed for a basic chart:

myapp/
  Chart.yaml              # Metadata about the chart
  values.yaml             # Default configuration values
  charts/                 # Directory for dependencies
  templates/              # YAML templates for Kubernetes resources
    deployment.yaml       # Deployment template
    service.yaml          # Service template
    _helpers.tpl          # Helper functions for templates

What Each Part Does:

Chart.yaml - Tells Helm what this chart is, its version, and who maintains it
values.yaml - Default settings (like "use nginx image" or "2 replicas")
templates/ - YAML files with {{ }} placeholders that get filled with values
charts/ - Stores other charts your chart depends on (like adding npm packages)

2. Understanding Chart.yaml

The Chart.yaml file is metadata—like a book's title page. It tells Helm and users essential information about your chart:

apiVersion: v2
name: myapp
version: 0.1.0
appVersion: "1.0.0"
description: A Helm chart for Kubernetes
maintainers:
  - name: Emem Isaac
    email: contact@example.com
keywords:
  - web
  - app

Field Explanations:

apiVersion: v2 - Use version 2 (this is the Helm 3 standard)
name - Your chart's name (must be lowercase, no spaces)
version - Chart version (for packaging and distribution; increment when you change the chart)
appVersion - The version of the application being deployed (e.g., "1.0.0" for your app)
description - What this chart does (visible when others browse charts)
maintainers - Who maintains this chart (important for community charts)
keywords - Tags for searchability

Real-World Example: If you're deploying WordPress with Helm, appVersion would be "6.4.2" (WordPress version), but version might be "10.0.0" (Helm chart version).

3. Understanding the Values File

The values.yaml file is where you define default configuration. Think of it as settings you can change without touching the templates.

# Application Configuration
replicaCount: 2                           # How many copies of the app to run
image:
  repository: nginx                       # Docker image source
  tag: stable                             # Image version
  pullPolicy: IfNotPresent               # When to download the image

# Service Configuration (how traffic reaches your app)
service:
  type: ClusterIP                         # Service type
  port: 80                                # What port to listen on

# Resource Limits (how much CPU/memory each pod can use)
resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi

# Environment Variables
env:
  LOG_LEVEL: info
  ENVIRONMENT: production

Why This Matters: Instead of creating multiple chart files for staging vs. production, you use one chart with different values files. You might have:

values.yaml - staging defaults (1 replica, 256MB memory)
values-prod.yaml - production settings (3 replicas, 1GB memory)

You reference values in templates using: {{ .Values.replicaCount }}

4. Creating Deployment Templates

Templates are Kubernetes YAML files with placeholders (marked with {{ }}). When you install the chart, Helm fills in these placeholders with actual values.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
  namespace: {{ .Release.Namespace }}
spec:
  replicas: {{ .Values.replicaCount }}      # Use value from values.yaml
  selector:
    matchLabels:
      app: {{ include "myapp.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "myapp.name" . }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
          env:
            - name: LOG_LEVEL
              value: {{ .Values.env.LOG_LEVEL }}
            - name: ENVIRONMENT
              value: {{ .Values.env.ENVIRONMENT }}

Understanding the Syntax:

{{ .Values.replicaCount }} - Gets value from values.yaml
{{ .Chart.Name }} - Gets chart name from Chart.yaml
{{ .Release.Namespace }} - Gets the namespace where chart is deployed
{{ include "myapp.fullname" . }} - Calls a helper function (defined in _helpers.tpl)
{{- }} - Removes whitespace (helps with formatting)
| nindent 12 - Indents output (Kubernetes YAML is very indentation-sensitive)

What Happens When You Install: If you install with helm install myapp ./myapp and have replicaCount: 2 in values.yaml, Helm will generate:

spec:
  replicas: 2

But if you override: helm install myapp ./myapp --set replicaCount=5, it generates:

spec:
  replicas: 5

5. Installing and Upgrading Charts

Installing a Chart - Deploy your application for the first time:

# Install from local chart
helm install myapp ./myapp

# Install with custom values
helm install myapp ./myapp --values values-prod.yaml

# Install and override specific values
helm install myapp ./myapp --set replicaCount=5 --set image.tag=v2.0.0

# Install to a specific namespace
helm install myapp ./myapp -n production --create-namespace

# Give the release a specific name
helm install my-app-instance ./myapp

Upgrading a Chart - Update an already-installed application:

# Upgrade to a new version of the chart
helm upgrade myapp ./myapp

# Upgrade with new values
helm upgrade myapp ./myapp --values values-prod.yaml

# Rollback if upgrade goes wrong
helm rollback myapp 1                    # Go back to previous release

Real-World Scenario:

# Initial deployment (version 1.0.0 of your app)
helm install myapp ./myapp --set image.tag=v1.0.0

# Two weeks later, you need more replicas
helm upgrade myapp ./myapp --set replicaCount=5

# New critical bug? Rollback immediately
helm rollback myapp

Checking Status:

# List all releases
helm list

# See release history (all versions deployed)
helm history myapp

# Get details about a release
helm status myapp

6. Real-World Use Cases

Use Case 1: Multi-Environment Deployment You're deploying a web app to staging and production:

Same chart for both
values-staging.yaml: 1 replica, 512MB memory, staging database
values-prod.yaml: 5 replicas, 4GB memory, production database
Single command deploys differently: helm install app ./myapp -f values-staging.yaml

Use Case 2: Microservices Architecture You have 10 microservices. Create one chart template, then:

helm install auth-service ./microservice --set serviceName=auth
helm install payment-service ./microservice --set serviceName=payment
helm install user-service ./microservice --set serviceName=user

Use Case 3: Third-Party Applications Installing open-source software (PostgreSQL, Redis, Prometheus):

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

# Install PostgreSQL with one command
helm install my-postgres bitnami/postgresql --set postgres.password=secret

Use Case 4: GitOps + Continuous Deployment Store Helm values in Git, automatically deploy when they change:

# CI/CD pipeline automatically runs:
helm upgrade app ./myapp -f values.yaml

7. Best Practices

Configuration Management

Use values.yaml for ALL configuration that might change
Never hardcode secrets; use .Values.secrets and Secret resources
Document every value with comments explaining what it does

Templating Best Practices

Use helm lint to validate your chart before sharing: helm lint ./myapp
Use helm template to preview what will be created: helm template myapp ./myapp
Keep templates simple; use helper functions for complex logic

Testing & Validation

# Validate chart syntax
helm lint ./myapp

# See generated YAML before installing (dry run)
helm install myapp ./myapp --dry-run --debug

# Actually install and test
helm install myapp ./myapp
helm test myapp                          # Run test pods defined in chart

Versioning & Distribution

Increment chart version when you make changes
Use semantic versioning (1.0.0, 1.1.0, 2.0.0)
Consider publishing to a chart repository so others can use it

Resource Management

Always define resource requests and limits
Use helm get values myapp to check what values are actually deployed

8. Related Concepts to Explore

To deepen your Kubernetes and deployment knowledge:

Within Helm Ecosystem:

Helm Hooks - Run scripts at specific lifecycle events (pre-install, post-upgrade)
Helm Subcharts - Use other charts as dependencies in your chart
Chart Repositories - Host and distribute charts (like Artifacthub.io)
Values Validation - Use JSON schemas to validate user-provided values

Kubernetes Concepts:

ConfigMaps & Secrets - Store configuration and sensitive data
StatefulSets - Deploy stateful applications (databases, caches)
Operators - Complex application management beyond Helm's scope
Ingress - Route external traffic to services
Persistent Volumes - Persistent storage for databases and files

Related Tools:

Kustomize - Alternative to Helm for configuration management
ArgoCD - GitOps tool that uses Helm for declarative deployments
Flux - Another GitOps approach for automatic deployments
Helmfile - Manage multiple Helm releases in one file

Advanced Topics:

Multi-cluster Deployments - Deploy same chart to multiple Kubernetes clusters
Helm Security - Verify chart signatures, manage RBAC with Helm
Chart Testing - Automated testing for Helm charts

Conclusion

Helm streamlines Kubernetes deployments by packaging resources into reusable, configurable charts. Rather than managing dozens of YAML files manually, Helm lets you:

Template configurations so one chart works for many scenarios
Version your deployments and rollback easily if needed
Share applications as packages (via Helm repositories)
Automate repetitive deployment tasks
Scale from single apps to microservices architectures

Whether you're deploying a single application or managing a company-wide Kubernetes infrastructure, Helm eliminates manual configuration work and makes deployments reliable, repeatable, and version-controlled. Master Helm, and you've leveled up your entire deployment workflow.

Isaac.

Helm for Kubernetes Deployments