In Helm, what does the global block in a values file make available to a chart tree?

### The one key Helm treats specially Every other top-level key in an umbrella chart's values is addressed to exactly one chart: `worker-gpu:` goes to the dependency aliased `worker-gpu` and nowhere else. `global` is the exception. Helm copies the contents of the top-level chart's `global` block into the values of every chart in the tree, so the parent's templates and every subchart's templates all resolve `.Values.global.storageClass` to the same thing. Depth does not matter. A grandchild three levels down sees the same globals as the parent — unlike ordinary values, which have to be threaded through each intermediate key. That is exactly what globals are for: a subchart cannot read its parent's other keys or its siblings' keys, so without globals the only way to state one fact for the whole install is to repeat it in every block. ```yaml # transcode-platform/values.yaml global: storageClass: fast-nvme imageRegistry: registry.example.internal worker-gpu: replicaCount: 6 ingest: replicaCount: 2 ``` ```yaml # any chart in the tree, at any depth spec: storageClassName: {{ .Values.global.storageClass }} ``` ### Propagation is not enforcement This is the point most candidates miss and most teams learn the hard way. Helm's contribution is *delivery*: it makes the value readable at `.Values.global.imageRegistry` inside every chart. Whether anything happens is up to each chart's templates. A bundled third-party subchart that never wrote `.Values.global.imageRegistry` into its image reference will keep pulling from its own default registry while your global sits there, correct and ignored. So when a global appears to do nothing, the first check is not Helm's merge — it is `helm show values` on the subchart, to see which globals that chart documents. Charts that support a global usually say so, and the well-known convention names (`global.imageRegistry`, `global.imagePullSecrets`, `global.storageClass`) are conventions between chart authors, not features of Helm. Helm defines no global by itself. ### One namespace, many owners The second structural limit is that globals are a single flat namespace shared by charts that are versioned and released independently. There is no per-chart scoping, no ownership marker and, in practice, no schema over the whole tree. If two subcharts both read `global.storageClass` but one of them needs a block-storage class and the other needs a shared filesystem, the global cannot express that — one of them has to move back to a per-chart key. The same flatness makes globals sticky. Renaming or restructuring a global is a change to the contract of every chart in the tree at once, which is a much bigger blast radius than editing one subchart's block. Adding a global is cheap; removing one is not. Because of that, treat globals as owned by the **top-level parent**. That is the direction the merge is designed for, and it keeps one place responsible for the shared namespace. Relying on a subchart to supply a global default for its siblings is fragile — put the default in the parent's own `values.yaml` where a reader can find it. ### Operating with globals On the CLI the path works exactly like any other values path, so a single flag can retarget the whole tree: ```bash helm upgrade transcode transcode-platform/ \ --set global.imageRegistry=mirror.example.internal \ --dry-run=client --debug ``` The dry run prints the computed values Helm hands the templates, and it is worth reading before a real upgrade for a specific reason: a global touches every chart, so changing one re-renders the whole tree. If a global feeds into an object that triggers a rollout — an image reference, or a chart that renders a Secret whose checksum is annotated onto a pod template — flipping it restarts far more than the one workload you were thinking about. ### When not to reach for it A global is right when a value is genuinely a property of the *installation* rather than of a component: which registry mirror this cluster pulls from, which storage class exists here, what the cluster's DNS domain is, what the environment is called. It is the wrong tool for a value that only two of fourteen subcharts happen to share today, because you have then written a tree-wide contract to save yourself one duplicated key. Duplication in a values file is verbose but honest — it diffs cleanly and it is obvious who is affected. A global that half the tree reads and half ignores is neither.