Learn Helm Chart - History, Background & Why You Need Helm

#Introduction

After episode 0 made sure your environment is ready — basic Kubernetes skills, kubectl habits, a running local cluster, and a responsive helm version — in this episode we step back for a moment to answer a question that's rarely asked but hugely consequential: where does Helm come from, and why is it needed?

This question isn't historical trivia. Understanding Helm's background answers three practical questions that will haunt you throughout your career: (1) why teams that deploy production applications with plain kubectl apply always run out of time for repetitive work, (2) what Helm actually solves and what it doesn't — so you know when to use it and when not to, and (3) why the Tiller security issue was a turning point that changed Helm's design forever. Just as understanding the history of a programming language makes you more than someone who types commands, understanding Helm's history means you know why its design is the way it is.

In this episode we'll dissect the deployment challenges in Kubernetes, trace the evolution from Helm 1 to Helm 3, break down why Tiller was removed, understand the Chart, Release, and Repository concepts, and close with an honest comparison between Helm, Kustomize, bare kubectl, and Kubernetes Operators.

#Deployment Challenges in Kubernetes

Kubernetes solves container orchestration brilliantly — but at the same time creates a new paradox: a huge amount of declarative infrastructure. Before Kubernetes, deploying one application was simply "run this process." With Kubernetes, one application is a collection of interrelated manifests. The bigger the team and system, the heavier the manual burden.

#Managing Dozens of YAML Files

A production application is not one Deployment. It's a Deployment, Service, ConfigMap, Secret, Ingress, HorizontalPodAutoscaler, ServiceAccount, NetworkPolicy, and possibly several Jobs — every resource needs its own file (or many sections in one file). Now multiply that by the number of environments: dev, staging, production. You quickly end up with dozens to hundreds of YAML files that copy each other. It's not just the quantity — the problem is fragmentation: changing one value (say, the replica count) means editing files in three different environments, and the risk of forgetting one is always lurking.

#Configuration Differences Across Environments

Environments are never identical. Production needs more replicas, the same image tag but with bigger resource limits, different Ingress hostnames, and different database credentials in every environment. Without the right tool, you end up with three almost-identical copies of your manifests — and that "almost" is the source of classic bugs: a one-line difference no one notices. This is exactly the same problem as the "dependency hell" that gave birth to Docker, only moved up to the configuration level.

#Versioning, Rollback, and Lifecycle

Git versions code well, but deploying an application version is not just git checkout. Applications have a lifecycle: install, upgrade, and delete — and each has its own state. kubectl apply does store the last configuration, but rollback in the bare kubectl world means "restore the file to an old version and apply again" — manual, error-prone, and with no audit trail. Teams that have stayed up late debugging "who changed what this afternoon" know exactly how painful this is.

#Dependency Management and Team Consistency

Modern applications depend on other components: ingress controllers, cert-manager, Prometheus, databases. These components are also applications — each with its own deployment method. Managing them manually means every team copies lengthy installation docs and follows steps that can differ from person to person. Cross-team consistency is lost: one team installs nginx-ingress with parameter A, another with parameter B, and when something breaks, no two engineers can agree on "what is actually running in the cluster."

#The Evolution of Helm: From Deis to CNCF Graduated

Helm didn't appear overnight. It went through three major generations, each born from the lessons of the previous one.

#Helm 1 (Deis, 2015)

Helm began in 2015 as a project called Deployment Manager from the Deis team — a company focused on open-source PaaS. The initial idea was simple: package an application along with all its Kubernetes manifests into one reusable package. The project was later renamed Helm, adopting the classic package manager pattern: the package is called a chart, fetched from a registry called a repository, and the result of an installation is called a release. Helm 1 had major limitations — its architecture wasn't mature and adoption was still small — but it laid the conceptual foundation that survives to this day.

#Helm 2 and Tiller (2016)

Helm 2 was released in 2016 with a major architectural change: it introduced Tiller, a server daemon running inside the cluster that acted as an intermediary between the Helm client and the Kubernetes API server. The user runs helm install, the client sends the chart to Tiller, and Tiller interacts with the API server — while also storing release state in ConfigMaps.

This design adopted the classic client-server pattern but brought serious security problems. Because Tiller ran inside the cluster with full privileges, any user who could communicate with Tiller effectively gained full control over the entire cluster — with no granular RBAC mechanism between them. Tiller became a persistent security concern: it was a cluster credential running inside the cluster itself, and the "least privilege" security best practice was hard to apply. This problem wasn't hypothetical — many organizations rejected Helm 2 precisely because of Tiller.

#Helm 3: Tillerless (2019)

Helm 3 was released in November 2019 with its boldest decision: removing Tiller entirely. The Helm client now communicates directly with the Kubernetes API server, using the credentials and RBAC from the same kubeconfig as kubectl. Releases are stored in Secrets (not ConfigMaps) in the namespace where the application is installed — not in the kube-system namespace anymore. The consequences: security follows standard Kubernetes principles, experimentation is easier (a local client can use its own access), and there's no central daemon to maintain.

#CNCF Graduated (2020)

Helm was accepted as a CNCF (Cloud Native Computing Foundation) project in 2018 with incubating status, and reached graduated status in April 2020 — a mark of project maturity: stable governance, wide adoption, and battle-tested security. Today Helm is the de facto standard for packaging applications in the Kubernetes ecosystem, with thousands of public charts on Artifact Hub.

#What Is Helm?

Helm is a package manager for Kubernetes. There are three core concepts you should memorize from now on:

• Chart — a package containing a set of files that describe Kubernetes resources along with their metadata. A chart is a distributable, versionable, reusable artifact.
• Release — one instance of a chart installed into the cluster under a unique name. One chart can produce many releases; each release has its own state and history (revisions).
• Repository — where charts are stored and fetched, like an npm or PyPI registry. It can be a simple HTTP/HTTPS server or an OCI registry.

Think of Helm as npm for Kubernetes: instead of installing JavaScript libraries into node_modules, you install a complete application into the cluster with all its manifests, configuration, and dependencies — as one unit that can be upgraded, rolled back, and uninstalled.

One thing that sets Helm apart from most package managers: dependencies between charts. A chart can declare a dependency on another chart in its Chart.yaml — for example, an application chart that depends on a database chart. On install, Helm pulls all those dependencies together, and their versions are locked in a Chart.lock file so everyone builds an identical chart. That's what makes installing "WordPress + MariaDB" a single command rather than two applications stitched together manually.

#Why Helm Is Needed

Helm's benefits answer the challenges we dissected at the start, one by one:

• Simplified deployment — a single helm install command replaces dozens of file-copying kubectl apply steps.
• Reusable packages — charts can be reused across environments and projects; build once, use many times.
• Versioning — charts and releases have versions and revisions, so teams know exactly what's running.
• Easy rollback — helm rollback restores an application to a previous revision without manually restoring files.
• Centralized configuration — configuration values (replica count, image tag, hostname) are defined separately from the manifests and changed per environment through values files.
• Community ecosystem — thousands of ready-to-use charts on Artifact Hub: databases, ingress controllers, monitoring, message queues — installed in minutes.

To see these benefits concretely, imagine deploying WordPress along with its database on a cluster. Without Helm, you manage two separate applications: the WordPress manifests (Deployment, Service, Ingress, ConfigMap) and the MariaDB manifests (StatefulSet, Service, PVC, Secret), then align them manually — including versions, credentials, and deployment order. With Helm, both are one chart with a declared dependency:

kubectl apply -f wordpress/deployment.yaml -f wordpress/service.yaml
kubectl apply -f wordpress/configmap.yaml -f wordpress/ingress.yaml
kubectl apply -f mariadb/statefulset.yaml -f mariadb/service.yaml
kubectl apply -f mariadb/pvc.yaml -f mariadb/secret.yaml

helm install blog bitnami/wordpress
helm upgrade blog bitnami/wordpress --set wordpress.replicaCount=3
helm rollback blog 1

One chart, one command, one control point for the entire lifecycle — and the same version already used by millions of people in the real world. That's the power that has made major teams adopt Helm as their packaging standard: not just templating, but moving the mental burden from "managing files" to "managing applications."

#Helm vs Alternatives

Helm isn't the only answer — and understanding its position lets you use the right tool in the right place. Let's compare three approaches for the same job: deploying nginx with three replicas.

kubectl apply -f deployment.yaml -f service.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../base
patches:
  - path: patch-replicas.yaml

helm install nginx bitnami/nginx --set replicaCount=3

Helm vs kubectl apply — plain kubectl apply is perfect for a few static files that rarely change. As soon as you have many environments, parameterized configuration, and rollback needs, bare kubectl gives you no tools to manage them. Helm exists precisely for that moment.

Helm vs Kustomize — Kustomize (now built into kubectl) transforms manifests through overlays and patches: one base, one overlay per environment. It's declarative, has no templating language, and is easier to learn. The key difference: Kustomize doesn't package and doesn't manage lifecycle — it has no concept of release, revision, rollback, or dependency. Helm has all of those, plus a more powerful templating language (Go templates). Many teams use both at once: Kustomize for customization, Helm for packaging.

Helm vs Kubernetes Operators — An Operator is a controller that manages complex applications (for example, databases) continuously: scaling, backup, automatic upgrades. Helm is an install tool — it deploys and manages the basic lifecycle but doesn't supervise the running application. The answer isn't "one or the other," it's "both": many operators (for example the Prometheus Operator) are actually installed using Helm.

#Conclusion

In episode 1 we've understood the root causes of deployment pain in Kubernetes: dozens of fragmented YAML files, environment-specific configuration, manual versioning and rollback, inconsistent dependency management, and the loss of cross-team consistency. We also traced Helm's evolution — from Deis 2015 (Helm 1), Tiller 2016 (Helm 2) which was later removed because of RBAC and security issues, to the Tillerless Helm 3 in 2019 adopted by the CNCF as a graduated project in 2020. We closed with an honest comparison: kubectl for static manifests, Kustomize for customization without packaging, and Helm for packaging plus lifecycle.

Key takeaways:

• Helm was born from application state management, not just "reducing the number of YAML files."
• Tiller was removed because it became a security failure point — Helm 3 talks directly to the API server using standard Kubernetes RBAC.
• Chart (package), Release (deployed instance), Repository (registry) are Helm's three core concepts.
• Helm provides versioning, rollback, and dependencies that neither bare kubectl nor Kustomize has.
• Use Helm when you need packaging & lifecycle; don't use it for manifests that are fine to manage directly.

Now you know why Helm exists. In the next episode, episode 2, we'll dissect the architecture and core concepts of Helm 3: how client-only works without Tiller, how releases are stored in Secrets, the correct chart directory structure, and the three-way strategic merge patch mechanism behind upgrade and rollback. See you in episode 2!