Kubernetes Helm Charts Cheat Sheet
Packaging, templating, and deploying Kubernetes applications with Helm charts, values files, and releases.
2 PagesIntermediateFeb 2, 2026
Core Helm Commands
Everyday Helm CLI workflow.
bash
helm create mychart # Scaffold a new charthelm install myrelease ./mychart # Install a chart as a releasehelm upgrade myrelease ./mychart # Upgrade an existing releasehelm upgrade --install myrelease ./mychart # Upgrade or installhelm rollback myrelease 1 # Roll back to revision 1helm list # List releases in current namespacehelm uninstall myrelease # Remove a releasehelm template ./mychart # Render manifests locally without installing
Chart Directory Structure
Standard layout produced by `helm create`.
text
mychart/ Chart.yaml # Chart metadata (name, version, appVersion) values.yaml # Default configuration values charts/ # Subchart dependencies templates/ deployment.yaml service.yaml ingress.yaml _helpers.tpl # Reusable template snippets NOTES.txt # Post-install usage notes
Templated Deployment Snippet
Using values and helpers inside a template file.
yaml
apiVersion: apps/v1kind: Deploymentmetadata: name: {{ .Release.Name }}-webspec: replicas: {{ .Values.replicaCount }} template: spec: containers: - name: web image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" ports: - containerPort: {{ .Values.service.port }}
Overriding Values
Pass custom values at install time via file or flags.
bash
# Using a values filehelm install myrelease ./mychart -f values.prod.yaml# Inline overrideshelm install myrelease ./mychart \ --set replicaCount=3 \ --set image.tag=1.4.0
Key Concepts
Terminology used throughout Helm.
- Chart- A packaged collection of Kubernetes manifest templates
- Release- A specific deployed instance of a chart with its own revision history
- Repository- A location (HTTP server or OCI registry) hosting packaged charts (`.tgz`)
- Hooks- Templates annotated to run at specific lifecycle points, e.g. pre-install, post-upgrade
Named Templates in _helpers.tpl
Define reusable, composable template snippets with `define`/`include` and the Sprig function library.
yaml
{{/* _helpers.tpl */}}{{- define "mychart.fullname" -}}{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}{{- end -}}{{- define "mychart.labels" -}}app.kubernetes.io/name: {{ .Chart.Name }}app.kubernetes.io/instance: {{ .Release.Name }}app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}helm.sh/chart: {{ printf "%s-%s" .Chart.Name .Chart.Version }}{{- end -}}{{/* Usage inside a template - always use 'include' (not 'template') so the output can be piped through functions like nindent */}}metadata: name: {{ include "mychart.fullname" . }} labels:{{ include "mychart.labels" . | nindent 4 }}
Subcharts, Conditions & Global Values
Declare chart dependencies and toggle them on/off from the parent's values.yaml.
yaml
# Chart.yamlapiVersion: v2name: myappversion: 1.0.0dependencies: - name: redis version: "18.x.x" repository: "https://charts.bitnami.com/bitnami" condition: redis.enabled tags: - caching - name: postgresql version: "14.x.x" repository: "https://charts.bitnami.com/bitnami" condition: postgresql.enabled---# values.yaml - toggles and subchart value overridesredis: enabled: true auth: enabled: falsepostgresql: enabled: falseglobal: imageRegistry: myregistry.example.com # visible to all subcharts as .Values.global.*
Lifecycle Hooks & helm test
Run one-off Jobs at specific points in a release's lifecycle, and define post-install smoke tests.
yaml
apiVersion: batch/v1kind: Jobmetadata: name: db-migrate annotations: "helm.sh/hook": pre-upgrade,pre-install "helm.sh/hook-weight": "-5" "helm.sh/hook-delete-policy": before-hook-creation,hook-succeededspec: template: spec: containers: - name: migrate image: myapp:1.0 command: ["./migrate", "up"] restartPolicy: Never---# templates/tests/connection-test.yaml - run with `helm test myrelease`apiVersion: v1kind: Podmetadata: name: {{ include "mychart.fullname" . }}-test-connection annotations: "helm.sh/hook": testspec: containers: - name: wget image: busybox command: ["wget", "{{ include \"mychart.fullname\" . }}:{{ .Values.service.port }}"] restartPolicy: Never
OCI Registries & the lookup Function
Push/pull charts as OCI artifacts and query live cluster state from inside a template.
bash
# Package and push a chart to an OCI-compliant registry (no separate index needed)helm package ./mycharthelm push mychart-1.0.0.tgz oci://myregistry.example.com/helm-charts# Install directly from OCIhelm install myrelease oci://myregistry.example.com/helm-charts/mychart --version 1.0.0
Helm Advanced Concepts
Terminology and tooling for production Helm usage beyond a single `helm install`.
- Library chart- `type: library` in Chart.yaml; provides only reusable `define` templates, produces no manifests of its own, can't be installed directly
- helm diff (plugin)- `helm diff upgrade` shows the exact manifest delta before you run a real upgrade, catching unintended changes
- helm secrets (plugin, via SOPS)- Encrypts values files at rest so secret material can live safely in a values.yaml in git
- post-renderer- A `--post-renderer` executable (e.g. Kustomize) that patches Helm's rendered output before it's applied
- Release history & rollback- Every install/upgrade is a numbered revision; `helm history` lists them, `helm rollback <rel> <rev>` reverts
- `--atomic` / `--wait`- `--atomic` auto-rolls-back on a failed install/upgrade; `--wait` blocks until resources report Ready
Pro Tip
Run `helm template` or `helm install --dry-run --debug` before applying to a real cluster — it renders the final manifests locally so you catch templating mistakes before they hit the API server.
Was this cheat sheet helpful?
Explore Topics
#KubernetesHelmCharts#KubernetesHelmChartsCheatSheet#DevOps#Intermediate#CoreHelmCommands#ChartDirectoryStructure#TemplatedDeploymentSnippet#OverridingValues#Kubernetes#CheatSheet#SkillVeris
