helm upgrade keeps fighting an operator over a field both set — how do you fix it?

### First, decide which "ownership" you are talking about Three different mechanisms wear this word, and mixing them up is the most common way this conversation goes wrong: * **Release ownership** — the `app.kubernetes.io/managed-by: Helm` label and the `meta.helm.sh/release-name` and `meta.helm.sh/release-namespace` annotations Helm puts on the objects a release owns. This is about *which release* an object belongs to. `helm upgrade --take-ownership` (available since Helm 3.17) is the flag for that problem: adopting existing objects into a release. * **Field ownership** — server-side apply's field managers, recorded in the object's `metadata.managedFields`. This is about *which writer* owns each individual field. `--force-conflicts` is the flag for that problem. * **Owner references** — the parent/child links Kubernetes uses for garbage collection, which is how a controller's own created objects are cleaned up. A fight between a chart and a controller over one field is the second kind, and only the second kind. Using `--take-ownership` on it does nothing; using `--force` does something else entirely. ### Why Helm 4 changed the symptom Helm 4 made server-side apply the default write path. On `install`, `--server-side` is a boolean defaulting to true. On `upgrade` and `rollback` it is a *string* defaulting to `auto`, which inherits the apply method of the previous release. That inheritance produces a genuinely confusing field report: a release first installed by Helm 3 and later upgraded with a Helm 4 client stays on the old client-side path, so two clusters running the same chart and the same CLI can behave differently. Check the release's history before you believe either symptom. **Under server-side apply**, each writer records the fields it sets. When the chart declares `spec.instances` on the ledger's custom resource and the operator has already claimed that field, the apply comes back as a conflict and the upgrade fails outright. That is unpleasant but honest — the cluster tells you two writers disagree. **Under the Helm 3 client-side three-way merge**, Helm computes a patch from the previous revision's stored manifest, the live object and the newly rendered manifest, and patches the field back to the chart's value. No error. The controller reconciles and writes its own value again. The object oscillates, `helm get manifest` disagrees with the live object between runs, and every upgrade produces a spurious diff. ### The fix: one field, one owner Whoever is not the owner must not emit the field at all. Not "emit the same value" — not emit it. A chart that writes the value the controller currently happens to want is still claiming the field, and will still fight the moment the controller changes its mind. In a chart this is a conditional in the template, gated by a value: ```yaml spec: {{- if not .Values.autoscaling.enabled }} replicas: {{ .Values.replicaCount }} {{- end }} ``` The same pattern applies to any field a controller computes: a scaled replica count, an image tag rewritten after a managed version migration, a resource request set by a sizing controller, a status-derived annotation. Under server-side apply there is a second half to the fix: when Helm stops declaring a field it previously owned, it releases it, so the object converges on the controller's value rather than keeping a stale one. ### Diagnosing it Read the object's `metadata.managedFields` — it names every manager and the exact fields each one owns, which turns "something keeps changing this" into a definite answer. Compare it against `helm get manifest <release>`, which shows what the release believes it applied. If the field appears in the chart's manifest *and* under another manager in `managedFields`, you have found the fight. For the flip-flopping client-side case, the giveaway is that the value is correct immediately after an upgrade and wrong minutes later, on a period that matches the controller's resync rather than anything Helm does. ### When `--force-conflicts` is right When the chart genuinely is the owner and something else claimed the field by accident — a one-off `kubectl` edit during an incident, a migration from a tool that has since been removed. `--force-conflicts` makes Helm take the field over and become its manager. It is a deliberate, one-time act, not a way to make the upgrade command stop complaining; wiring it into a pipeline permanently guarantees you will overwrite a controller that had a good reason for its value. It is also mutually exclusive with `--force-replace`, and note the trap: `--force` is a deprecated alias of `--force-replace`, which is about recreating resources, and has nothing to do with server-side apply conflicts. A candidate who says "just use `--force`" has named the wrong flag for the wrong mechanism. ### The judgment behind it The real answer to "who wins" is that nobody should have to win. Two writers on one field is a design defect, and the chart is usually the side that should yield, because the controller is reacting to information — load, health, migration progress — that the chart's author did not have at render time.