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.
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.