What is a Helm chart and why would you use one?
Helm is the package manager for Kubernetes. A **Helm chart** is a directory of files that together define a deployable unit: Go-templated Kubernetes manifests, a `values.yaml` file of defaults, a `Chart.yaml` with metadata, and optionally subcharts and lifecycle hooks.
The core value proposition is **parameterization with versioning**. Without Helm, teams maintain separate sets of manifests per environment (dev, staging, prod), leading to drift. With Helm, you write a chart once, define variable points with `{{ .Values.image.tag }}` or `{{ .Values.replicas }}`, and install the same chart with different `values.yaml` overrides per environment. The chart is versioned and can be published to a chart repository (Artifact Hub, OCI registries, Harbor), enabling reproducible installs and rollbacks with `helm rollback`.
A **release** is a specific installation of a chart into a namespace. Helm stores release state as Secrets in the target namespace (Helm 3), so the release history is durable and `helm history` shows every revision with its status.
Helm also manages the deployment lifecycle through **hooks** — Jobs or other resources that run at defined points: `pre-install`, `post-install`, `pre-upgrade`, `pre-rollback`. These are useful for running database migrations before an upgrade or sending a Slack notification on rollback.
For complex applications, charts can declare **dependencies** (subcharts) in `Chart.yaml`. For example, your app chart might depend on a `postgresql` subchart from Bitnami, pinned to a specific version, so a `helm dependency update` pulls it in before packaging.
The alternative to Helm is managing raw manifests with `kubectl apply -k` (Kustomize), which uses overlay patching rather than templating. Kustomize avoids template logic but requires more boilerplate for multi-environment variance. Many teams use both: Helm for third-party charts (databases, ingress controllers) and Kustomize for their own application manifests.
Helm 3 removed the server-side Tiller component from Helm 2, addressing a major security concern — all operations now happen client-side using the user's kubeconfig credentials.
Explains that Helm is a package manager, describes the values/template mechanism, and mentions versioned releases. Does not go into hooks, subcharts, or the Helm 2 vs. 3 security change.
Covers templating, values overrides, release management and rollback, hooks for lifecycle operations, subchart dependencies, release state storage, and can compare Helm vs. Kustomize trade-offs.
Reading the answer is step one. Explaining it unprompted — under interview pressure — is what actually matters. Get AI-graded feedback on your answer with follow-up probes on your weak points.
Get Graded — Free Assessment