Video summary

Как устроен Helm

Main summary

Key takeaways

Technology

Helm and the “missing application layer”

Helm is introduced as the missing “layer” that understands Kubernetes objects belong to one application. Kubernetes itself has no concept of an “application” (it only knows independent objects).

Why Helm is needed (problems without it)

For the simplest “app + DB” deployment, Kubernetes ends up with ~7 separate objects (e.g., Deployment, Service, ConfigMap, Secret, optional HPA, ServiceAccount, etc.). However, the relationship between them exists only in the developer’s head / filesystem.

This leads to:

  1. Environment drift Multiple environments (dev/stage/prod) require copying/manually maintaining similar manifest sets. Small changes don’t consistently propagate across environments.

  2. No true app-level lifecycle There’s no single “update application” / “delete application” operation—only apply/delete specific objects. If you delete part of an app (e.g., forget a ConfigMap), leftovers remain in the cluster.

  3. Copy-paste complexity from “foreign software” Installing third-party components often means copying many manifests without knowing whether anything was missed or correctly applied.

Helm addresses all three via release management (not just templating).

What Helm does (3 main tasks)

Helm performs:

  1. Templating Use one chart template instead of duplicating manifests across environments. Substitute variables (e.g., replicas, image tag, domain, resource limits).

  2. Package manager Install charts from a registry with one command—similar in spirit to Linux package installs.

  3. Release manager (core feature) Track installed instances as releases with:

    • release name
    • revision number
    • revision history

Helm then lets you update, rollback, or uninstall the whole set of objects as one unit.

Key terms

  • Chart: a directory with a predictable structure:

    • Chart.yaml (name/version info)
    • values.yaml (default values)
    • templates/ (manifest templates)
    • charts/ (dependencies)
    • crds/ (CRDs; mentioned for later return)

  • Values: environment-specific parameter files that control template substitutions (e.g., replicas, image tag, domain). Multiple values files can be used with one chart.

  • Release: what is installed and running in the cluster under a specific name. A single chart can be installed multiple times, producing multiple independent releases.

  • Revision: the version number of a release over time. The 1st install is revision 1; upgrades create revision 2, then 3, etc.

Helm architecture / where components live

  • Helm itself is a client-side executable (like a local binary used in your terminal or CI runner).
  • It is not installed inside the Kubernetes cluster; the cluster doesn’t have Helm server/agent components.
  • It behaves similarly to kubectl: reads kubeconfig/access, calls the Kubernetes API server with your permissions. If you lack permissions, Helm cannot create the resources.

Important historical security point

  • Helm v2 used Tiller in-cluster; it had broad rights—reaching Tillers effectively meant controlling the cluster.
  • Helm v3 removed Tiller; the client talks directly to the Kubernetes API server, improving security.

How installation works (helm install)

When running helm install:

  1. Helm assembles the chart and pulls dependencies.
  2. Substitutes values into templates to render standard Kubernetes manifests.
  3. Sends the manifests to the cluster.
  4. Records what was installed in the cluster, not only locally.

Where Helm stores release state

  • Helm stores release info as a Kubernetes Secret (one per revision).
  • The secret contains:
    • the chart values (noted as being present in plaintext)
    • a rendered manifest snapshot (compressed/encoded)

Because this data is stored in-cluster, the release list is consistent for all cluster users.

Rollback behavior (and common misconception)

Helm rollback is not a “time machine” for the entire system:

  • It returns the previous manifest values (e.g., image tag, replicas, settings).
  • It does not revert database changes.
  • It does not undo already-applied migrations.
  • It does not restore deleted runtime resources (e.g., volumes) that changed outside manifests.

Also:

  • Rollback does not overwrite revisions in-place. It creates a new revision that repeats the old one, so revision history grows.

Journal size pitfall

The “journal” of revisions is finite (bounded by cluster/storage limits/settings). If you repeatedly roll forward with bad releases and then rollback, you can fill history with faulty revisions and hit the limit, causing future operations to fail.

Template value resolution order

Values come from multiple sources with increasing priority:

  1. chart default values (values.yaml)
  2. a values file provided with -f/--values
  3. values set directly on the command line

Later sources override earlier ones.

Chart sources / registries

  • Charts can be installed from a local directory.
  • For others, Helm pulls charts by name/version from a chart registry/repository (often a registry that stores chart packages alongside container images and other artifacts).

Speaker / sources

  • Main speaker/source: “Simply Devops” YouTube channel narrator/host (the video’s presenter)
  • No specific individual is named in the subtitles; the source is the channel (“Simply Devops”) throughout.

Original video