What Helm Solves
Helm is the de facto package manager for Kubernetes. Instead of hand-editing dozens of raw YAML manifests per environment, Helm lets you define a reusable, parameterized chart once and install it many times with different values — for dev, staging, and production, or across many customers.
Cricket analogy: Instead of a curator manually re-marking the pitch and boundary lines by hand for every single match at every ground, a standard groundskeeping template is reused with only the venue-specific numbers changed, just as Helm lets you install one chart many times with different values.
Anatomy of a chart and its templates
A chart is a directory with a fixed layout: Chart.yaml holds metadata, values.yaml holds default configuration, and templates/ holds Kubernetes manifest templates written in Go template syntax that reference values from values.yaml. Templates use {{ .Values.x }} to pull in values, {{ .Release.Name }} for the release name, and helper functions/partials (_helpers.tpl) to keep labels and names consistent across resources.
Cricket analogy: A tour dossier has a fixed structure: a cover page with team metadata (Chart.yaml), a default squad list (values.yaml), and match-day plans (templates/) that reference the squad list by placeholder like {{ .Values.playerName }}, kept consistent via a shared style guide (_helpers.tpl).
# Chart.yaml
apiVersion: v2
name: web
version: 1.2.0 # chart version
appVersion: "1.5.0" # version of the app it deploys
---
# values.yaml
replicaCount: 3
image:
repository: registry.example.com/web
tag: "1.5.0"
---
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-web
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: web
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"Installing and upgrading releases
helm install creates a named release from a chart. helm upgrade applies changes to values or chart version to an existing release; --install makes the command idempotent for CI/CD, and every install/upgrade is recorded as a new release revision. helm template renders manifests locally without contacting the cluster — invaluable for reviewing generated YAML before applying.
Cricket analogy: Naming and fielding a new touring squad for the first time is like 'helm install' creating a named release; making roster changes mid-series is 'helm upgrade', and reviewing the proposed team sheet before it's officially announced is like 'helm template' rendering locally first.
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install web ./charts/web -f values-prod.yaml --namespace prod --create-namespace
helm upgrade web ./charts/web --set image.tag=1.6.0 --namespace prod
helm upgrade --install web ./charts/web -f values-prod.yaml --namespace prodRolling back a release, dependencies, and hooks
Like kubectl rollout undo for Deployments, Helm keeps release history so a bad upgrade can be reverted in one command; note that helm rollback restores the previous chart/values state but does not undo external side effects (e.g. a database migration a hook ran), so design chart hooks with rollback safety in mind. Charts can also declare dependencies on other charts (e.g. a Redis subchart) in Chart.yaml under dependencies, fetched with helm dependency update. Hooks (helm.sh/hook annotations like pre-install or post-upgrade) run Jobs at specific points in a release's lifecycle, commonly for migrations or smoke tests.
Cricket analogy: Just as a captain can revert to a previous winning batting order in one decision if a new lineup fails, 'helm rollback' restores the previous chart state in one command; but if the failed lineup already led to a real forfeited match, that outcome isn't undone by reverting.
helm history web -n prod
helm rollback web 2 -n prod # roll back to revision 2
helm status web -n prod
helm uninstall web -n prod- A chart = Chart.yaml (metadata) + values.yaml (defaults) + templates/ (Go-templated manifests).
- helm install creates a release; helm upgrade updates one; helm rollback reverts to a prior revision.
- -f/--values supplies a values file, --set overrides individual keys on the command line.
- helm template renders manifests locally for review without touching the cluster.
- helm history shows revisions much like kubectl rollout history does for Deployments.
- Chart dependencies (subcharts) and lifecycle hooks extend charts beyond plain templating.
Practice what you learned
1. Which file in a Helm chart holds the default configuration values?
2. Which command renders a chart's manifests locally without applying them to a cluster?
3. What does helm upgrade --install do if the named release does not already exist?
4. Which command reverts a Helm release to a previous revision?
5. What is the purpose of Chart.yaml's appVersion field?
Was this page helpful?
You May Also Like
ConfigMaps and Secrets
Learn how to externalize configuration and sensitive data from container images using ConfigMaps and Secrets in Kubernetes.
Deployments and ReplicaSets
Learn how Deployments manage ReplicaSets to declaratively run, scale, and update stateless Pod replicas in Kubernetes.
CI/CD Pipelines for Containers
How to design continuous integration and delivery pipelines that build, test, scan, and deploy containerized applications to Kubernetes.
Rolling Updates and Rollbacks
Learn how Kubernetes Deployments update Pods gradually with zero downtime and how to roll back safely when a release breaks.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics