Understanding Helm Charts
Explore chart structure, template syntax, built-in objects, and commands that help you render and lint Helm templates.
Chart Directory Structure
A Helm chart is usually organized like this:
mychart/
├── Chart.yaml
├── values.yaml
├── charts/
├── templates/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── _helpers.tpl
└── .helmignore
What the Main Files Do
| File or folder | Purpose |
|---|---|
Chart.yaml | Chart metadata |
values.yaml | Default configuration values |
templates/ | Kubernetes manifest templates |
charts/ | Dependent subcharts |
Built-in Objects
| Object | What it gives you |
|---|---|
.Release | Release information such as name and namespace |
.Values | User-supplied and default values |
.Chart | Chart metadata |
Template Syntax Example
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}
spec:
template:
spec:
containers:
- name: app
image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
Debug Templates Locally
helm template my-release ./mychart
helm lint ./mychart
Scaffold a New Chart
helm create mychart
That command generates a starter structure you can customize.
Why Helm Templates Help
Helm lets you keep one chart and vary values by environment instead of copying many slightly different YAML files.
Helm templating is like a mail merge for Kubernetes manifests. The template stays reusable while values change per environment.
Exercise
Values Object
Which built-in Helm object commonly holds chart configuration values?
Exercise
Template Debugging
Why is `helm template` useful?