Helm Charts — Packaging K8s Apps

The Core Philosophy of Templating

At its simplest, a Helm Chart is a collection of files that describe a related set of Kubernetes resources. Instead of maintaining static files, Helm uses a templating engine to inject values into Kubernetes manifests at runtime. The reasoning behind this is modularity; you define your core deployment structure once and expose only the volatile parameters—such as replica counts, image tags, or resource limits—as configurable variables. When you run a Helm command, it processes these templates against a values file, producing standard Kubernetes YAML. This abstraction layer prevents the manual copy-pasting of manifest files, which is the primary source of configuration drift in production environments. By decoupling the static configuration logic from the environment-specific data, you create a system where the same chart can safely serve production, staging, and development namespaces without modification to the base templates themselves.

# Example of a template snippet (deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-app
spec:
  replicas: {{ .Values.replicaCount }} # Configurable replica count
  template:
    spec:
      containers:
      - name: web
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

Managing Configuration via Values Files

The true power of Helm lies in the values.yaml file, which acts as the source of truth for the variables defined in your templates. By separating configuration from the deployment logic, you achieve a cleaner separation of concerns. The templating engine iterates over this file, replacing occurrences of variable references with the specified keys and values. This structure is essential because it allows infrastructure teams to maintain a set of hardened defaults within the chart, while application developers provide custom overrides via command-line flags or environment-specific values files. Understanding this mechanism is vital because it enables 'Don't Repeat Yourself' (DRY) principles within your cluster management. If you need to change a core security policy or a global label, you modify a single location, and the change propagates across all instances of the application, ensuring consistency and drastically reducing the surface area for human error during cluster updates or routine maintenance tasks.

# values.yaml: default configuration values
replicaCount: 3
image:
  repository: registry.internal/app
  tag: 1.2.0

# Command to override values during installation:
# helm install my-app ./my-chart --set replicaCount=5

Lifecycle Management and Versioning

Helm treats releases as discrete, versioned objects rather than just a pile of running resources. When you execute an installation or an upgrade, Helm tracks the revision history of your application. If a deployment fails or introduces an unwanted behavior, you have the native ability to roll back to a specific previous release version. This is achieved by storing the state of the release as a secret inside the cluster, which allows Helm to compare the current state against the desired state during every operation. The reason this is critical is that it provides a transactional safety net for your infrastructure. Instead of manually deleting and recreating pods or services, you issue a single command that brings the cluster to the exact desired state defined by the chart version. This versioning approach turns potentially destructive infrastructure changes into predictable, reversible transitions, maintaining high availability during updates.

# Upgrade an existing release
helm upgrade my-app ./my-chart --values production-values.yaml

# Roll back if the upgrade fails
helm rollback my-app 1 # Roll back to revision 1

Dependencies and Chart Composition

Modern applications are rarely composed of a single microservice; they often rely on databases, message brokers, or caching layers. Helm solves this through 'dependencies,' which allow you to include sub-charts within your parent chart. This hierarchical organization enables the grouping of complex service architectures into a single logical unit. When you bundle these dependencies, Helm manages the installation sequence and lifecycle for all included components, ensuring that your core application does not start until its required infrastructure dependencies are ready. This 'chart composition' methodology is robust because it encapsulates entire environments as a single deployment package. By treating supporting services as dependencies of the main application chart, you ensure that the required network policies, persistent volumes, and secrets are provisioned in sync, avoiding the classic 'missing dependency' runtime errors that frequently occur in unmanaged, distributed manual deployments.

# Chart.yaml: declaring a sub-chart dependency
dependencies:
  - name: postgresql
    version: 12.x.x
    repository: https://charts.bitnami.com/bitnami

# Run this to download the sub-charts
helm dependency build ./my-chart

Testing and Verification with Linting

Before deploying a chart to a live cluster, you must ensure it adheres to valid syntax and logic. Helm provides a linting command that acts as a quality gate, parsing your templates and checking for potential failures before they manifest as deployment errors. This process validates that your YAML structure is sound and that all required variables are present. The reasoning here is proactive risk mitigation; by running validation locally or in a build pipeline, you catch structural errors—like mismatched indents or missing values—early in the development lifecycle. This prevents the 'apply-then-fail' feedback loop that wastes time and causes unnecessary resource instability. Mastering the linting process is the hallmark of an effective operator, as it ensures that every release is structurally guaranteed to be valid before it interacts with the cluster's API server, providing a stable foundation for automated deployment workflows.

# Check the chart for structural correctness
helm lint ./my-chart

# Dry-run to see generated output without installing
helm install --debug --dry-run my-app ./my-chart

Interview questions

All Docker & Kubernetes interview questions →

Check yourself

Take the full Docker & Kubernetes quiz →