learninfra · Linux · Networking · Kubernetes · System Design · AI Infrastructure · Exam blueprints · Drills

Helm & Kustomize (CKAD)

Install, upgrade and roll back packaged apps with Helm; adapt plain YAML per environment with Kustomize.

An interactive Kubernetes lesson: 24 steps, about 35 minutes, on a live simulation in your browser.

The shop's storefront is three objects: a Deployment, a Service and a ConfigMap. You need it in staging and in production. The two are almost identical: replica count, image tag and Service type differ.

The obvious approach is a folder of YAML per environment. The diff in the terminal shows what that turns into: two copies that must be kept in step by hand, where every fix is made twice and sooner or later only once.

What you will learn

  1. Charts and repositories

    • The same YAML, copied and edited: Helm fills in templates and tracks releases. Kustomize patches plain YAML and tracks nothing.
    • Find a chart in a repository: A chart is a versioned package of templates. A repo is a catalogue of charts. helm repo update refreshes your copy of the catalogue.
    • Read the chart's values first: values.yaml is the chart's public interface: the full list of knobs and their defaults.

  2. A release

    • helm install: a chart becomes a release: A release is one installed copy of a chart: chart + your values + a name. Same chart, different name, separate release.
    • Where does Helm remember this?: Helm's memory is a Secret per revision, in the release's namespace: sh.helm.release.v1.<release>.v<revision>.

  3. Upgrade, break, roll back

    • Break it: the upgrade that forgot
    • One values file, passed every time: An upgrade is rendered from chart defaults plus what you pass now. The values file is the source of truth, not the last command.
    • Break it: deployed, and not working: helm upgrade succeeds when the API accepts the YAML. Whether the pods come up is a separate question unless you pass --wait.
    • helm history and helm rollback
    • helm template: look before you apply: A chart is a function: values in, manifests out. helm template runs the function and stops there.

  4. Cluster components

    • Install a cluster component with Helm
    • Where did the release go?: Every helm command is scoped to one namespace, like kubectl. No -n means the current namespace, not all of them.
    • A second release, then helm uninstall

  5. Kustomize: patch, don't template

    • Kustomize: start from plain YAML: A kustomization.yaml lists resources and the changes to lay over them. The source files are never edited; the output is new YAML.
    • An overlay: the base, plus changes: An overlay is a base plus a short list of differences. One base, one small overlay per environment.
    • Production: images, replicas, patches
    • configMapGenerator: config from a list
    • Change a generated ConfigMap: A generated ConfigMap is named after its contents. Change the contents and the name changes, and every Deployment that uses it rolls.
    • Patching software you did not write: Never edit a vendor manifest. Keep it untouched as a resource and keep your differences as patches next to it.

  6. Choosing, and exam speed

    • Which tool, when: Helm for packages you consume. Kustomize for YAML you own. Helm remembers releases; Kustomize leaves history to Git.
    • Drill: install a chart into a namespace
    • Drill: apply an overlay

  7. Recap & playground

    • Cheat sheet
    • Playground