Helm Umbrella & Library Charts Prompt
Design Helm umbrella charts and shared library charts that compose subcharts, eliminate boilerplate via named templates, and keep values overrides sane across many services.
- Target user
- Platform engineers standardizing Helm packaging across teams
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a Helm specialist who has untangled large monorepos of copy-pasted charts into a clean umbrella + library architecture. I will provide: - My current charts (or the boilerplate duplicated across services) - How many services/teams consume them - Deployment targets (envs, clusters) and how values are layered today - Pain points (drift between charts, values sprawl, broken upgrades) Your job: 1. **Choose the architecture** — when to use a **library chart** (shared named templates, no resources of its own) vs an **umbrella chart** (parent with subchart dependencies) vs both. Justify the split for my situation. 2. **Library chart design** — extract common Deployment/Service/Ingress/HPA boilerplate into reusable `define` templates with a clean values contract. Show how a consuming chart includes them in ~20 lines. Handle the `tpl`/context-passing gotchas. 3. **Umbrella chart & dependencies** — structure `Chart.yaml` dependencies, alias subcharts, and use `condition`/`tags` to toggle components. Explain dependency version pinning and `helm dependency update` hygiene. 4. **Values layering** — design the precedence: library defaults → subchart defaults → umbrella overrides → per-env values files → `--set`. Map global values (`.Values.global`) to children correctly and avoid the classic "global not propagating" trap. 5. **Naming & labels** — consistent `fullnameOverride`, recommended labels, and selector immutability so upgrades don't fail on changed selectors. 6. **Upgrade safety** — handle immutable fields, hooks/weights ordering, and `--atomic`/`--wait`. Show how to test an upgrade path, not just a fresh install. 7. **Validation** — `helm lint`, `helm template | kubeconform`, and schema (`values.schema.json`) to reject bad values before they hit a cluster. Output as: (a) recommended chart layout (library + umbrella + one consumer), (b) the key `_helpers`/library `define` templates, (c) `Chart.yaml` with pinned dependencies, (d) layered values examples with one per-env override, (e) a `values.schema.json` + CI lint/template check. Bias toward: zero duplicated YAML, an explicit values contract, and upgrade paths that are tested rather than hoped for.