Helm Basics

Helm is the premier package manager for Kubernetes, transforming how you deploy, manage, and scale applications across cloud-native environments. Think of it as the de facto standard for packaging reusable Kubernetes applications—enabling teams to version control, share, and automate deployments with confidence. By treating applications as reusable units rather than ad-hoc configurations, Helm eliminates the chaos of manual Kubernetes YAML deployments and scales teams from small pilots to enterprise adoption. 🐳

Charts: The Building Blocks of Kubernetes Applications

At its core, a chart is a collection of pre-defined Kubernetes resources (like Deployments, Services, ConfigMaps) packaged into a single, version-controlled unit. Charts act as blueprints for your applications—allowing you to define how your services interact, scale, and integrate with Kubernetes infrastructure. This abstraction is critical for consistency, especially when collaborating across teams or environments.

Charts solve the fundamental problem of reproducibility: without Helm, every team might deploy applications using slightly different configurations, leading to inconsistent behavior across clusters. With Helm, you package your application’s entire lifecycle into a single, auditable unit that works identically across all environments.

Here’s a concrete example of a minimal chart for a simple web application. This chart defines a single Deployment and Service to run a containerized app:

<code class="language-bash"># Create a new chart directory structure
<p>mkdir -p my-web-app/charts</p>
<p>cd my-web-app/charts</p>

<h1>Initialize a new chart</h1>
<p>helm create my-web-app</code>

This generates a basic chart with the following structure:

<code>my-web-app/
<p>├── Chart.yaml</p>
<p>├── templates/</p>
<p>│   ├── deployment.yaml</p>
<p>│   ├── service.yaml</p>
<p>│   └── _helpers.tpl</p>
<p>└── values.yaml</code>

The Chart.yaml file declares the chart’s metadata (name, version, description), while templates/ contains the Kubernetes manifests that Helm will render during deployment. The values.yaml file is where you customize the chart’s behavior—like setting environment variables or resource limits.

Let’s create a minimal chart that deploys a simple Nginx web server:

<code class="language-bash"># Update deployment template to use Nginx
<p>cat > templates/deployment.yaml <<EOF</p>
<p>apiVersion: apps/v1</p>
<p>kind: Deployment</p>
<p>metadata:</p>
<p>  name: nginx-deployment</p>
<p>spec:</p>
<p>  replicas: 1</p>
<p>  selector:</p>
<p>    matchLabels:</p>
<p>      app: nginx</p>
<p>  template:</p>
<p>    metadata:</p>
<p>      labels:</p>
<p>        app: nginx</p>
<p>    spec:</p>
<p>      containers:</p>
<p>      - name: nginx</p>
<p>        image: nginx:alpine</p>
<p>        ports:</p>
<p>        - containerPort: 80</p>
<p>EOF</p>

<h1>Update service template</h1>
<p>cat > templates/service.yaml <<EOF</p>
<p>apiVersion: v1</p>
<p>kind: Service</p>
<p>metadata:</p>
<p>  name: nginx-service</p>
<p>spec:</p>
<p>  type: LoadBalancer</p>
<p>  ports:</p>
<p>  - port: 80</p>
<p>    targetPort: 80</p>
<p>  selector:</p>
<p>    app: nginx</p>
<p>EOF</code>

Now, to deploy this chart to a local Kubernetes cluster (using minikube as an example):

<code class="language-bash"># Start minikube if needed
<p>minikube start</p>

<h1>Deploy the chart with default values</h1>
<p>helm install my-web-app ./my-web-app</code>

This command creates a release (we’ll cover this next) using the chart’s templates and values. You can inspect the deployed resources with:

<code class="language-bash">kubectl get deployments,svc -l app=nginx</code>

Why charts matter:

They enforce version control for your application’s infrastructure
They enable reproducible deployments across development, staging, and production
They simplify team collaboration by isolating application logic from infrastructure

💡 Pro tip: Always use helm create to generate charts—this ensures you follow Helm’s best practices and avoids manual template errors.

Releases: Deploying Charts to Kubernetes

A release is the actual deployment of a chart to a Kubernetes cluster. When you run helm install or helm upgrade, Helm creates a release that tracks your application’s state, configuration, and lifecycle. Releases are the operational units that interact with Kubernetes—like a “versioned instance” of your application.

Each release has a unique identifier (the release name) and stores metadata about its deployment (like the chart version, deployment time, and status). This metadata is crucial for debugging and rollbacks—without releases, you’d have no way to track which configuration was active at which point in time.

Here’s how a release works in practice:

Create a release: Run helm install to deploy a chart to your cluster.
Track the release: Helm stores metadata about the release in the cluster’s kube-system namespace (via the Tiller service, now replaced by the helm CLI).
Update the release: Run helm upgrade to modify the chart’s configuration without losing the release’s history.
Roll back the release: Use helm rollback to revert to a previous state if something goes wrong.

Let’s deploy a release with a custom configuration:

<code class="language-bash"># Create a values file to override default settings
<p>cat > values.yaml <<EOF</p>
<p>replicas: 3</p>
<p>image:</p>
<p>  tag: latest</p>
<p>EOF</p>

<h1>Deploy the chart with custom values</h1>
<p>helm install my-web-app ./my-web-app -f values.yaml</code>

This command deploys the chart with 3 replicas of the Nginx service (vs. the default 1) and uses the latest image tag. The output shows the release name (my-web-app) and the chart version (1.0.0):

<code class="language-bash">Release "my-web-app" created: 1.0.0</code>

Now, let’s simulate a change—say, we want to scale down to 1 replica:

<code class="language-bash"># Update the release with new values
<p>helm upgrade my-web-app ./my-web-app -f values.yaml</code>

Helm tracks this change in the release’s history, allowing you to roll back later if needed:

<code class="language-bash"># Roll back to the previous state (before the upgrade)
<p>helm rollback my-web-app 1</code>

Key release concepts:

Term	Description
Release name	Unique identifier for the deployment (e.g., `my-web-app`)
Release version	Incremental version of the chart’s deployment (e.g., `1`, `2`, `3`)
Release history	Audit trail of all changes made to the release (used for rollbacks)

⚠️ Critical note: Releases replace the old chart deployment. If you run helm install without the --force flag, Helm will create a new release (not update the existing one).

Summary

Helm’s charts are reusable Kubernetes application templates that define your infrastructure as code—enabling consistent, versioned deployments across teams and environments. Releases are the operational deployments of these charts to clusters, tracking configuration changes and providing rollback capabilities. Together, they form the backbone of scalable, reliable cloud-native application management: charts act as the blueprint, while releases handle the execution. By mastering these concepts, you transform Kubernetes from a low-level orchestration tool into a strategic asset for building resilient, team-friendly applications. 🚀