Drift & Change Preview

## What Helm actually stores Every successful `helm install`, `helm upgrade` or `helm rollback` finishes by writing a **release record**: by default a Secret in the release namespace named `sh.helm.release.v1.<release>.v<revision>`, containing a compressed blob with the chart metadata, the merged values, the rendered manifest, a status such as `deployed` or `failed`, and timestamps. `HELM_DRIVER` can point that storage at ConfigMaps, memory or SQL instead, but the content is the same. `helm status`, `helm list`, `helm history`, `helm get values` and `helm get manifest` all read that record and nothing else about the workload. That single fact is the whole answer. `deployed` is a statement about an **operation that finished**, not about the cluster today. Between operations Helm runs nothing: no watch, no informer, no controller, no interval. Nothing in Helm notices a `kubectl edit`, a `kubectl scale`, a mutating webhook rewriting a pod template, or another controller taking a field over. Delete every Deployment a release owns and `helm status` still prints `deployed`, with the same revision, and `helm list` still lists the release. The contrast worth naming in an interview is with a reconciling system — an in-cluster agent that continuously compares a desired state to live state and can report or correct divergence. Helm has never been that, by design; it is a client-side package manager that applies once per command and then goes away. Which of the two models you want is a delivery decision, not something to be fixed by looking harder at `helm status`. ## Three things called "the manifest" Much of the confusion here is vocabulary. There are three artefacts, and the question is only interesting when they disagree: 1. the YAML a **fresh render** produces from today's chart and values; 2. the manifest **stored in the release record**, which is what Helm last applied and what `helm get manifest` prints; 3. the **live objects** in the API server. They coincide for a moment after an upgrade and start diverging immediately: the API server defaults fields, controllers write status and take ownership of things like replica counts, and a human may edit something. `helm status` compares none of these; it just reads the status field inside (2)'s record. ## Doing the comparison yourself The standard move is to feed the stored manifest to a server-side diff: ```bash helm get manifest reranker-api -n reco | kubectl diff -f - ``` Each object is sent to the API server as a dry-run apply, so server defaulting is applied to your input before comparison and you see the field differences that a real apply would produce. It exits non-zero when there are differences, which is enough for a scheduled job to alert on. Know its blind spots: hook-annotated manifests are not part of what `helm get manifest` prints (they live in `helm get hooks`), resources installed from `crds/` are never updated or deleted by Helm at all so a template diff says nothing about them, and any field owned by another controller shows as a difference even though nobody drifted anything. ## Why this was never a status feature To report drift, Helm would have to fetch every object in the release, diff it field by field, and then decide which differences are *meaningful* — exactly the hard part that reconcilers spend their design budget on. Helm 3 had a status flag that listed the release's resources, and even that only printed names and readiness fetched with a get; it never compared fields against the stored manifest. Helm 4 removed it. Nothing in either version turns `helm status` into a drift report. ## What happens to the edit next time A good answer closes the loop without over-promising. Whether the hand edit survives the next `helm upgrade` is decided by the apply path — Helm 4 writes with server-side apply by default on install, while on upgrade the mode is inherited from how the release was previously applied — and by whether the chart even sets that field. If the chart does not template `spec.replicas`, an upgrade will typically leave a hand-scaled value alone; if it does, the upgrade asserts it back. "The next upgrade will fix it" is a guess, not a mechanism. The safe operational answer is: detect the difference deliberately with a diff, decide whether the cluster or the chart is right, and then either re-run the upgrade so the record and the cluster agree again, or fold the change into the chart.