All modules in this track (20)
In this module, you'll learn to:
- Keep one app's manifests consistent across environments with Kustomize overlays
- Install, configure, upgrade, and roll back packaged software with Helm
- Decide which tool fits which job
Before you start: this builds on the declarative kubectl apply workflow from Reading Kubernetes YAML. Have the kind cluster running, and install Helm (brew install helm, winget install Helm.Helm, or the script on helm.sh).
One app, many environments, no copy-paste
So far each app has been a few YAML files. Two problems show up quickly in real work:
- Environments differ a little. Dev runs one replica, Production runs four; the image tag, namespace, and resource sizes change. Copying the whole folder per environment works until someone fixes a bug in one copy and forgets the others.
- Other people's software comes as a bundle. An ingress controller or a monitoring stack is dozens of objects with hundreds of settings. You want to install a version, change a few settings, and upgrade it later, without editing their YAML.
Kustomize solves the first problem. Helm solves both, in a different way. You'll meet each of them throughout the rest of this track.
A shared base, plus small patches per environment
Kustomize is built into kubectl. You keep one base with the full manifests, and an overlay per environment that lists only what's different. There's no templating language: every file stays valid Kubernetes YAML.
hello/
├── base/
│ ├── deployment.yaml # the Deployment from module 03
│ ├── service.yaml
│ └── kustomization.yaml
└── overlays/
├── dev/
│ └── kustomization.yaml
└── prod/
└── kustomization.yaml# base/kustomization.yaml: which files make up the app
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml# overlays/prod/kustomization.yaml: only what's different in Production
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
namespace: shop-prod
images:
- name: nginx
newTag: "1.27.2" # pin an exact version in Production
patches:
- target:
kind: Deployment
name: hello
patch: |-
- op: replace
path: /spec/replicas
value: 4# overlays/dev/kustomization.yaml: the base as it is, in its own namespace
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
namespace: shop-dev# Print the final YAML for an environment, without applying it
kubectl kustomize overlays/prod
# Apply an environment (-k instead of -f)
kubectl create namespace shop-prod
kubectl apply -k overlays/prodA package manager for Kubernetes
Helm works like a package manager (apt, brew, npm) for Kubernetes. A chart is a package: a folder of templated manifests plus a values.yaml file of settings with sensible defaults. Installing a chart creates a release, which Helm tracks so you can upgrade it, roll it back, or uninstall it as one unit.
# Inside a chart: templates/deployment.yaml (an excerpt)
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"# my-values.yaml: your settings, overriding the chart's defaults
replicaCount: 2# Add a chart repository and look at what it offers
helm repo add podinfo https://stefanprodan.github.io/podinfo
helm repo update
helm search repo podinfo --versions | head
# See every setting the chart supports
helm show values podinfo/podinfo
# Install a specific version, with your values
helm install my-podinfo podinfo/podinfo --version <chart-version> -f my-values.yaml
# Change a setting, see the release history, roll back, and uninstall
helm upgrade my-podinfo podinfo/podinfo --version <chart-version> --set replicaCount=3
helm history my-podinfo
helm rollback my-podinfo 1
helm uninstall my-podinfo
# Render the YAML without installing, to review what a chart will create
helm template my-podinfo podinfo/podinfo -f my-values.yamlHelm, Kustomize, or both
| Kustomize | Helm | |
|---|---|---|
| How it works | Patches plain YAML | Fills in templates from values |
| Installed with | Built into kubectl | A separate CLI |
| Best for | Your own apps across environments | Installing and upgrading third-party software |
| Tracks releases and rollbacks | No; Git history does that | Yes, per release |
| Learning curve | Low: it's still just YAML | Higher: Go templating for chart authors |
A common split, and the one used later in this track: Helm for third-party add-ons (load balancer controller, ExternalDNS, metrics) in The Platform Add-on Layer, and Kustomize overlays (or Helm values files) for your own apps, applied by Argo CD in GitOps with Argo CD. Argo CD understands both natively.
One app, two environments
# Build the hello/ folder above, reusing deployment.yaml and service.yaml
# from module 03, then compare the two environments
kubectl kustomize hello/overlays/dev
kubectl kustomize hello/overlays/prod
# Apply both side by side on kind
kubectl create namespace shop-dev
kubectl create namespace shop-prod
kubectl apply -k hello/overlays/dev
kubectl apply -k hello/overlays/prod
kubectl get deployments -A -l app=hello
# Clean up
kubectl delete -k hello/overlays/dev
kubectl delete -k hello/overlays/prodImplementation notes
- Always pin chart versions.
helm installwithout--versioninstalls whatever is newest today, so two environments installed a week apart can differ. The same lesson appears in The Platform Add-on Layer. - Keep your values files in Git.
--seton the command line is fine in a lab, but the settings then exist only in Helm's release history. - Review what a chart creates before installing it.
helm templateshows every object, including cluster-wide roles and permissions some charts ask for. - Don't mix tools on the same objects. If Helm installed something, change it with Helm. A
kubectl editon a Helm-managed object isn't in the chart or the values, so nobody can see it was made, and a later upgrade or rollback may silently overwrite it.
Key terms
- Kustomize: builds per-environment YAML from a shared base plus patches; built into kubectl.
- Base and overlay: the shared manifests, and one environment's differences from them.
- Helm chart: a package of templated manifests with default settings.
- Values: the settings you pass to a chart to override its defaults.
- Release: one installed copy of a chart, with a revision history you can roll back.
Pop quiz
Five questions: three on the ideas in this module, and two scenarios where you apply them. The order changes every time you take it, and 4 out of 5 passes.
5 questions. Decide on your answer to each, then check it.
-
Scenario
Dev and Production differ only in replica count, namespace, and image tag. What's the Kustomize way to handle that?
Show answer
One base, plus a small overlay per environment listing only those differences
Overlays keep the shared manifests in one place, so a fix in the base reaches every environment, and each overlay stays a small, readable diff.
-
Concept
What does
helm installwithout--versioninstall?Show answer
Whatever the newest chart version is right now
Without
--versionyou get today's newest chart, so two environments installed a week apart can differ. Always pin chart versions. -
Concept
Before installing a chart, you want to see every object it will create, including cluster-wide permissions. Which command?
Show answer
helm templatehelm templaterenders the chart to plain YAML without touching the cluster, so you can review it first. -
Scenario
Someone fixes a Helm-managed Deployment with
kubectl editduring an incident. What's the problem with leaving it that way?Show answer
The fix isn't in the chart or values, so it's invisible, and a later upgrade or rollback may overwrite it
Helm merges each upgrade with the live state, so an edit can survive one upgrade and be lost on the next, or on a rollback. Put the fix into the values file, so it's recorded and reviewed.
-
Concept
Which split does this track use?
Show answer
Helm for third-party add-ons; overlays or values files for your own apps
Helm is good at installing and upgrading other people's software. Your own apps fit Kustomize overlays or per-environment Helm values, applied by Argo CD.