How does a checksum/config pod annotation in a Helm chart restart Pods when a ConfigMap changes?

## The problem A chart renders a ConfigMap and a Deployment that consumes it. On upgrade the ConfigMap is updated in place and the Deployment's own spec is byte-identical to before, so the workload controller sees no reason to do anything - the running Pods keep serving the values they read when they started. Config delivered as environment variables is read once at process start and never re-read; config delivered as a mounted file may eventually appear on disk but only helps if the application watches the file and reloads. From the chart author's point of view, none of that is something a chart can rely on. ## The mechanism A workload controller rolls Pods when the **Pod template** changes. So the chart makes the config part of the Pod template - not the config itself, which would be enormous and would leak, but a hash of it: ```yaml spec: template: metadata: annotations: checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }} ``` Read it inside out. `$.Template.BasePath` is a built-in holding the chart's templates path, for example `scoring-chart/templates`; `print` concatenates it with `/configmap.yaml` to form the *name* of that template. `include` renders that template with the current context and returns its output as a string - this is why `include` is used rather than `template`, which writes directly to the output and cannot be piped. `sha256sum` hashes the string. The result is a stable hex digest that changes if and only if the rendered ConfigMap changes. Now every `helm upgrade` recomputes the hash. Same config, same digest, identical Pod template, no rollout. Different config, different digest, changed Pod template, ordinary rolling update with the workload's existing surge and unavailability settings. The rollout is the controller's normal behaviour, not something Helm does. ## Three details that get people **It must be on the Pod template.** `spec.template.metadata.annotations`, not the Deployment's top-level `metadata.annotations`. An annotation on the object itself is metadata about the Deployment and changing it triggers nothing. This is the single most common implementation bug, and it is invisible until someone changes config and wonders why nothing restarted. **Helm does not read the key.** `checksum/config` is a convention that spread from the Helm documentation, not a reserved name. You could call it `config-hash/scoring` and it would work identically, because the mechanism is "the Pod template changed", not "Helm noticed an annotation". Candidates who claim Helm restarts the Pods have the causality backwards. **Watch where the annotations block is emitted.** Charts commonly wrap the Pod template's `annotations:` key in a conditional over a values key that lets callers add their own annotations. If you nest the checksum inside that conditional, the checksum disappears for every caller who sets no annotations of their own - which is most of them. Emit `annotations:` unconditionally when the chart itself always has one to write. ## Choosing what to hash Hashing the whole rendered template file is the documented default and it is the safest starting point, but it is broad: the file includes the ConfigMap's own metadata, and that metadata carries version-bearing labels, so the digest moves whenever the chart version moves even if no config value changed. The narrower alternative hashes only the values subtree that feeds the config: ```yaml checksum/config: {{ toYaml .Values.scoring.config | sha256sum }} ``` That rolls Pods exactly when the configuration a user set changes. The trade is that it misses config the template computes from something other than that subtree. Pick one deliberately and say which in the chart's documentation. A rendered Secret gets the same treatment under a second annotation. Hash it - never inline the value. The annotation is readable by anyone who can read the Pod, and a hash is one-way while a copied value is not. ## What good looks like A good answer explains that the rollout comes from the Pod template changing, writes the `include`/`sha256sum` pipeline correctly, and puts it in the right place. A strong answer adds that the key name is arbitrary, that hashing the whole rendered file couples the rollout to chart-version bumps, and that a Secret needs the same annotation with the same hash-don't-inline discipline.