Helm Charts

Helm Charts

Published on
Authors

In the world of Kubernetes, deploying and managing complex applications can quickly become challenging. Helm charts, Kubernetes’ de facto package manager, step in to simplify the orchestration of applications. This guide goes beyond the basics to cover why Helm is essential, how it simplifies deployment, advanced use cases, and a deep dive into essential Helm commands with practical usage examples and considerations.

🚀 Why Helm Charts Are a Game-Changer

Kubernetes offers robust capabilities for orchestrating containerized applications—but managing multiple YAML files for deployments, services, config maps, secrets, ingress, and more can be tedious and error-prone.

Helm charts solve this complexity by allowing developers and DevOps teams to:

  • Package Kubernetes manifests into reusable, version-controlled application units.
  • Deploy applications consistently across multiple environments.
  • Upgrade and rollback applications easily.
  • Use templates to avoid duplication and hardcoded values.
  • Manage dependencies cleanly between microservices.

Think of Helm charts as the apt or yum of Kubernetes. They bring package management to your cluster—complete with versioning, sharing, and reproducibility.

🛠️ Real-World Use Cases for Helm Charts

Here are some practical scenarios where Helm charts shine:

1. Microservices Deployments

You can package each microservice into its own Helm chart and use a parent chart to manage the overall application. This modular design simplifies lifecycle management.

2. Databases and Stateful Workloads

Stateful applications like MySQL, MongoDB, or PostgreSQL need persistent storage and careful pod management. Official Helm charts incorporate these best practices, sparing you from reinventing the wheel.

3. CI/CD Pipelines

Helm charts are CI/CD-friendly and integrate with GitOps tools like ArgoCD and Flux, or CI tools like Jenkins, GitLab CI, or GitHub Actions. Automate versioned deployments through Helm.

4. Dev Environments

Need to spin up a local environment with backend, frontend, and database services? Helm charts let you do this consistently and quickly.

5. Monitoring and Observability

Deploy full stacks like Prometheus, Grafana, or ELK using community-maintained Helm charts to save hours of setup and configuration.

🔧 Deep Dive: Essential Helm Commands (with Practical Usage Tips)

🏁 Basic Setup

helm version

When to use: To verify that Helm is installed and check the client/server version.
When not to use: Not needed during scripting or CI pipelines unless troubleshooting.

helm repo add bitnami https://charts.bitnami.com/bitnami

Use it when: Adding a new chart repository (e.g., Bitnami, HashiCorp, etc.).
Avoid if: You’ve already added the repo or use private/OCI registries.

helm repo update

When to use: To fetch the latest charts from all configured repositories.
When not to use: If you’ve just updated it recently; avoids unnecessary network calls.

📦 Installing Helm Charts

helm install my-app bitnami/nginx

Use this for: Deploying a new Helm release to your cluster.
Avoid if: The release already exists; instead, use helm upgrade.

helm install -f myvalues.yaml myredis ./redis

Use it when: You need to customize chart values using a file.
Avoid if: You’re just doing a simple override (--set) or testing defaults.

helm install --set name=prod myredis ./redis

When to use: For quick overrides in automation scripts or testing.
Not ideal if: You’re overriding many values—use a values.yaml file instead.

helm install --set-json foo='{"key1":"value1"}' myredis ./redis

When to use: To inject complex or nested structures directly.
Avoid if: It makes your command unreadable; prefer a JSON/YAML file.

🔁 Upgrading and Rolling Back Releases

helm upgrade my-app bitnami/nginx --set key=value

Use it when: Upgrading to a new version or modifying configuration.
Avoid if: There’s a risk of failure without testing—use helm diff first.

helm rollback my-app 1

When to use: Something broke after an upgrade, and you want to roll back.
Avoid if: Rollback can worsen the issue—always investigate first.

🗑️ Uninstalling

helm uninstall my-app

Use when: Cleaning up test deployments or decommissioning applications.
Don’t use: In production without a backup plan—data may be lost.

📜 Inspecting Helm Releases

helm status my-app
helm history my-app
helm get values my-app

When to use: For auditing, debugging, or reviewing current state/configuration.
Avoid if: You’re using CI systems that already track this in logs.

🔍 Chart Exploration & Verification

helm show all bitnami/redis
helm show values bitnami/nginx

Use this for: Understanding what a chart offers and how to configure it.
Avoid if: You already maintain internal documentation for your charts.

helm template myapp ./my-chart

When to use: For dry-run rendering to inspect the final manifests.
Not needed if: You directly trust the values and configuration.

helm lint ./my-chart

Use when: Validating chart syntax before committing or deploying.
Avoid if: You’re not modifying charts yourself.

🔁 Dependency Management

helm dependency update ./my-chart
helm dependency list ./my-chart

Use when: Your chart depends on other charts (e.g., subcharts).
Avoid if: You’re not using requirements.yaml or Chart.yaml dependencies.

📦 Packaging and Sharing

helm package ./my-chart

Use when: Distributing or storing Helm charts.
Avoid if: You deploy locally and don’t need .tgz archives.

helm push my-chart.tgz oci://myregistry.azurecr.io

Use it for: Pushing to OCI-compliant registries like ACR, ECR, or Harbor.
Avoid if: You rely on Helm chart repositories (helm repo add method).

🧪 Testing Helm Releases

helm test my-app

Use when: The chart includes test hooks (e.g., smoke tests, readiness probes).
Avoid if: The chart has no test hooks defined.

🧭 Environment & Plugin Support

helm env
helm plugin list
helm plugin install <url>

Use for: Debugging or extending Helm’s capabilities.
Avoid if: You’re in restricted environments (e.g., locked-down CI runners).

🔐 OCI and Registry Authentication

helm registry login myregistry.azurecr.io
helm registry logout myregistry.azurecr.io
helm registry list

When to use: Working with private registries like ACR, ECR, or GitHub Container Registry.
Not needed if: You use public repositories or traditional chart repos.

🧪 Diff, Create & Completion Commands

helm create my-chart

Use for: Bootstrapping new Helm charts.
Avoid if: You’re using a starter template generator (like Plop or Yeoman).

helm diff upgrade my-app my-chart

When to use: Comparing manifest changes between chart versions (requires plugin).
Avoid if: You don’t have helm-diff installed.

helm completion bash/zsh/fish

Use when: You want autocompletion in your terminal for Helm commands.
Avoid if: You’re using a GUI or don’t need CLI speed.

🧠 Final Thoughts

Helm brings structure, scalability, and sanity to Kubernetes deployments. Whether you’re operating a single service or managing an enterprise-scale microservices architecture, Helm charts help you:

  • Avoid YAML sprawl
  • Automate safely
  • Upgrade with confidence
  • Share configurations across teams

The command set might seem overwhelming at first, but once you categorize them (install, inspect, upgrade, rollback, template, etc.), Helm becomes second nature.

Pro Tip: Maintain your own internal chart repository and version every release. Treat your charts as immutable infrastructure assets.

📘 Resources

Cheers,

Sim