How do you address a value inside a nested Helm subchart with --set?

### The path is the values file, flattened `--set` does not have a syntax of its own for subcharts. It builds a values object, and that object is merged into the same tree the umbrella's `values.yaml` produces. So the rule is: whatever path the value would occupy in the parent's values file, that is the `--set` path. ```yaml # what it would look like in a file worker-gpu: encoder: threads: 12 ``` ```bash # the same thing on the command line helm upgrade transcode ./transcode-platform --set worker-gpu.encoder.threads=12 ``` Each segment is a level of the dependency graph. The first segment is a dependency's `name`, or its `alias` when one is declared in `Chart.yaml` — after aliasing, the chart's real name addresses nothing. A grandchild takes three segments, a great-grandchild four. Globals are the shortcut past all of it: `--set global.storageClass=fast-nvme` is readable by every chart in the tree, at any depth, without naming a single dependency. ### Nothing searches, so nothing errors The most important property of `--set` is what it does *not* do. Helm never hunts for a key named `threads` somewhere in the tree. It writes the path you gave, verbatim, into the values object. A misspelled or missing segment therefore produces a brand-new key that no chart reads, and the command succeeds — the upgrade goes out, the workload does not change, and nothing in the output says why. If the chart ships a `values.schema.json` that forbids additional properties, the mistake is caught; otherwise it is silent. That is why the verification step belongs in muscle memory: ```bash helm upgrade transcode ./transcode-platform \ --set worker-gpu.encoder.threads=12 \ --dry-run=client --debug ``` The computed-values section of that output shows exactly where your key landed. If it sits at the root instead of under the subchart, or under the chart's real name instead of its alias, the path is wrong. ### The syntax details that bite **Dots inside key names.** Kubernetes label and annotation keys are full of dots, and a dot is the path separator, so it must be escaped — and quoted so the shell does not eat the backslash: ```bash helm upgrade transcode ./transcode-platform \ --set worker-gpu.nodeSelector."topology\.kubernetes\.io/zone"=eu-west-2b ``` **Lists are indexed, not appended.** `--set worker-gpu.env[0].name=QUEUE_URL` writes element zero. There is no append syntax, so building a multi-element list on the command line means writing every index, and doing so replaces the chart's default list rather than adding to it. **Commas separate assignments**, which means a value that itself contains a comma has to be escaped — another reason a values file wins as soon as the value is non-trivial. **Types are inferred.** `--set worker-gpu.image.tag=1.20` yields a number, not the string `"1.20"`, and a leading-zero identifier loses its zeros. `--set-string` forces string typing and is the right default for image tags, account IDs and version-looking values. `--set-file key=path` reads the value from a file, which is how a certificate or a script body reaches a chart without being mangled on the command line. `--set-json` takes a JSON document for a value, which is the sane way to supply a nested structure or a real list in one argument. ### When to stop using --set A nested override on a fourteen-subchart umbrella is often four segments long, and three of them are boilerplate. A pipeline that accumulates a dozen such flags becomes unreviewable: nobody can diff it, the escaping is fragile, and the values that are actually in force are spread across a shell line rather than a file. Past one or two overrides, write a values file and pass it with `-f`. A file is diffable, reviewable in a pull request, and can be committed next to whatever produced it. The legitimate home for `--set` is the value that is genuinely per-invocation — the image tag CI just built, a release-specific identifier, a one-off toggle during an incident. Even then, keep the path honest: name the alias, count the levels, and dry-run once before the real upgrade rather than discovering afterwards that a seven-minute upgrade rolled out with the override silently parked in an unread key. ### Reading a path someone else wrote The skill worth practising is the reverse direction: given `--set worker-gpu.encoder.audio.bitrateKbps=192`, say what the chart tree must look like. The first segment names a dependency of the top-level chart — by alias if one is declared — the second names a dependency of that chart or a key inside it, and only the tail is the chart's own values. Helm cannot tell you which, because the path is written before any chart is consulted. That ambiguity is the reason a wrong path is invisible and the reason the computed values from a client-side dry run, not the command line, are the thing to check when an override does not take effect.