Designing and Using Helm Charts for Application Packaging

Helm is a tool that helps you package and manage Kubernetes applications. Think of Kubernetes as the operating system for running containers — and Helm as the app store and package manager combined. Just like you use a package manager on your computer (like APT on Ubuntu or Homebrew on macOS) to install and update software without hunting down files, Helm lets you install, upgrade, and remove entire Kubernetes applications with simple commands.

A Helm chart is a collection of files that describe a set of Kubernetes resources. Instead of writing a separate YAML file for a Deployment, a Service, a ConfigMap, and a PersistentVolumeClaim, you put them all into one chart. The chart is like a blueprint for your application. It includes templates — these are YAML files with placeholders, written in a special language called Go templates. The placeholders get filled in with actual values when you install the chart.

The values are stored in a file called values.yaml. This file is the central place where you define things like the number of replicas (how many copies of your app to run), the image tag (which version of the container to use), and the port your app listens on. When someone installs the chart, Helm takes the templates and merges them with the values from values.yaml to produce the final Kubernetes YAML files. Those files are then sent to the Kubernetes API, which creates the actual resources.

This design solves a huge problem: configuration drift. If you manually edit YAML files in different environments (development, staging, production), they quickly become inconsistent. With Helm, you keep one chart and one set of templates. You change only the values.yaml file for each environment. For example, your development values.yaml might set replicas to 1 and use a debug image tag. Your production values.yaml sets replicas to 5 and uses a stable image tag. The templates never change. This is called separation of concerns — the structure (the templates) is separate from the settings (the values).

Helm also manages releases. Every time you install a chart, Helm creates a release — a record of that installation. You can upgrade a release with new values, roll back to a previous version, or delete the release entirely. This is critical for application lifecycle management. In the old way, you would have to track your YAML files manually and apply them with kubectl apply. If something went wrong, rolling back meant finding the old files and hoping you remembered the correct state. With Helm, one command rolls back to the previous release.

Key terms in Helm:

A simple example. Suppose you have a web app that needs a Deployment and a Service. Without Helm, you would write two YAML files:

deployment.yaml:

apiVersion: apps/v1 kind: Deployment metadata: name: my-web-app spec: replicas: 3 selector: matchLabels: app: my-web-app template: metadata: labels: app: my-web-app spec: containers: - name: web image: nginx:1.21 ports: - containerPort: 80

service.yaml:

apiVersion: v1 kind: Service metadata: name: my-web-app-svc spec: selector: app: my-web-app ports: - port: 80 targetPort: 80

With Helm, you create a chart structure:

mychart/ Chart.yaml values.yaml templates/ deployment.yaml service.yaml

The Chart.yaml file contains metadata about the chart (name, version, description). The values.yaml file contains:

replicaCount: 3 image: repository: nginx tag: "1.21" service: port: 80

The deployment.yaml template looks like this:

apiVersion: apps/v1 kind: Deployment metadata: name: {{ .Values.nameOverride | default "my-web-app" }} spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: app: {{ .Values.nameOverride | default "my-web-app" }} template: metadata: labels: spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" ports: - containerPort: {{ .Values.service.port }}

When you run helm install my-release ./mychart, Helm processes the templates, replaces the placeholders with the values from values.yaml, and creates the Deployment and Service in Kubernetes. If you want to change the number of replicas to 5 for production, you create a new values file (prod-values.yaml) with replicaCount: 5 and run helm upgrade my-release ./mychart -f prod-values.yaml.

This is the heart of designing and using Helm charts for application packaging. You design the templates once, and you package them as a chart that can be shared, versioned, and reused across environments.

An IT professional working for a mid-sized e-commerce company is responsible for deploying a microservices-based application. The application consists of ten services: a web frontend, an authentication service, a product catalogue service, a shopping cart service, an order service, a payment service, a notification service, and three data stores (PostgreSQL, Redis, and Elasticsearch). Each service has its own Kubernetes resources: Deployments, Services, ConfigMaps, and sometimes PersistentVolumeClaims and NetworkPolicies.

Without Helm, the engineer would have to manage approximately forty separate YAML files. Every time a new version of a service is released, they would need to edit the corresponding Deployment file (changing the container image tag), and then run kubectl apply on each file. If one service requires a configuration change (like a new database connection string), they must update the ConfigMap YAML file and possibly restart the pods. This manual process is prone to typographical errors, leading to outages. For example, a missing indentation in a YAML file could cause the Deployment to fail silently.

The engineer decides to convert each microservice into a Helm chart. They create a structure like this:

backend/ charts/ auth/ catalogue/ cart/ orders/ payments/ notifications/ Chart.yaml values.yaml

Each sub-chart has its own templates and default values. The engineer creates one global values.yaml file that sets common defaults (like the Kubernetes namespace, the container registry URL, and the logging level). For environment-specific customisation, they create separate values files:

development.yaml: replicaCount: 1 imageTag: "latest" resources: limits: memory: "256Mi" cpu: "250m"

staging.yaml: replicaCount: 2 imageTag: "staging-20231001" resources: limits: memory: "512Mi" cpu: "500m"

production.yaml: replicaCount: 5 imageTag: "v1.2.3" resources: limits: memory: "1Gi" cpu: "1" requests: memory: "512Mi" cpu: "500m"

To deploy to staging, the engineer runs:

helm upgrade --install ecommerce-staging ./backend -f staging.yaml --namespace staging

This single command installs all ten services with the correct configurations. If the staging deployment breaks, the engineer can roll back quickly:

helm rollback ecommerce-staging 1

This reverts to the previous working release. In production, the engineer uses a CI/CD pipeline that automatically runs helm upgrade with the production values file whenever a new Git tag is pushed. The pipeline also runs helm lint before deployment to check for chart errors.

Helm charts are also stored in a chart repository (like an HTTTP server or a cloud storage bucket). The company uses a private Helm repository so that all teams can discover and reuse charts. For example, the platform team publishes a standard PostgreSQL chart that all microservice teams can depend on. This reduces duplication and ensures consistency (e.g., all databases use the same backup configuration).

The engineer also uses Helm hooks — special annotations in templates that run jobs before or after a release. For example, a pre-upgrade hook runs a database migration Job before the new version of the app deploys. A post-delete hook runs a cleanup Job to remove orphaned resources.

In summary, the real-world benefit is speed and reliability. What used to take thirty minutes of manual file editing and kubectl commands now takes a single Helm command that takes seconds. The risk of human error drops dramatically. The team can focus on developing features rather than fighting with configuration files.