Lab 20 - Helm releases

Goal: install, configure, upgrade and roll back somebody else’s chart. Chapter: Helm basics

Helm should already be installed from Lab 14. If not:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod +x get_helm.sh && sudo ./get_helm.sh && helm version

# 1 - a repository
helm repo add podinfo https://stefanprodan.github.io/podinfo
helm repo update
helm repo list
helm search repo podinfo
helm search repo podinfo --versions | head -5

A repository is just a web server with an index.yaml. helm repo update refetches that index - Helm does not go online for anything else until you install.

# 2 - ALWAYS look before you install
helm show chart podinfo/podinfo | head -15
helm show values podinfo/podinfo | head -30

show values is the chart’s public interface. If a setting is not in there, the chart does not support it, and --set will silently do nothing.

# 3 - render without touching the cluster
helm template web podinfo/podinfo | head -40
helm template web podinfo/podinfo | grep -c '^kind:'

That is how many objects one helm install would create. Rendering locally needs no cluster and no permissions - it is the safest way to review a chart.

# 4 - server-side dry run: same, but the API server validates it
helm install web podinfo/podinfo --dry-run --debug > /tmp/dryrun.yaml
head -30 /tmp/dryrun.yaml

# 5 - install for real
helm install web podinfo/podinfo --set replicaCount=2 -n helmlab --create-namespace
helm list -n helmlab
kubectl get all -n helmlab

Everything in that namespace was created by the chart. Helm did not do anything kubectl could not - it rendered YAML and applied it - but it did it consistently and it remembers what it did.

# 6 - what does Helm think it deployed?
helm get values web -n helmlab           # only what you overrode
helm get manifest web -n helmlab | grep -E '^(kind|  name):'
helm status web -n helmlab

# 7 - one chart, many releases
helm install web2 podinfo/podinfo -n helmlab
helm list -n helmlab
kubectl get deploy -n helmlab
helm uninstall web2 -n helmlab

Two independent installations of the same chart, told apart by release name. Every object the chart creates is named after the release, which is why this works.

Upgrade and roll back

# 8 - change a value -> a new revision
helm upgrade web podinfo/podinfo --set replicaCount=4 -n helmlab
helm history web -n helmlab
kubectl get deploy -n helmlab

# 9 - values from a file (better than a long --set)
cat > ~/podinfo-values.yaml <<'YAML'
replicaCount: 3
service:
  type: NodePort
  nodePort: 30090
YAML
helm upgrade web podinfo/podinfo -f ~/podinfo-values.yaml -n helmlab
kubectl get svc -n helmlab
curl -s http://worker01:30090 | head -5

A values file belongs in Git next to your code. --set is for one-offs and secrets you do not want in a file.

# 10 - roll back
helm history web -n helmlab
helm rollback web 1 -n helmlab
helm history web -n helmlab
kubectl get deploy -n helmlab

Note that the rollback is itself a new revision. Helm never rewrites history - it appends, which is why helm history is trustworthy during an incident.

Clean up

helm uninstall web -n helmlab
kubectl delete ns helmlab

Tip

In a pipeline use helm upgrade --install <release> <chart> -f values.yaml. It works the first time and every time after.