A Helm chart's templates nest if and range so deeply nobody can predict the output. Now what?

### Diagnose the sprawl before you redesign it "Nobody can read it" is a feeling; turn it into a number. For each values file you actually ship, render the chart and keep the output: ```bash for v in values/*.yaml; do helm template gateway ./chart -f "$v" > "render/$(basename "$v" .yaml).yaml" done sha256sum render/*.yaml | sort ``` Two numbers fall out. The first is how many *distinct* manifests the chart produces across real usage. The second is how many values keys exist only to feed a conditional rather than to set a field. In a library chart consumed by twelve service charts, it is common to find twelve values files collapsing to three or four distinct shapes: the conditionals are encoding a small number of archetypes, and the chart is paying combinatorial complexity to express a categorical choice. ### Read the render, not the template Helm gives you the tools to work at the output level, and they are the ones to reach for during triage: `helm template --debug` shows the parsed values alongside the render, `--show-only templates/deployment.yaml` narrows the output to a single file, `helm lint` catches structural problems in the chart, `--dry-run=server` sends the render to the API server for validation without persisting it, and `helm get manifest` shows what a live release actually applied. If your team can only reason about the chart by rendering it, that is data: the source of truth for review has already moved to the output, and you are maintaining a generator that nobody reads. ### The signals that templating has outgrown its job - Conditionals nested three or more deep, particularly `if` inside `range` inside `with`, where the meaning of dot at any given line is genuinely hard to state. - Values keys whose only purpose is to switch other values on, forming an untyped, undocumented mini-language. - Whitespace and indentation bugs that are found by rendering rather than by reading. - A change that requires touching `_helpers.tpl` and re-rendering all consumers to be sure nothing moved — the blast radius of an 18-chart umbrella is the whole umbrella. - Logic that is arithmetic or invariant-checking rather than shape selection. ### The four ways out, in increasing cost **Split the chart.** If the render collapses to three shapes, ship three charts. This is the cheapest fix and the most often skipped, because splitting feels like duplication — but duplication between three readable charts beats one chart that nobody can evaluate. **Extract into a library chart.** A chart with `type: library` in `Chart.yaml` installs nothing; it exists to publish named templates that other charts `include`. This is the right home for shared boilerplate such as label blocks and naming helpers. It concentrates the shared parts rather than reducing branching, so it helps when the problem is repetition and not conditionality. **Flatten by pushing the choice up.** Replace `enabled` flags with per-consumer values files that state the whole shape, so the chart branches less and the caller states more. Verbose, but readable, and it makes the render diff meaningful in review. **Stop templating.** If the logic is real program logic, generate the manifests with a typed generator — cdk8s expresses them as objects in a general-purpose language, jsonnet as a data-templating language with functions and composition — and let ordinary language tooling handle abstraction, testing and refactoring. Crucially this replaces only the rendering layer: the generated YAML still has to reach a cluster, and if you still want release history you either keep the output as a simple chart's static templates or accept plain applies. ### Do not confuse this with the packaging decision An unreadable chart is an argument against *this chart's design*, not automatically against Helm. Many charts get rescued by splitting alone. The stronger claim — that templating is the wrong medium — should rest on what the branching does, not on how it currently looks, because a badly written chart and an inherently unsuitable one look identical from the outside. ### What an interviewer is listening for Evidence first, then options with costs. A senior answer counts distinct outputs, names the specific Helm commands used to see them, distinguishes repetition from conditionality, and treats abandoning templating as the expensive last option rather than the opening move. An answer that jumps straight to "rewrite it in a real language" has skipped the measurement that would tell you whether the rewrite is needed.