Package Kubernetes apps instead of copying YAML

Agenda

By the end, learners should be able to

• Explain why Helm is better than hand-editing YAML for repeatable installs
• Read a chart directory and identify the role of each file
• Parameterize manifests with values.yaml and templates
• Install, upgrade, rollback, and inspect releases safely
• Package and publish charts through repositories

What Helm does

• Bundles Kubernetes manifests into a versioned chart
• Turns static YAML into parameterized templates
• Installs and tracks a release as one logical unit
• Makes upgrade and rollback operationally simpler

Why teams use it

• One install command instead of copying many files
• Environment-specific values without editing templates
• Versioned application packaging like software artifacts
• Shared distribution through chart repositories

helm install my-release bitnami/postgresql
helm upgrade my-release ./my-chart
helm rollback my-release 1

my-chart/
  Chart.yaml
  values.yaml
  charts/
  templates/
    deployment.yaml
    service.yaml
    _helpers.tpl

Key files

• Chart.yaml: name, version, description, dependencies
• values.yaml: default configuration for templates
• templates/: Kubernetes YAML with Go template syntax
• _helpers.tpl: reusable template fragments and naming helpers
• charts/: packaged sub-charts and dependencies

metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
spec:
  replicas: {{ .Values.replicaCount }}

Template objects to know

• .Release: release-specific data like name and namespace
• .Chart: metadata from Chart.yaml
• .Values: merged values supplied to the chart
• include, default, quote, required: common template helpers

Override order

• 1. Chart default values.yaml
• 2. Parent chart values
• 3. User-supplied --values custom-values.yaml
• 4. Individual --set key=value flags

helm install web ./web-chart \
  --values prod-values.yaml \
  --set image.tag=1.2.4

Later sources override earlier ones. Treat --set as the highest-priority emergency override, not your main configuration strategy.

Release lifecycle

• helm install: creates a new release
• helm upgrade: updates an existing release
• helm history: shows release revisions
• helm rollback: reverts to a prior revision

helm list
helm status my-release
helm history my-release
helm rollback my-release 1

What a repository contains

• Packaged chart archives such as .tgz files
• An index.yaml file that maps chart names to versions
• A predictable source for installation, upgrade, and dependency resolution
• A shared distribution point for internal or public charts

Repository workflow

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo nginx
helm show values bitnami/nginx
helm package ./my-chart

Apply order

helm version
helm create web-chart
helm lint ./web-chart
helm template demo ./web-chart
helm install demo ./web-chart
helm upgrade demo ./web-chart --set image.tag=v2

# macOS
brew install helm

# Windows
choco install kubernetes-helm

# Linux
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

helm version

What to notice

• Install Helm before starting the chart workflow
• helm version confirms the CLI is available locally
• Package manager install is fine for the lab; teams can standardize later

helm create web-chart
cd web-chart
ls

Chart.yaml
values.yaml
templates/

What to notice

• helm create gives you a working starting point, not a final chart
• Generated templates are useful for learning, but usually need cleanup
• Start by understanding the directory, then simplify it

# Chart.yaml
apiVersion: v2
name: web-chart
version: 0.1.0
appVersion: "1.0.0"
description: Demo Helm chart for a web app

# values.yaml
replicaCount: 2
image:
  repository: nginx
  tag: "1.27"
service:
  type: ClusterIP
  port: 80

What to notice

• version is the chart version; appVersion is the app version
• values.yaml becomes the contract between chart and operator
• Keep values predictable and flat enough to override safely

# templates/deployment.yaml
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: web
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

# templates/service.yaml
spec:
  type: {{ .Values.service.type }}
  ports:
  - port: {{ .Values.service.port }}

What to notice

• Release name prevents collisions between installs
• Templates should read from values, not hardcode environment choices
• One chart can now render different outputs with different values files

helm lint ./web-chart
helm template demo ./web-chart
helm install demo ./web-chart
helm upgrade demo ./web-chart --set image.tag=1.27.1
helm history demo
helm rollback demo 1

What to notice

• helm lint validates structure and catches common mistakes early
• helm template shows rendered YAML before touching the cluster
• helm history and helm rollback make change tracking operationally safer