What is Helm, and what problem does it solve compared to raw kubectl apply?

The problem: deploying the same application across many environments

A real application's Kubernetes manifests (Deployment, Service, ConfigMap, Ingress, maybe an HPA) need slightly different values across dev, staging, and production — different replica counts, different resource limits, different hostnames. With plain YAML and kubectl apply, you either maintain entirely separate copies of every manifest per environment (duplicated, drifts out of sync over time) or bolt on your own ad-hoc templating (shell scripts with sed, or hand-rolled variable substitution) with no standard tooling around it.

What Helm adds: charts, values, and releases

mychart/
├── Chart.yaml           # chart metadata: name, version, description
├── values.yaml           # default configuration values
└── templates/
    ├── deployment.yaml    # Kubernetes manifest, with {{ .Values.x }} placeholders
    ├── service.yaml
    └── configmap.yaml

# templates/deployment.yaml (simplified)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-web
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: web
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

helm install my-app ./mychart --values production-values.yaml

A chart is the packaged, templated bundle of manifests; values parameterize it per environment/deployment without duplicating the underlying templates; a release is Helm's tracked record of one specific installation of a chart (with a specific set of values) into a cluster, versioned so you can see history and roll back.

What this buys you over raw kubectl apply

• No manifest duplication across environments — one set of templates, different values files per environment.
• Built-in release history and rollback — helm rollback my-app 3 reverts to a previous release revision, without needing to have manually kept old YAML files around yourself.
• Dependency management — a chart can declare dependencies on other charts (e.g., an application chart depending on a postgresql subchart), letting complex, multi-component applications be installed and versioned together as one unit.
• A public ecosystem of pre-built charts — Artifact Hub and vendor-published charts let you install well-known software (Prometheus, cert-manager, ingress-nginx) with a single helm install, rather than hand-writing manifests for someone else's application from scratch.

What Helm doesn't change about the underlying model

Helm ultimately still produces and applies ordinary Kubernetes manifests — it's a layer of templating, packaging, and release tracking on top of the same declarative object model everything else in Kubernetes uses (see the fundamentals topic), not a replacement for understanding what a Deployment or Service actually is. Debugging a Helm-deployed application still means understanding the actual rendered Kubernetes objects underneath (helm template renders the final YAML without installing anything, useful for exactly this kind of inspection).

When plain kubectl apply is still perfectly fine

For a small number of simple, rarely-changing manifests, or a single-environment deployment with no real parameterization need, introducing Helm's additional layer of templating and tooling can be more complexity than the problem warrants — Helm earns its keep specifically once you have real per-environment variation, a genuine need for tracked release history/rollback, or want to consume other people's pre-packaged charts.