Helm 3: Streamline Kubernetes Deployments with Charts

Modern Kubernetes deployments often involve dozens of YAML manifests that must be applied in sequence—a process that’s error-prone and time-consuming. Helm 3, the de facto package manager for Kubernetes, changes this by bundling configurations into reusable charts that can be installed, upgraded, and rolled back with a single command. Unlike its predecessor, Helm 3 eliminates the need for a server-side component called Tiller, making deployments lighter, faster, and more secure.

What Helm 3 Brings to Kubernetes

Helm 3 acts as a package manager for Kubernetes, much like apt manages software on Linux or npm handles JavaScript libraries. Instead of manually applying individual YAML files, engineers create charts—predefined templates that encapsulate all required Kubernetes resources for an application. This approach reduces configuration overhead and standardizes deployments across environments.

Key capabilities include:

• Application packaging: Bundle Kubernetes manifests into portable charts for easy sharing and reuse.
• Version control: Track changes between chart releases and roll back to previous states if issues arise.
• Templating: Use Go templating to dynamically generate Kubernetes manifests, reducing redundancy.
• Dependency management: Automatically resolve and install nested charts (subcharts) for complex stacks.

Organizations leveraging Helm 3 report up to 60% faster deployments and fewer configuration errors, according to a 2023 survey by the Cloud Native Computing Foundation.

Breaking Down Helm’s Architecture

At its core, Helm 3 consists of three primary components: charts, releases, and repositories. Each chart is a package containing Kubernetes manifests, metadata, and default configurations, while repositories serve as centralized storage for sharing charts—akin to Docker Hub for container images.

Core Components

• Chart: A directory of files that describe a set of Kubernetes resources. Charts are versioned and can include subcharts for complex architectures.
• Release: An instance of a chart deployed into a Kubernetes cluster. Helm tracks each release’s lifecycle, enabling upgrades and rollbacks.
• Repository: A collection of charts hosted on a server, accessible via Helm commands. Public repositories like Bitnami or Prometheus Community provide prebuilt charts for common tools.

A typical chart structure looks like this:

mychart/
├── Chart.yaml          # Metadata (name, version, dependencies)
├── values.yaml         # Default configuration values
├── charts/             # Subcharts (dependencies)
└── templates/          # Go template files for Kubernetes manifests
    ├── deployment.yaml
    ├── service.yaml
    └── _helpers.tpl     # Reusable template functions

Critical files include:

• Chart.yaml: Defines the chart’s name, version, and dependencies.
• values.yaml: Contains default configurations for template variables.
• templates/: Houses Go templates that generate Kubernetes YAML manifests dynamically.

Essential Helm Commands for Every Developer

Mastering Helm 3 starts with understanding its command-line interface (CLI), which simplifies interactions with charts and clusters. Below are the most commonly used commands, organized by workflow stage.

Repository Management

Before installing charts, add repositories to access their contents:

# Add a chart repository
helm repo add bitnami 

# Update local cache of repository charts
helm repo update

# List all added repositories
helm repo list

# Remove a repository
helm repo remove bitnami

Chart Installation and Upgrades

Deploy charts as releases and manage their lifecycle:

# Install a chart and create a release named 'my-release'
helm install my-release bitnami/nginx

# Upgrade an existing release with new configurations
helm upgrade my-release bitnami/nginx --set replicaCount=3

# Roll back a release to a previous version
helm rollback my-release 1

# List all active releases in a namespace
helm list -n monitoring

# Inspect a release’s current configuration
helm get values my-release -n monitoring

Debugging and Cleanup

Helm provides tools to diagnose issues and clean up resources:

# Fetch the generated Kubernetes manifests for a release
helm get manifest my-release -n monitoring

# View a release’s revision history
helm history my-release -n monitoring

# Uninstall a release and purge associated resources
helm uninstall my-release -n monitoring

Hands-On: Deploying a Monitoring Stack with Helm

Let’s walk through deploying a production-grade monitoring stack using Helm charts from the Prometheus Community repository. This example demonstrates how Helm simplifies complex setups involving multiple components like Prometheus, Grafana, and Alertmanager.

Step 1: Prepare Your Cluster and Tools

Ensure you have the prerequisites installed:

• A running Kubernetes cluster (e.g., Minikube, EKS, GKE).
• kubectl configured to interact with the cluster.
• Helm 3 installed on your local machine.

Step 2: Add and Configure Repositories

# Add the Prometheus Community and Grafana repositories
helm repo add prometheus-community 
helm repo add grafana 

# Update the local chart cache
helm repo update

Step 3: Explore and Select a Chart

Browse available charts and their versions:

# Search for the kube-prometheus-stack chart
helm search repo kube-prometheus-stack

# List the latest available versions
helm search repo kube-prometheus-stack --versions | head -5

# Inspect the chart’s metadata without installing it
helm show chart prometheus-community/kube-prometheus-stack

# View default configuration values
helm show values prometheus-community/kube-prometheus-stack > default-values.yaml

Step 4: Deploy the Monitoring Stack

Create a dedicated namespace and install the chart:

# Create a namespace for monitoring resources
kubectl create namespace monitoring

# Install the chart with a specific version
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --version 65.1.1

Step 5: Access Monitoring Dashboards

Use port forwarding to access Grafana, Prometheus, and Alertmanager UIs:

# Access Grafana dashboard (default credentials: admin/prom-operator)
kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80

# Access Prometheus UI
kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-prometheus 9090:9090

# Access Alertmanager UI
kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-alertmanager 9093:9093

Step 6: Scale and Upgrade the Release

Adjust configurations or upgrade the stack as needed:

# Scale Grafana replicas to 2
helm upgrade monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set grafana.replicas=2

# View the release history
helm history monitoring -n monitoring

# Roll back to the previous revision if issues occur
helm rollback monitoring 1 -n monitoring

Step 7: Clean Up Resources

Remove the monitoring stack and namespace when no longer needed:

# Uninstall the release
helm uninstall monitoring -n monitoring

# Delete the namespace
kubectl delete namespace monitoring

Why Helm 3 Is a Game-Changer for DevOps Teams

Helm 3’s architecture eliminates the need for Tiller, reducing security risks and simplifying cluster interactions. Its templating system and dependency management empower teams to standardize deployments, reducing configuration drift and accelerating release cycles. As Kubernetes adoption grows, Helm 3’s role as a unifying package manager becomes indispensable for scalable, reproducible infrastructure.

The rise of GitOps workflows—where Helm charts are version-controlled and deployed via CI/CD pipelines—further solidifies Helm’s position as a cornerstone of modern cloud-native development. Teams that adopt Helm 3 today will be better equipped to handle the complexity of tomorrow’s distributed systems.