Subcharts and Dependencies
Subcharts and Dependencies
Declare dependencies in Chart.yaml:
dependencies:
- name: postgresql
version: 12.5.10
repository: https://charts.bitnami.com/bitnami
condition: postgresql.enabled
alias: db
helm dependency update downloads .tgz files into charts/. Parent values flow in by dependency key (postgresql: in the parent's values.yaml configures the subchart), while a top-level global: block is visible to every chart and subchart. condition toggles install (here: set postgresql.enabled=false to skip it); alias lets the same chart be instantiated twice under different keys.
Hooks, CRDs, and Library Charts
Hooks, CRDs, and Library Charts
Hooks are resources that run outside the normal release lifecycle:
metadata:
annotations:
"helm.sh/hook": pre-install,pre-upgrade
"helm.sh/hook-weight": "5"
"helm.sh/hook-delete-policy": before-hook-creation
Typical hooks: schema migrations, seed Jobs, tests. With hook-delete-policy: hook-succeeded they clean up; without one they linger for debugging.
CRDs live in crds/ and are installed only on first install — Helm never upgrades them, so CRD changes must be applied manually with kubectl apply.
Library charts (type: library) contain only templates: no templates/ manifests to deploy, they exist to be included by other charts, sharing helpers without shipping workloads.
Pitfalls and Interview Angles
Pitfalls and Interview Angles
Stuck hooks. A Job hook with hook-failure-policy: hook-style failures or a pod that never completes blocks the entire install — set deadlines and delete policies deliberately.
CRD drift. Because crds/ files never update, a chart upgrade that changes a CRD silently runs against the old schema; version conversions then require webhook planning.
Value surprises. Subchart values can be overridden by the parent's global block in ways authors did not anticipate — read the subchart's values.yaml before overriding.
Library chart misuse. Putting manifests in a library chart makes rendering fail; only named templates belong there.
Interview angle: order a lifecycle out loud (CRDs → pre-install hooks → resources → post-install), then contrast a regular chart with a library chart and a hook-managed Job.
Quiz
1. What does helm do with files in a chart's crds/ directory?
2. What is a library chart?
3. Which annotation schedules a migration Job before every upgrade?
Flashcards
Question
Subchart value flow
Click to reveal answer
Answer
Parent values.yaml keys named after the dependency configure it; global is visible to all charts.
Question
helm.sh/hook
Click to reveal answer
Answer
Lifecycle annotations (pre-install, pre-upgrade, post-*, test) with hook-weight ordering and delete policies.
Question
crds/ semantics
Click to reveal answer
Answer
Applied on first install, never upgraded by Helm, kept on uninstall — manage CRD updates with kubectl.
Question
condition vs alias
Click to reveal answer
Answer
condition toggles whether a dependency installs; alias lets the same chart appear twice under different keys.
Revision Notes
Key Takeaways
- 1. Dependencies are value-scoped children toggled by condition and wired by alias/global values
- 2. Hooks escape the release lifecycle: weight them, give them delete policies and timeouts
- 3. CRDs are install-only and library charts are template-only — know both boundaries
Interview Tips
- • Describe the exact resource lifecycle order including where hooks and CRDs sit
- • Explain what happens on chart upgrade when a CRD changed, and how you would apply it
Cheat Sheet
Deps via Chart.yaml + helm dependency update; values by key, global shared, condition/alias. Hooks: annotation + weight + delete-policy. crds/ install-only. Library charts = templates only.