Helm Components

Let’s explore the core components of Helm and how they interact with Kubernetes. This article introduces the Helm CLI, Charts, Releases, Revisions, repositories, and where Helm stores metadata — plus practical examples showing templating and values usage. At a high level:

The Helm command-line utility runs on your local machine and performs Helm actions (install, upgrade, rollback, etc.).
A Chart is a file tree that contains templates and metadata describing how to create a set of Kubernetes resources for an application.
Applying a Chart to a cluster creates a Release — a single installation of an application using that Chart.
Each Release has multiple Revisions. A Revision is a snapshot of a Release’s state; Helm creates a new Revision whenever you change a Release with Helm (for example, helm upgrade).
Charts are published in repositories (public or private) for discovery and reuse.
Helm stores Release metadata inside the Kubernetes cluster — by default Helm 3 uses Kubernetes Secrets in the target namespace (it can also be configured to use ConfigMaps). Storing metadata in-cluster enables team members with cluster access to manage Releases without copying local state.

A diagram titled "Helm Components" showing an online chart repository and a helm CLI pulling a chart on the left. On the right is a Kubernetes release box containing multiple revision entries and a secret.

Helm stores its history (Releases and Revisions) in the cluster by default. This means anyone with appropriate namespace or cluster access can list and manage Releases for that namespace — Helm will always be able to determine the history and perform rollbacks using in-cluster metadata.

Now let’s review each piece in more detail. Summary of Helm components

Component	Purpose	Example / CLI
Helm CLI	Local tool to manage Charts and Releases	`helm install`, `helm upgrade`, `helm rollback`
Chart	Packaged file tree (templates, `values.yaml`, Chart.yaml) that describes Kubernetes resources	`./mychart` or `bitnami/wordpress`
Release	A deployed instance of a Chart in a cluster (tracked by Helm)	`helm install my-site bitnami/wordpress`
Revision	A snapshot of a Release created by Helm operations	Created on `helm upgrade`
Repository	Hosting for Charts (public/private)	Artifact Hub, custom chart repo
Storage backend	Where Helm stores metadata in-cluster	Secrets (default) or ConfigMaps

Charts and templating A Helm chart is a file tree containing templates (YAML files with Go template placeholders) and a values.yaml file that supplies configurable inputs for those templates. Most users consume existing charts and customize them by editing values.yaml or passing overrides with --values/--set rather than modifying templates directly. Common patterns:

.Values — the values exposed to templates, populated from values.yaml and CLI overrides.
include and helper templates — to share logic and produce consistent names/labels.
Conditional logic (if, with, range) — to render resources only when required.

Simple example: Service + Deployment templates (combined view)

# templates/service.yaml and templates/deployment.yaml (combined view)
apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app: hello-world

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: hello-world
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
        - name: nginx
          image: "{{ .Values.image.repository }}"
          ports:
            - name: http
              containerPort: 80
              protocol: TCP

Corresponding values.yaml:

replicaCount: 1

image:
  repository: nginx

For most use-cases you will provide a custom values.yaml or use helm install --set/--values to change behavior without touching the chart templates. Advanced templating patterns Larger charts (WordPress, Prometheus, Redis) use helpers and conditional rendering. This example demonstrates typical patterns like include, nindent, and conditional blocks:

apiVersion: {{ include "common.capabilities.deployment.apiVersion" . }}
kind: Deployment
metadata:
  name: {{ include "common.names.fullname" . }}
  namespace: {{ .Release.Namespace | quote }}
  labels:
{{- include "common.labels.standard" . | nindent 4 }}
{{- if .Values.commonLabels }}
{{- include "common.tplvalues.render" (dict "value" .Values.commonLabels "context" $ ) | nindent 2 }}
{{- end }}
{{- if .Values.commonAnnotations }}
annotations:
{{- include "common.tplvalues.render" (dict "value" .Values.commonAnnotations "context" $ ) | nindent 4 }}
{{- end }}
spec:
  selector:
    matchLabels: {{- include "common.labels.matchlabels" . | nindent 6 }}
{{- if .Values.updateStrategy }}
  strategy: {{- toYaml .Values.updateStrategy | nindent 4 }}
{{- end }}
{{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
{{- end }}

Releases and why they matter A Release is an installed instance of a Chart. You can create multiple Releases from the same Chart to run separate independent instances (e.g., dev and prod). Examples:

# Install a release named my-site from the bitnami/wordpress chart
helm install my-site bitnami/wordpress

# Install another independent instance from the same chart
helm install my-second-site bitnami/wordpress

Each Release (for example my-site) has its own Revision history, enabling safe rollbacks and auditability.

Important: Helm only creates new Revisions when you modify a Release using Helm commands (for example helm upgrade). Changes made directly with kubectl (like scaling a Deployment) do not create Helm Revisions and will not be tracked in the Helm Release history.

Finding charts — Artifact Hub There are thousands of pre-built charts across public and private repositories (Bitnami, AppsCode, community repos, vendor-specific repos). Artifact Hub centralizes discovery by aggregating many publishers and repository indexes. Use Artifact Hub to:

Search for popular charts (Redis, NGINX, WordPress, Prometheus).
Inspect chart versions, publisher metadata, and security/verification badges.
Find installation instructions and values examples.

A screenshot of the Artifact Hub "Helm Repositories" page showing a list of Kubernetes Helm charts (including "kube-prometheus-stack" and "ingress-nginx"), with a search bar at the top and filter options in a left sidebar.

What this article covers

Installing charts from repositories
Customizing charts with values.yaml, --values, and --set
Templating basics and common helper patterns
Release lifecycle: install, upgrade, rollback, history
Hands-on examples (Hello World and WordPress scenarios)

Links and references

Further reading: explore official charts on Artifact Hub, inspect Chart.yaml and values.yaml of example charts, and try installing a simple chart to see Release and Revision behavior firsthand.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Watch Video