10.04 Helm Components

Abstract

Helm is a package manager and release manager for Kubernetes.

It helps install, upgrade, rollback, and uninstall Kubernetes applications as a single package instead of managing many YAML files manually.

Helm Components Overview

Helm has four main components:

Component	Purpose
Helm CLI	Command-line tool used by users
Chart	Package containing Kubernetes templates and values
Release	Installed instance of a chart
Repository	Place where Helm charts are stored and shared

Note

In Helm 3, release metadata is stored inside the Kubernetes cluster, usually as Secrets.

Helm CLI

The Helm CLI is installed on your local machine or CI/CD runner.

It is used to perform actions such as:

install applications
upgrade applications
rollback releases
uninstall applications
search charts
manage chart repositories

Common commands:

helm install
helm upgrade
helm rollback
helm uninstall
helm repo add
helm search repo

Tip

Helm uses your Kubernetes context from kubeconfig, similar to kubectl.

Check current context before running Helm commands:

kubectl config current-context

Helm Chart

A Helm Chart is a package that contains Kubernetes YAML templates.

It includes all files needed to deploy an application.

Example chart structure:

hello-world/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    └── service.yaml

File	Purpose
`Chart.yaml`	Chart metadata
`values.yaml`	Default configurable values
`templates/`	Kubernetes manifests with templates

Example

A chart can contain Deployments, Services, ConfigMaps, Secrets, PVCs, Ingress resources, ServiceAccounts, RBAC objects, and more.

Chart Templates

Helm templates allow YAML files to use dynamic values.

Example deployment.yaml:

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:
        - containerPort: 80

Example values.yaml:

replicaCount: 3

image:
  repository: nginx

Note

The chart template defines the structure, and values.yaml provides the input values.

values.yaml

The values.yaml file is the main customization file for a Helm chart.

You can use it to configure:

replica count
image repository and tag
service type
resource limits
ingress settings
storage settings
environment variables

Example:

replicaCount: 2

image:
  repository: nginx
  tag: "1.25"

service:
  type: NodePort
  port: 80

Install using custom values:

helm install hello-world ./hello-world -f values.yaml

Tip

In production, store environment-specific values files in Git, such as values-dev.yaml, values-stage.yaml, and values-prod.yaml.

Helm Release

A Release is a single installed instance of a chart.

Example:

helm install my-site bitnami/wordpress

Here:

Part	Meaning
`my-site`	Release name
`bitnami/wordpress`	Chart name

Example

You can install the same chart multiple times using different release names.

helm install my-site bitnami/wordpress
helm install my-second-site bitnami/wordpress

Both releases use the same chart, but they are managed independently.

Why Releases Are Useful

Releases allow teams to manage multiple installations separately.

Example use cases:

Release	Purpose
`wordpress-prod`	Production website
`wordpress-dev`	Developer testing website
`wordpress-stage`	Pre-production validation

Each release can have:

different values
different namespaces
different revisions
independent upgrades
independent rollbacks

Success

Releases make Helm useful for production because each deployment is tracked as a separate application instance.

Helm Revisions

Each release can have multiple revisions.

A new revision is created when a release changes.

Examples:

helm install my-site bitnami/wordpress
helm upgrade my-site bitnami/wordpress
helm rollback my-site 1

Action	Result
Install	Revision 1
Upgrade	Revision 2
Rollback	Revision 3

View release history:

helm history my-site

Note

Revisions act like snapshots of release state and allow rollback when an upgrade fails.

Helm Metadata

Helm stores release metadata inside the Kubernetes cluster.

In Helm 3, this metadata is commonly stored as Kubernetes Secrets.

This metadata includes:

release name
chart used
values used
manifest history
revision history

View Helm release secrets:

kubectl get secrets

Example secret naming pattern:

sh.helm.release.v1.<release-name>.v1

Warning

Do not manually delete Helm release Secrets unless you understand the impact.
Deleting them can break Helm's ability to track, upgrade, or rollback releases.

Helm Repository

A Helm Repository stores packaged charts.

Repositories are similar to Docker image registries, but for Helm charts.

Examples of chart sources:

Artifact Hub
Bitnami
TrueCharts
AppsCode
Community Operators

Add a repository:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Search charts:

helm search repo wordpress

Install from repository:

helm install my-site bitnami/wordpress

Tip

Prefer official or verified publisher charts when available.

Artifact Hub

Artifact Hub is a central place to discover Helm charts and Kubernetes packages.

You can use it to find charts for:

WordPress
Redis
Prometheus
Grafana
Argo CD
NGINX
PostgreSQL
MySQL

Note

Artifact Hub lists charts from many providers, but the charts are still hosted in their own repositories.

Helm Chart vs Release

Concept	Meaning
Chart	Installable package/template
Release	Actual installed instance of the chart
Revision	Versioned state of a release
Repository	Place where charts are stored

Example

A chart is like an application installer.
A release is the installed application.

Example: Simple Hello World Chart

A simple chart may create:

Deployment
Service

values.yaml:

replicaCount: 2

image:
  repository: nginx

service:
  type: NodePort
  port: 80

deployment.yaml uses values:

replicas: {{ .Values.replicaCount }}
image: "{{ .Values.image.repository }}"

service.yaml exposes the application:

apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: hello-world

Helm Install Flow

User runs Helm CLI
        |
        v
Helm downloads chart from repository
        |
        v
Helm renders templates using values.yaml
        |
        v
Helm sends manifests to Kubernetes API
        |
        v
Kubernetes creates objects
        |
        v
Helm stores release metadata as Secrets

Success

Helm does not replace Kubernetes. It generates and manages Kubernetes manifests.

Useful Helm Commands

Task	Command
Add repo	`helm repo add <name> <url>`
Update repos	`helm repo update`
Search repo	`helm search repo <keyword>`
Install chart	`helm install <release> <chart>`
List releases	`helm list`
Upgrade release	`helm upgrade <release> <chart>`
Rollback release	`helm rollback <release> <revision>`
Uninstall release	`helm uninstall <release>`
Show chart values	`helm show values <chart>`
Render templates locally	`helm template <release> <chart>`

Production Best Practices

Recommended

Use Helm 3
Use official or verified charts when possible
Pin chart versions in production
Store values files in Git
Use separate values files per environment
Review generated manifests before applying
Use namespaces to isolate releases
Keep secrets out of plain values.yaml
Use CI/CD or GitOps for Helm deployments

Validate Before Installing

Render templates locally:

helm template my-site bitnami/wordpress

Dry run install:

helm install my-site bitnami/wordpress --dry-run --debug

Check Kubernetes permissions:

kubectl auth can-i create deployments
kubectl auth can-i create services
kubectl auth can-i create secrets

Tip

Always test Helm charts in a non-production namespace before deploying to production.

Do's

Use clear release names
Use version-controlled values files
Use separate namespaces for environments
Review chart documentation before installation
Check chart templates before applying
Track Helm release history
Use rollback when upgrades fail

Don'ts

Don't install random charts without reviewing them
Don't store passwords directly in plain text values files
Don't manually delete Helm release metadata
Don't use the same release name twice in the same namespace
Don't make manual changes to Helm-managed resources without updating Helm values
Don't run Helm against the wrong Kubernetes context

Security Considerations

Danger

A Helm chart can create powerful Kubernetes resources such as RBAC roles, ClusterRoles, Secrets, and privileged workloads.

Before installing a chart, review:

helm template <release> <chart>

Check for:

privileged containers
hostPath mounts
excessive RBAC permissions
exposed services
hardcoded secrets
outdated images

Warning

Treat Helm charts like application code. Review them before using them in production.

Common Mistakes

Installing into the wrong cluster

Check context:

kubectl config current-context

Installing into the wrong namespace

Use:

helm install my-site bitnami/wordpress -n wordpress --create-namespace

Losing custom changes

Avoid manually editing Helm-managed resources.

Instead, update values and run:

helm upgrade my-site bitnami/wordpress -f values-prod.yaml

Summary

Quote

Helm CLI runs commands from your machine or CI/CD system
Helm Charts define Kubernetes resources using templates
values.yaml customizes chart behavior
A Release is an installed instance of a chart
Revisions track release changes over time
Repositories store and distribute charts
Helm metadata is stored inside Kubernetes as Secrets