Deploy with Helm Charts: Installation, Configuration and Best Practices

Helm is the package manager for Kubernetes. It simplifies deploying complex applications by bundling YAML manifests, configurations, and dependencies into a reusable format called a chart. According to Orca Security 2025, 70% of organizations use Helm in their Kubernetes environments.

TL;DR: This guide walks you through from installing Helm to creating your own charts. You'll learn how to install, configure, upgrade, and troubleshoot your Helm deployments in production. Each step includes the commands and expected outputs.

To master these skills and prepare for the CKAD, discover the LFD459 Kubernetes for Application Developers training.

What Is Helm and Why Use It?

Helm is a templating and packaging tool for Kubernetes. It allows you to version, share, and deploy applications in a reproducible manner.

Helm adds an abstraction layer on top of Kubernetes, significantly simplifying the deployment of complex applications.

Key Definitions

Term	Definition
Chart	A chart is a Helm package containing all Kubernetes manifests needed to deploy an application
Release	A release is an instance of a chart deployed in your cluster with a specific configuration
Repository	A repository is an HTTP server hosting downloadable Helm charts
Values	Values are configuration parameters you pass to the chart to customize the deployment
Template	A template is a YAML file with Go variables that generates the final Kubernetes manifests

Remember: Helm saves you from copy-pasting dozens of YAML files. You manage a single source of truth with configurable parameters.

Prerequisites Before Starting

Before installing Helm, verify that your environment meets these requirements:

Working Kubernetes Cluster

You need an active Kubernetes cluster. Verify with:

kubectl cluster-info
# Expected output:
# Kubernetes control plane is running at https://127.0.0.1:6443
# CoreDNS is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

kubectl Configured

Your kubeconfig file must point to the correct cluster:

kubectl config current-context
# Expected output: the name of your active context (e.g., minikube, docker-desktop, production-cluster)

Compatible Versions

In 2026, use Helm 3.14+ with Kubernetes 1.28+. Helm 3 removed Tiller, making installation more secure. Check the Kubernetes deployment strategies to choose your approach.

Step 1: Install Helm on Your Machine

You have several options for installing Helm. Choose the one suited to your operating system.

Installation on macOS

brew install helm

Installation on Linux

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Installation on Windows

choco install kubernetes-helm

Verify Installation

Confirm that Helm works correctly:

helm version
# Expected output:
# version.BuildInfo{Version:"v3.14.2", GitCommit:"c309b6f0ff63856811846ce18f3bdc93d2b4d54b", GitTreeState:"clean", GoVersion:"go1.21.7"}

Remember: Helm 3 requires no cluster-side component. Installation is limited to your workstation.

Step 2: Add and Manage Repositories

Helm repositories work like apt or npm. You add them to access available charts.

Add the Official Repository

helm repo add bitnami https://charts.bitnami.com/bitnami
# Expected output:
# "bitnami" has been added to your repositories

Update Repositories

Run this command regularly to fetch the latest versions:

helm repo update
# Expected output:
# Hang tight while we grab the latest from your chart repositories...
# ...Successfully got an update from the "bitnami" chart repository
# Update Complete. ⎈Happy Helming!⎈

List Your Repositories

helm repo list
# Expected output:
# NAME    URL
# bitnami https://charts.bitnami.com/bitnami

To manage your deployments effectively, compare Helm vs Kustomize based on your needs.

Step 3: Search and Inspect Charts

Before installing a chart, examine its content and documentation. This step prevents surprises in production.

Search for a Chart

helm search repo nginx
# Expected output:
# NAME                    CHART VERSION   APP VERSION     DESCRIPTION
# bitnami/nginx           15.14.0         1.25.4          NGINX Open Source is a web server...
# bitnami/nginx-ingress   9.10.1          1.9.6           NGINX Ingress Controller...

Display Chart Information

helm show chart bitnami/nginx
# Expected output:
# apiVersion: v2
# appVersion: 1.25.4
# description: NGINX Open Source is a web server...
# name: nginx
# version: 15.14.0

View Configurable Values

This command is essential. It lists all parameters you can customize:

helm show values bitnami/nginx > nginx-values.yaml

Open the generated file to discover available options. According to the CNCF Annual Survey 2025, 82% of container users run Kubernetes in production. Understanding configuration options is therefore critical.

Remember: Always read the default values before installing. You'll avoid insecure or oversized configurations.

Step 4: Install Your First Chart

Installation creates a release in your cluster. Each release has a unique name that you choose.

Basic Installation

helm install my-nginx bitnami/nginx --namespace web --create-namespace
# Expected output:
# NAME: my-nginx
# LAST DEPLOYED: Fri Feb 28 10:30:00 2026
# NAMESPACE: web
# STATUS: deployed
# REVISION: 1

Verify the Deployment

kubectl get pods -n web
# Expected output:
# NAME                        READY   STATUS    RESTARTS   AGE
# my-nginx-5d9c6d4c8b-7xk2m   1/1     Running   0          45s

List Installed Releases

helm list -n web
# Expected output:
# NAME      NAMESPACE   REVISION    UPDATED                                 STATUS      CHART           APP VERSION
# my-nginx  web         1           2026-02-28 10:30:00.123456789 +0100 CET  deployed    nginx-15.14.0   1.25.4

Integrate your Helm deployments into a CI/CD pipeline for Kubernetes to automate your releases.

Step 5: Customize with Values

You customize a chart by overriding its values. Two methods exist: inline or via file.

Method 1: Inline Parameters

helm install my-nginx bitnami/nginx \
--set replicaCount=3 \
--set service.type=ClusterIP \
--namespace web

Method 2: Values File (Recommended)

Create a custom-values.yaml file:

# custom-values.yaml
replicaCount: 3

service:
type: ClusterIP
port: 80

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

autoscaling:
enabled: true
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 80

Install with this file:

helm install my-nginx bitnami/nginx -f custom-values.yaml --namespace web

Combine Multiple Files

You can layer configurations. Later files override earlier ones:

helm install my-nginx bitnami/nginx \
-f base-values.yaml \
-f production-values.yaml \
--namespace web

Remember: Version your values files in Git. This is your source of truth for reproducing deployments.

Check the guide on Kubernetes monitoring and troubleshooting to monitor your deployed applications.

Step 6: Upgrade and Rollback Your Releases

Upgrades apply new configurations or versions. Helm keeps history for rollbacks.

Upgrade a Release

Modify your custom-values.yaml file, then:

helm upgrade my-nginx bitnami/nginx -f custom-values.yaml --namespace web
# Expected output:
# Release "my-nginx" has been upgraded. Happy Helming!
# NAME: my-nginx
# LAST DEPLOYED: Fri Feb 28 14:45:00 2026
# NAMESPACE: web
# STATUS: deployed
# REVISION: 2

View History

helm history my-nginx -n web
# Expected output:
# REVISION    UPDATED                     STATUS      CHART           APP VERSION     DESCRIPTION
# 1           Fri Feb 28 10:30:00 2026    superseded  nginx-15.14.0   1.25.4          Install complete
# 2           Fri Feb 28 14:45:00 2026    deployed    nginx-15.14.0   1.25.4          Upgrade complete

Rollback to a Previous Version

helm rollback my-nginx 1 -n web
# Expected output:
# Rollback was a success! Happy Helming!

Verify that the rollback worked:

helm history my-nginx -n web
# Revision 3 appears with description "Rollback to 1"

For zero-downtime deployments, study Kubernetes Rolling Update or Blue-Green Deployment.

Step 7: Create Your Own Chart

You can package your applications into reusable charts. This skill is tested on the CKAD.

Generate the Structure

helm create my-app
# Expected output:
# Creating my-app

Generated Chart Structure

my-app/
├── Chart.yaml          # Chart metadata
├── values.yaml         # Default values
├── templates/          # Kubernetes templates
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── hpa.yaml
│   └── _helpers.tpl    # Reusable functions
└── charts/             # Dependencies

Test Locally Before Installation

Validate your chart's syntax:

helm lint my-app
# Expected output:
# ==> Linting my-app
# [INFO] Chart.yaml: icon is recommended
# 1 chart(s) linted, 0 chart(s) failed

Generate manifests without installing:

helm template my-app ./my-app -f custom-values.yaml
# Displays generated YAMLs for verification

Dry-Run Installation

helm install my-app ./my-app --dry-run --debug -n production
# Simulates installation and displays potential errors

Remember: Systematically test with lint, template, and dry-run. You'll detect errors before they reach production.

The LFD459 training covers Helm chart creation in detail for the CKAD.

Troubleshooting Common Errors

Error: "INSTALLATION FAILED: cannot re-use a name"

Cause: A release with this name already exists.

helm list -n web
# Check if the release exists
helm uninstall my-nginx -n web
# Then reinstall

Error: "Error: UPGRADE FAILED: another operation is in progress"

Cause: A previous operation is stuck.

helm history my-nginx -n web
# Identify the release in "pending-*" state
kubectl get secrets -n web -l owner=helm
# Delete the corresponding secret if necessary

Pods in CrashLoopBackOff After Installation

Diagnosis:

kubectl describe pod <pod-name> -n web
kubectl logs <pod-name> -n web --previous

Common solutions:

Check resources (insufficient CPU/memory)
Verify environment variables
Validate referenced secrets and ConfigMaps

For deeper diagnosis, consult the Kubernetes monitoring and troubleshooting guide.

Chart Not Found in Repository

helm repo update
helm search repo <chart-name> --versions
# Verify the repository contains the chart

Production Best Practices

Version Everything

Store your values in Git with your application code. Use branches for environments (dev, staging, production).

Use Dedicated Namespaces

helm install my-app ./my-app --namespace production --create-namespace

Enable Long History

By default, Helm keeps 10 revisions. Increase if needed:

helm upgrade my-app ./my-app --history-max 25

Sign Your Charts

For production, enable signature verification:

helm verify my-app-1.0.0.tgz
helm install my-app my-app-1.0.0.tgz --verify

According to Spectro Cloud State of Kubernetes 2025, 80% of organizations manage more than 20 clusters in production. Standardization via Helm becomes essential.

Next Steps: Train with SFEIR

You now master Helm fundamentals. To go further and obtain your certification, explore these trainings:

LFD459 Kubernetes for Developers: 3 days to prepare for the CKAD, including Helm and application deployments
LFS458 Kubernetes Administration: 4 days for the CKA, covering production cluster administration
Kubernetes Fundamentals: 1 day to discover Kubernetes before going deeper

Check the training calendar to book your next session. As TealHQ states: "Don't let your knowledge remain theoretical - set up a real Kubernetes environment to solidify your skills."

Contact our advisors to define your Kubernetes certification path.

Key Takeaways