How do Helm and Kustomize differ in how they produce the final manifests applied to a cluster?

### Two different machines for producing YAML Both tools end up sending Kubernetes manifests to an API server, but they build those manifests in opposite ways, and the interview question is almost always really about that difference plus its consequences. **Helm generates.** A chart is a directory containing `Chart.yaml` (name, `version`, `appVersion`, dependencies), `values.yaml` (the defaults), and `templates/` — files written in Go's text/template dialect. `helm install` and `helm upgrade` merge the chart defaults with whatever the caller supplied, expose the result to the templates as `.Values` alongside the built-in objects `.Release`, `.Chart`, `.Capabilities`, `.Files` and `.Template`, render every file under `templates/`, and apply what comes out. The consequence people miss is that the files under `templates/` are not Kubernetes YAML at all before rendering — they are text with actions in them: ```yaml {{- if .Values.persistence.enabled }} volumeClaimTemplates: - metadata: name: data spec: resources: requests: storage: {{ .Values.persistence.size }} {{- end }} ``` A Redis chart written this way can emit a StatefulSet with a PersistentVolumeClaim for one caller and a plain Deployment with an `emptyDir` for another, from the same source, because whole blocks and whole objects appear and disappear. That expressive power has a price: the customisation surface is fixed in advance by the chart author. If the author never templated `topologySpreadConstraints`, a consumer cannot set it — there is no value to set. The options are then to fork the chart, upstream a new value, or post-process the rendered output. **Kustomize patches.** Its inputs are complete, valid manifests, and a variant is produced by applying patches to them. Nothing in the tree needs a rendering step before it can be read, linted or validated as a manifest, and no field is out of reach because nobody anticipated it — you can patch something the base's author never thought about. The symmetric cost is that "emit this object only in production" or "repeat this block once per queue" is not what patching expresses naturally. ### The second difference: state The rendering model is only half the answer, and candidates who stop there sound shallow. Helm keeps a record. Every `install`, `upgrade` and `rollback` writes a **release revision** — the rendered manifest, the values that produced it, the chart metadata and a status — into a Secret named `sh.helm.release.v1.<name>.v<rev>` in the release's namespace. That record is the basis of everything Helm can do that a plain apply cannot: - `helm list` enumerates what is installed in a namespace, without you knowing what to look for. - `helm get manifest <release>` prints exactly what that release applied — the render, after the fact. - an upgrade diffs the new render against the **stored previous manifest**, so a resource you deleted from the chart is deleted from the cluster. - `helm rollback` can re-apply an earlier revision because that revision's manifest is still on disk in the cluster. - `helm uninstall` knows precisely which objects belong to the release. `kubectl apply -k` has none of that: the built manifests are applied and forgotten. The cluster plus your source tree are the only state, so "what is deployed here?" and "put it back" are questions you answer with Git and a rebuild rather than with a command. ### The third difference: packaging Helm charts are also a **distribution format**. `helm package` produces a versioned `.tgz` that can be served from a classic chart repository with an `index.yaml`, or pushed to and installed from an OCI registry with an `oci://` reference. A chart therefore has an explicit public interface — `values.yaml`, optionally constrained by `values.schema.json` — that strangers depend on. That is why nearly everything you install from a vendor arrives as a chart, and why most organisations end up running Helm at least as a consumer regardless of what they choose for their own services. ### How to say it in an interview A crisp answer covers three axes: **generation versus patching** (templating power and a fixed knob surface, against unconstrained patching of real YAML); **stateful release versus stateless apply** (revision history, rollback, uninstall, deletion of removed resources, against nothing but the cluster); and **packaging** (a versioned, parameterised artifact for consumers you cannot redeploy yourself). Then say the honest thing: they are not mutually exclusive. Helm can hand its rendered output to a post-renderer, and plenty of teams consume third-party charts while writing their own services as plain manifests with overlays. One myth worth killing on the spot: Helm has no server-side component. Since Helm 3 there is no Tiller — the CLI renders locally and talks to the API server with your own credentials, exactly as `kubectl` does.