luvv to help

Menu

Topic 6 of 8

Helm Basics

Learn Helm Basics for free with explanations, exercises, and a quick test (for Platform Engineer).

Published: January 23, 2026 | Updated: January 23, 2026

Table of Contents

Why this matters

As a Platform Engineer, you roll out apps and infra quickly and safely. Helm is Kubernetes' package manager. It lets you:

  • Install complex apps (databases, ingress, dashboards) with one command.
  • Keep environments consistent via versioned, parameterized templates.
  • Upgrade or roll back reliably across clusters and teams.

Who this is for

  • Platform/DevOps/Backend engineers deploying to Kubernetes.
  • Engineers who want repeatable, reviewable Kubernetes changes.

Prerequisites

  • Basic Kubernetes (pods, deployments, services) and kubectl.
  • Comfortable with YAML and container images.
  • Optional but helpful: basic Go template syntax exposure.

Concept explained simply

Helm bundles Kubernetes manifests and settings into a reusable package called a chart. You install a chart into a cluster as a release. Values let you customize a chart without editing templates.

Mental model

Think: Chart (templates + defaults) + Values (your inputs) → Rendered YAML → Applied to cluster as a Release. The Release is versioned so you can upgrade/rollback safely.

Key terms

  • Chart: A versioned package with Chart.yaml, values.yaml, and templates/.
  • Release: A running instance of a chart in a namespace with a name, revisions, and history.
  • Values: Configuration inputs merged from defaults, files (-f), and flags (--set).
  • Repository: A collection of charts you can add and search.

Core commands you'll use

helm repo add NAME URL
helm repo update
helm search repo KEYWORD
helm install RELEASE CHART [--namespace ns --create-namespace]
helm upgrade RELEASE CHART -f values.yaml --set key=val
helm rollback RELEASE REVISION
helm list [-n ns]
helm uninstall RELEASE [-n ns]
helm template RELEASE PATH/TO/CHART   # render to stdout without installing
helm lint PATH/TO/CHART               # static checks

Worked examples

Example 1 — Install a public chart into a new namespace
  1. Initialize repo cache: 
    helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
  2. Install NGINX from Bitnami into namespace demo: 
    helm install web bitnami/nginx \
  --namespace demo --create-namespace
  3. Check resources: 
    helm list -n demo
kubectl get all -n demo

Result: a running NGINX deployment and service in demo.

Example 2 — Create a new chart and customize values
  1. Scaffold a chart: 
    helm create hello
  2. Edit values.yaml (key changes): 
    image:
  repository: nginx
  tag: "1.25"
replicaCount: 2
service:
  type: ClusterIP
  port: 80
  3. Render without installing: 
    helm template hello ./hello | head -n 50
  4. Install into dev namespace: 
    helm upgrade --install hello ./hello -n dev --create-namespace

Result: 2 replicas of nginx, service on port 80.

Example 3 — Upgrade then rollback safely
  1. Scale up using CLI values: 
    helm upgrade hello ./hello -n dev --set replicaCount=3
  2. Verify revision and pods: 
    helm history hello -n dev
kubectl get deploy hello -n dev -o jsonpath='{.spec.replicas}'
  3. Rollback to previous revision (example to 1): 
    helm rollback hello 1 -n dev
Example 4 — Templating a ConfigMap from values

values.yaml:

env:
  LOG_LEVEL: info
  FEATURE_X: "true"

templates/configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "hello.fullname" . }}-config
  labels:
    app.kubernetes.io/name: {{ include "hello.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/version: {{ .Chart.AppVersion }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
data:
{{- if .Values.env }}
{{ toYaml .Values.env | nindent 2 }}
{{- end }}

Render to verify indentation:

helm template hello ./hello | sed -n '/ConfigMap/,/---/p'

Exercises

Complete the following. Use a test cluster (e.g., kind or minikube). Avoid production clusters.

  • [ ] Exercise 1: Install a public NGINX chart in a dedicated namespace and verify resources.
  • [ ] Exercise 2: Scaffold a chart, customize values, install, upgrade, and check history.
  • [ ] Exercise 3: Write a ConfigMap template to render environment variables from values.

Tip: Use these checks as you work:

  • [ ] helm lint to catch template issues early.
  • [ ] helm template to preview manifests before applying.
  • [ ] helm history to confirm revisions.

Common mistakes and self-check

  • Forgetting helm repo update before install. Self-check: run it and retry search/install.
  • Indentation issues in templates. Self-check: use toYaml | nindent; preview with helm template.
  • Wrong values precedence. Self-check: remember highest wins is --set; last -f wins among files.
  • Mismatched namespace. Self-check: use --namespace consistently; helm list -n the same namespace.
  • Confusing chart version vs appVersion. Self-check: bump chart version on any template/values change; appVersion is the application image version.
  • Rendering booleans as strings. Self-check: values true/false should be unquoted unless you intentionally want strings.

Learning path

  1. Containers basics → build and tag images.
  2. Kubernetes basics → deployments, services, namespaces.
  3. Helm Basics (this lesson) → charts, values, install/upgrade/rollback.
  4. Next: Advanced templating, chart testing, dependency management, and GitOps with Helm.

Practical projects

  • Create: A reusable Helm chart for a stateless web service with configurable image, replicas, resources, probes, and optional ingress.
  • Environment overlays: Use base values.yaml plus values-dev.yaml and values-prod.yaml; demonstrate upgrades across environments.
  • Migrate: Replace raw manifests of a small service with a Helm chart; document upgrade/rollback steps.

Next steps

  • Learn chart dependencies and requirements.
  • Use advanced templates: pipelines, include, tpl, required, default.
  • Adopt GitOps with a tool that syncs Helm releases from Git.
  • Add chart tests and CI linting.

Mini challenge

Add optional ingress to your chart:

  • values.yaml should have ingress.enabled, className, host, and path fields.
  • templates/ingress.yaml should render only when ingress.enabled is true.
  • Acceptance: helm template shows Ingress when enabled and not otherwise; kubectl apply of rendered output passes server-side validation.
Hint for mini challenge 
{{- if .Values.ingress.enabled }}
# ingress manifest here
{{- end }}

Quick Test note: The test is available to everyone. Log in to save your progress and resume anytime.

Practice Exercises

3 exercises to complete

Instructions

  1. Add the Bitnami repo and refresh cache:
    helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
  2. Install NGINX as release web in namespace demo (create if needed):
    helm install web bitnami/nginx --namespace demo --create-namespace
  3. Verify the release and resources:
    helm list -n demo
kubectl get deploy,svc -n demo
Expected Output
helm list -n demo NAME NAMESPACE REVISION UPDATED STATUS CHART APP_VERSION web demo 1 ... deployed nginx-... ... kubectl get deploy,svc -n demo NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/web... 1/1 1 1 ... NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/web... ClusterIP 10.x.x.x <none> 80/TCP ...

Helm Basics — Quick Test

Test your knowledge with 10 questions. Pass with 70% or higher.

10 questions70% to pass
Resource Requests Limits AutoscalingCluster Upgrades And Maintenance

Have questions about Helm Basics?

AI Assistant

Ask questions about this tool