Free — no signup required

How Helm Works: The Templating Engine

2 min read

Mad Libs for Kubernetes

How does Helm turn a generic blueprint into specific YAML? It uses a templating engine based on Go's text/template package, extended with a library of helper functions called Sprig.

Inside a Helm Chart, the YAML files in the templates/ directory don't have hardcoded values. Instead, they have placeholders wrapped in double curly braces. Here's what a real template snippet looks like:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-webserver
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          resources:
            limits:
              memory: {{ .Values.resources.limits.memory }}

And the corresponding values.yaml:

replicaCount: 3

image:
  repository: nginx
  tag: "1.25.0"

resources:
  limits:
    memory: 256Mi

When you run helm install, Helm executes this process:
1. Load the template files from the Chart.
2. Read configuration from values.yaml and any override files or --set flags you provide.
3. Render the templates by substituting all {{ ... }} placeholders with real values. This produces pure, valid Kubernetes YAML.
4. Apply the rendered manifests to the Kubernetes API Server.

You can inspect the rendered output without actually deploying anything by asking Helm to render the templates locally instead of installing them. This is invaluable for debugging — you can see exactly what YAML Helm would send to Kubernetes before committing to a deployment.

Helm v3 vs. v2: The Tiller Removal

Helm v2 required a server-side component called Tiller running inside the cluster, which had broad permissions and created significant security concerns. Helm v3 (released 2019) eliminated Tiller entirely. Modern Helm is a pure client-side tool — it runs on your machine and communicates directly with the Kubernetes API Server using your existing kubectl credentials and RBAC permissions. This means Helm's permissions are exactly your permissions, no more and no less.

Interview Tip

Interviewers frequently ask: "What's the difference between Helm v2 and v3?" The answer they're looking for is the removal of Tiller. In v2, Tiller ran as a Pod with cluster-admin privileges, making it a security liability. In v3, Helm uses the caller's kubeconfig credentials directly, so access control is handled entirely by Kubernetes RBAC. A follow-up question is often: "Where does Helm v3 store release state?" — the answer is as Kubernetes Secrets in the release's namespace.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free