What Is a Helm Chart in Kubernetes?

Detailed Answer

What Is Helm?

Helm is the package manager for Kubernetes, analogous to apt for Debian or npm for Node.js. It solves the problem of managing multiple Kubernetes YAML files for an application by bundling them into a single, versioned, configurable package called a chart.

Chart Structure

A Helm chart is a directory with a specific structure:

my-app/
  Chart.yaml          # Chart metadata (name, version, dependencies)
  values.yaml         # Default configuration values
  templates/          # Kubernetes manifest templates
    deployment.yaml
    service.yaml
    ingress.yaml
    configmap.yaml
    _helpers.tpl      # Template helper functions
  charts/             # Sub-charts (dependencies)
  .helmignore         # Files to ignore when packaging

Chart.yaml

apiVersion: v2
name: my-app
description: A web application with Redis cache
type: application
version: 1.2.0        # Chart version
appVersion: "3.5.1"   # Application version
dependencies:
  - name: redis
    version: 18.x.x
    repository: https://charts.bitnami.com/bitnami

values.yaml

replicaCount: 3

image:
  repository: my-app
  tag: "3.5.1"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  host: app.example.com

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

Template Example

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-app.fullname" . }}
  labels:
    {{- include "my-app.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-app.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-app.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: 8080
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Core Helm Commands

# Add a chart repository
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Search for charts
helm search repo nginx

# Install a chart (creates a release)
helm install my-release bitnami/nginx \
  --namespace production \
  --values custom-values.yaml

# List installed releases
helm list -n production

# Upgrade a release with new values
helm upgrade my-release bitnami/nginx \
  --namespace production \
  --set replicaCount=5

# View release history
helm history my-release -n production

# Rollback to a previous revision
helm rollback my-release 2 -n production

# Uninstall a release
helm uninstall my-release -n production

Customizing Charts with Values

There are multiple ways to override default values:

# Using a custom values file
helm install my-release ./my-app -f production-values.yaml

# Using --set for individual values
helm install my-release ./my-app \
  --set replicaCount=5 \
  --set image.tag="4.0.0" \
  --set ingress.enabled=true

# Combining both (--set takes precedence)
helm install my-release ./my-app \
  -f production-values.yaml \
  --set image.tag="hotfix-4.0.1"

# Preview rendered templates without installing
helm template my-release ./my-app -f production-values.yaml

# Dry-run against the cluster (validates with API server)
helm install my-release ./my-app --dry-run

Helm Release Lifecycle

1. Install: helm install renders templates with values and applies them to the cluster. Helm stores the release metadata as a Secret in the target namespace.
2. Upgrade: helm upgrade computes the diff between the current and new rendered manifests and applies changes.
3. Rollback: helm rollback re-applies the manifests from a previous revision.
4. Uninstall: helm uninstall deletes all resources created by the release.

# View what Helm would change during an upgrade
helm diff upgrade my-release ./my-app -f new-values.yaml
# (requires the helm-diff plugin)

Helm Hooks

Hooks allow running Jobs at specific points in the release lifecycle:

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    "helm.sh/hook": pre-upgrade
    "helm.sh/hook-weight": "0"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: my-app:latest
          command: ["./migrate.sh"]
      restartPolicy: Never

Common hooks: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete.

Chart Repositories and OCI

Helm supports both traditional HTTP repositories and OCI (container) registries:

# Traditional repo
helm repo add my-repo https://charts.example.com

# OCI registry (Helm 3.8+)
helm push my-app-1.2.0.tgz oci://registry.example.com/charts
helm install my-release oci://registry.example.com/charts/my-app --version 1.2.0

Best Practices

1. Always pin chart and image versions in production. Never use latest.
2. Use helm template and helm lint in CI/CD pipelines to catch errors early.
3. Store custom values files in Git alongside your application code.
4. Use helm diff before upgrading to understand what will change.
5. Keep charts in an OCI registry for versioning and access control.