# The Problem Helm Solves — Helm

Source: https://www.skillbyai.com/en/helm/h-why

> Explain why raw Kubernetes YAML becomes hard to manage and what a package manager adds.

## From a pile of YAML to a package

A real application on Kubernetes is not one file. A typical web service needs a Deployment, a Service, an Ingress, a ConfigMap, a ServiceAccount, maybe a HorizontalPodAutoscaler and a PodDisruptionBudget. Now repeat that for **dev, staging and production**, where only a few values differ: replica count, image tag, hostnames, resource limits. Copy-pasting YAML per environment drifts quickly. And `kubectl apply` has no idea which objects belong together, so removing an app or going back to last week's version is manual. **Helm** is the package manager for Kubernetes. It bundles templated manifests into a **chart**, fills them in with **values** for each environment, installs them as a named **release**, records every **revision**, and can **upgrade**, **roll back** or **uninstall** the whole set as one unit. Helm is a graduated project of the Cloud Native Computing Foundation.

## Chart plus values becomes a release

The same chart, combined with different values, produces a release per environment.

![A package box on the left and two small settings cards merging into it, producing two separate stacks of deployed blocks on the right.](assets/figures/helm/section-1-map.svg) — Figure 1.1 — One chart, different values, separate releases.

## What Helm replaces

Without Helm you manage each file and each environment by hand; with Helm one command installs or upgrades the whole set.

```bash
# without Helm: apply many files, per environment, and track them yourself
kubectl apply -f deployment.yaml -f service.yaml -f ingress.yaml -f configmap.yaml

# with Helm: one release, one command, with history
helm install shop-api ./charts/shop-api -f values-prod.yaml --namespace shop
helm history shop-api --namespace shop
helm rollback shop-api 3 --namespace shop
```

## apt or npm for your cluster

Just as `apt install nginx` or `npm install express` fetches a package and its dependencies, `helm install` fetches a chart and installs everything it needs into the cluster, and remembers what it installed so it can upgrade or remove it later.

**Quiz:** Which capability does Helm add that plain `kubectl apply` of files lacks?

- [x] Tracking a set of objects as one versioned release that can be rolled back
- [ ] Running containers
- [ ] Scheduling pods onto nodes
- [ ] Building container images

*Answer:* Tracking a set of objects as one versioned release that can be rolled back. Helm groups manifests into a release with revision history; scheduling and running containers is still Kubernetes' job.