Helm and Helm Chart

Helm — Comprehensive Production Guide

Helm eliminates the chaos of managing 5-6 separate Kubernetes YAML files per service. Instead of manually editing Deployment, Service, Ingress, and ServiceAccount manifests for every deploy, Helm packages them into one versioned chart and applies them with a single command.

📌 Remember: Helm is to Kubernetes what npm is to Node.js — a package manager that handles versioning, upgrades, and rollbacks.

Helm Chart

A chart is the core Helm unit — a folder containing all Kubernetes manifest templates and configuration defaults for one application.

Chart structure

Chart.yaml

📌 Remember: version is the chart version — bump it every time you change templates. appVersion is the version of the application itself.

Templates use Go template variables that Helm fills at deploy time:

💡 Tip: Always add extraVolumes and extraVolumeMounts support to your deployment template from the start. Adding them later requires a chart version bump and redeployment.

values.yaml

The default configuration file for a chart. All tunable parameters live here — image tag, replica count, resource limits, env vars. Environment-specific files like dev.values.yaml override these defaults at deploy time.

Base values.yaml

Environment override — dev.values.yaml

Only include keys you want to override. Everything else falls back to values.yaml:

🔴 Common Mistake: Putting secrets as plain text in values.yaml committed to your repo. Always use secretKeyRef pointing to a Kubernetes Secret, and store actual values in AWS Secrets Manager or Vault.

Helm Release

A running instance of a Helm chart deployed to a Kubernetes cluster. The same chart can be installed multiple times as different releases — each with its own name, namespace, and values. Helm tracks each release's revision history, enabling instant upgrades and rollbacks.

Core release commands

Revision history example

⚠️ Security: Rollback restores Kubernetes resource config only — Deployment spec, env vars, image tag. It does NOT revert database migrations or external state. Always test rollback in staging before a production incident.

💡 Tip: Always use --atomic in production pipelines. If new pods fail health checks, Helm automatically rolls back to the previous revision without manual intervention.

Helmfile

A declarative wrapper on top of Helm. Instead of running separate helm upgrade commands for each environment, Helmfile lets you define all releases, charts, and environment-specific values in one helmfile.yaml — deploying everything with a single helmfile apply command.

helmfile.yaml

Deploy commands

How value merging works

Helmfile layers values files in order — later files override earlier ones:

📌 Remember: Helmfile only upgrades releases that have actual changes — it runs helm diff internally and skips unchanged releases. This makes helmfile apply safe to run on every pipeline push.

OCI Chart Registry

Helm charts can be stored in any OCI-compatible container registry alongside Docker images. AWS ECR, GitHub Container Registry, and Docker Hub all support OCI chart storage — no separate chart server needed.

Push chart to ECR

Reference OCI chart in helmfile.yaml

🔴 Common Mistake: Using a flat ECR repo name like devops-network-helm. ECR OCI push requires the full nested path — devops-network-helm/devops-network-chart as the repository name. Creating the repo with just the parent name will cause a push failure.

Quick Reference