Why Helm — the kubectl Way and the Helm Way

Docker & Kubernetes · Helm – The Package Manager for Kubernetes · Lesson 1 of 5

Helm bundles many manifests into one parameterised chart and installs it as a release with history, so upgrades and rollbacks are easy.

The kubectl way: an app is many YAML files (Deployment, Service, ConfigMap, Ingress, a database…) applied with kubectl apply -f. As environments and apps grow:

Changing the image, replica count or domain means editing many files by hand, which is error-prone.
There is no "version" of the whole manifest set: a rollback means digging up old YAML yourself.
Installing a second copy (say web-staging) needs renamed names/labels so it does not overwrite the first.
Anyone reusing it must understand all of the YAML.

The Helm way: Helm is a package manager for Kubernetes.

flowchart LR
  C["Chart nginx<br/>(templates + default values)"] --> H["helm install"]
  V["values: replicaCount=2"] --> H
  H --> R1["Release web (ns web)"]
  H --> R2["Release web-staging (ns staging)"]
  R1 --> K["Standard K8s objects<br/>Deployment, Service…"]

A chart packages every manifest and dependency; configuration is passed at install time as values (key-value).
Each install is a release with revisions; helm upgrade and helm rollback work on revisions.
One chart installs many times under different release names; charts are shared through repositories.

Note: Helm does not replace the Kubernetes API. It renders templates into ordinary manifests and sends them to the apiserver; kubectl get deploy still shows the objects Helm created.

Command	Meaning
`helm version`	Check the CLI version (v3.x)
`helm install web bitnami/nginx -n web --create-namespace`	Install the whole app with one command

Helm compared with other approaches

Approach	How configuration varies	Release history	Best for
Plain YAML + `kubectl apply`	Copy and edit files	None built in	Very small apps, learning
Kustomize (`kubectl apply -k`)	Base YAML plus overlays that patch it per environment	None built in	Teams who want plain YAML and few abstractions
Helm	Templates plus values	Revisions, rollback	Reusable packages, third-party software, many environments

They are not exclusive: many teams install third-party software (ingress controllers, monitoring stacks, databases) with Helm charts and manage their own apps with Kustomize or Helm.

A typical layout for your own app

charts/shop/
values.yaml            # shared defaults
values-dev.yaml        # small differences per environment
values-prod.yaml

helm upgrade --install shop charts/shop -n shop-prod --create-namespace \
  -f charts/shop/values-prod.yaml --set image.tag=3f9c2ab --atomic --wait

The CI pipeline only changes the image tag; everything else lives in reviewed values files.

Using third-party charts responsibly

Find charts on Artifact Hub and prefer those maintained by the software's own project.
Pin the chart version with --version and upgrade deliberately after reading the changelog.
Inspect defaults with helm show values and override only what you need in your own values file.
Check which images the chart pulls, and mirror them into your registry if production must not depend on public registries.

Where this module goes

The next lessons cover Helm's architecture, chart structure, templates, and dependencies. Together with the earlier Kubernetes modules, this gives you everything needed to package an application, deploy it repeatably to several environments, and roll it back safely.