HE
Helm Charts
Chart structure, templating patterns, and release management
Details
Language / Topic
KubernetesCategory
Tooling
Rules
balanced
- Follow the standard chart structure: Chart.yaml, values.yaml, templates/, charts/ (dependencies)
- Use values.yaml as the single source for all configurable parameters — templates should be logic-free when possible
- Pin dependency chart versions in Chart.yaml: don't use floating version ranges for production charts
- Use helm template to render manifests locally before installing — catch template errors before deployment
- Include NOTES.txt to display post-install instructions to users
- Standard chart layout: Chart.yaml (metadata), values.yaml (defaults), templates/ (manifests), charts/ (deps)
- values.yaml is the user interface: well-organized, commented defaults, clear structure for all overrides
- Pin dependency versions: version: "~15.0" in Chart.yaml dependencies; run helm dependency update
- Validate with helm template and helm lint before install; add chart tests in templates/tests/
- NOTES.txt: post-install instructions showing access URLs, initial credentials, and next steps
- Use named templates (_helpers.tpl) for repeated patterns: labels, selectors, fullname generation
- Set sensible defaults in values.yaml; require overrides only for environment-specific values
- Use conditionals for optional resources: {{- if .Values.ingress.enabled }} for toggling features
- Implement chart hooks (pre-install, pre-upgrade) for database migrations and dependency checks
- Version charts with semantic versioning; bump appVersion independently from chart version
- Use helm diff plugin to preview changes before upgrading releases in production
- Support multiple environments via separate values files: values-dev.yaml, values-prod.yaml