213 Helm Interview Questions and Answers (2026)

Helm is the package manager for Kubernetes: it bundles a set of related Kubernetes manifests into a versioned, parameterized unit called a chart, so you can install, upgrade, and roll back an application as a single named release.

• The problem it solves:

  • Real apps need many objects (Deployment, Service, ConfigMap, Ingress) that must be kept consistent across environments.

  • Raw YAML means copy-pasting and hand-editing per environment, which is error-prone and hard to version.

• What Helm provides:

  • Templating: one chart parameterized by values.yaml produces per-environment manifests.

  • Lifecycle management: helm install, helm upgrade, helm rollback, helm uninstall as atomic operations.

  • Distribution: charts are packaged and shared through repositories, like OS packages.

Helm replaces piles of static, per-environment YAML with a single templated, versioned package that you configure through values, letting you deploy the same app to dev, staging, and prod by changing inputs instead of duplicating files.

• Parameterization instead of duplication: One templated chart plus a values.yaml per environment replaces N copies of manifests.

• Single-command lifecycle: One helm upgrade applies all changed objects together; kubectl apply over many files has no unified release concept.

• Release tracking and rollback: Helm stores each revision, so helm rollback reverts to a known-good state instantly.

• Dependency management: Subcharts pull in dependencies (a database, cache) declared in Chart.yaml, avoiding manual assembly.

• Reuse and sharing: Community charts let you deploy complex software without authoring the YAML yourself.

A Helm chart is a directory (or packaged archive) with a defined structure that bundles templates, default configuration, and metadata into an installable Kubernetes application.

• Chart.yaml: Metadata: chart name, version, appVersion, and declared dependencies.

• values.yaml: Default configuration values that templates reference; overridden at install with --set or -f.

• templates/:

  • Go-templated manifests rendered into real Kubernetes objects.

  • Includes _helpers.tpl for reusable named template snippets.

• charts/: Subcharts (dependencies) vendored or fetched into this directory.

• Supporting files: templates/NOTES.txt (post-install message) and Chart.lock for pinned dependency versions.

A Helm release is a specific installed instance of a chart running in a cluster, identified by a name and tracked with a revision history so it can be upgraded and rolled back independently.

• Instance, not just the chart: Installing the same chart twice with different names yields two independent releases.

• Revisioned state: Each install or upgrade creates a new revision, enabling helm rollback to a prior one.

• Where state lives: Release metadata is stored as Kubernetes Secret objects (by default) in the release's namespace.

• Inspecting it: helm list, helm status, and helm history show current and past state.

Helm is called Kubernetes' package manager because it does for cluster applications what apt or yum do for an OS: it packages software into versioned, distributable units and manages their full install/upgrade/remove lifecycle.

• Packages: A chart is the equivalent of a .deb or .rpm: a self-contained, versioned bundle.

• Repositories: Charts are hosted and pulled from repos (helm repo add), mirroring package registries.

• Dependencies: Charts declare and resolve subchart dependencies, like packages depend on libraries.

• Lifecycle commands: install/upgrade/uninstall parallel package-manager verbs, with versioning and rollback on top.

Helm's core benefits are consistency, repeatability, and safe lifecycle management: it turns a complex application into one reusable package you can deploy, version, and revert predictably across environments.

• Reusable, configurable packages: One chart serves many environments through values overrides.

• Safe upgrades and rollbacks: Revision history means a bad helm upgrade is undone with helm rollback.

• Consistency and DRY: Templates and helpers eliminate copy-pasted manifests and drift between environments.

• Dependency management: Subcharts compose multi-component systems into one deployable unit.

• Ecosystem and automation: Large catalog of community charts, plus hooks and CI/CD integration for automated deploys.

Helm renders manifests using the Go template engine: files in templates/ contain placeholders that pull values from values.yaml and built-in objects, and Helm substitutes them at install/upgrade time to produce final Kubernetes YAML.

• Value injection: {{ .Values.x }} reads from values.yaml, overridable with --set or a custom -f file.yaml.

• Built-in objects: .Release, .Chart, and .Capabilities expose release name, chart metadata, and cluster info.

• Logic and functions: Conditionals (if), loops (range), and pipeline functions (default, quote, toYaml) shape output.

• Reuse: Named templates in _helpers.tpl are pulled in with include.

• Preview before applying: helm template or --dry-run renders the YAML without touching the cluster.

A chart is the packaged template (the blueprint); a release is a specific installed instance of that chart running in a cluster.

• Chart: the reusable package:

  • A directory/archive of templates, default values (values.yaml), and metadata (Chart.yaml).

  • Static and versioned: one chart can be installed many times.

• Release: an installed instance:

  • Created when you run helm install <name> <chart> with a chosen name and values.

  • Helm tracks its state and revision history, enabling helm upgrade and helm rollback.

• Analogy: chart is like a class/image, release is like an object/running container.

Charts package the app, repositories distribute those charts, and releases are the running installations Helm manages in the cluster.

• Chart: A bundle of Kubernetes manifest templates plus defaults and metadata that defines an application.

• Repository:

  • An HTTP server (or OCI registry) hosting packaged charts and an index.yaml, so charts can be shared and pulled by version.

  • Added via helm repo add.

• Release: A named, versioned instance of a chart deployed to a cluster, with tracked revision history.

Both ultimately apply manifests, but Helm adds templating, packaging, release tracking, and rollback, whereas raw kubectl apply is unmanaged static YAML.

• Templating and reuse: Helm parameterizes YAML with values.yaml, so one chart serves dev/staging/prod; raw YAML duplicates files per environment.

• Lifecycle management: Helm tracks release revisions and offers helm rollback; with kubectl you manually revert files.

• Grouping and cleanup: A release groups all resources; helm uninstall removes them cleanly, unlike hunting individual objects.

• Cost/tradeoff: Raw YAML is simpler and fully transparent for tiny/static setups; Helm adds a learning curve and templating complexity.

Helm is a templating package manager with a values-driven engine and release lifecycle; Kustomize is a template-free tool that overlays and patches plain YAML declaratively.

• Approach:

  • Helm uses Go templates and values.yaml to render manifests.

  • Kustomize keeps valid YAML as a base and applies overlays/patches per environment: no templating language.

• Packaging and lifecycle:

  • Helm packages, versions, and tracks releases with install/upgrade/rollback.

  • Kustomize just produces manifests (kubectl apply -k); no release concept.

• Tradeoffs:

  • Helm is powerful for redistributable, parameterized apps but templates can get complex.

  • Kustomize is simpler and native (built into kubectl) but lacks packaging/distribution and dynamic logic.

• They can combine: render a Helm chart, then post-process with Kustomize.

Helm charts turn a collection of Kubernetes manifests into a reusable, versioned, configurable package, giving you simplified deploys, controlled upgrades/rollbacks, and environment-specific configuration from a single source.

• Simplified deployments:

  • One command (helm install) deploys many related resources as a single release.

  • Dependencies (subcharts) are pulled and installed together.

• Version control:

  • Charts carry a semantic version and appVersion in Chart.yaml.

  • Each release keeps a revision history, so helm rollback restores a prior state.

• Configuration management:

  • Defaults live in values.yaml and are overridden per environment with -f or --set.

  • Templates plus values keep one chart serving dev/staging/prod.

• Packaging and sharing: Charts bundle into archives published to repositories for reuse across teams.

• Templating logic: Go template functions, conditionals, and helpers (_helpers.tpl) reduce duplication and enforce consistency.

Helm is a package manager for Kubernetes: it renders parameterized templates into Kubernetes manifests, then applies them to the cluster as a versioned unit called a release.

• Charts are the package: A chart bundles templated manifests plus a values.yaml of defaults and a Chart.yaml of metadata.

• Templating and rendering:

  • Go templates in templates/ are merged with values to produce final YAML.

  • You override defaults with --set or -f myvalues.yaml.

• Client-side rendering (Helm 3): The Helm CLI renders locally and talks to the Kubernetes API directly (no Tiller), using your kubeconfig and RBAC.

• Releases and lifecycle: Each helm install creates a release; helm upgrade, helm rollback, and helm uninstall manage versions over time.

They operate at different layers: Docker packages a single application into an image, Kubernetes runs and orchestrates those images, and Helm packages the Kubernetes resources needed to deploy them into one reusable, versioned chart.

• Docker: the container: Builds an image containing your app and its runtime; Helm charts reference these images (e.g. in a Deployment's image: field).

• Kubernetes: the platform: Runs containers via objects like Deployments, Services, and ConfigMaps; Helm ultimately produces these objects.

• Helm: the packaging layer: Templates and bundles many Kubernetes manifests so an entire app (image tags, replicas, config) is installed and upgraded as one unit.

• Flow: Docker build image, push to registry, Helm chart references it, Helm applies manifests to Kubernetes.

Helm was created by Deis in 2015 and first shown at the inaugural KubeCon; it later merged with Google's Kubernetes Deployment Manager work and became a CNCF project.

• Origin: Started at Deis (engineers including Matt Butcher) as a package manager for Kubernetes.

• Helm 2: Co-developed after merging Deis's Helm with Google's Deployment Manager; introduced the server-side Tiller component.

• Governance today: Helm is a graduated CNCF project maintained by an open community, with Helm 3 removing Tiller.

Helm is a client that speaks to the same Kubernetes API as kubectl, reusing your kubeconfig, context, and RBAC; it complements kubectl by managing whole releases rather than individual manifests.

• Shared access path: Helm reads the same KUBECONFIG/current-context as kubectl, so RBAC permissions apply identically.

• Different level of abstraction: kubectl applies raw manifests; Helm templates, versions, and tracks them as releases.

• Interop patterns:

  • helm template renders YAML you can pipe into kubectl apply.

  • After a Helm install you inspect the results with kubectl get/describe.

  • Plays alongside GitOps tools (Argo CD, Flux) and Kustomize, which can render Helm charts too.

• Caution: Editing Helm-managed objects directly with kubectl edit causes drift from Helm's recorded state.

Helm charts follow well-established conventions for structure, naming, and templating so charts are predictable, composable, and safe to upgrade.

• Standard layout: Chart.yaml (metadata), values.yaml (defaults), templates/, charts/ (subcharts), and _helpers.tpl for named templates.

• Naming and labels: Prefix resource names with the release via fullname helpers and apply recommended labels like app.kubernetes.io/name and managed-by.

• Values style: Use camelCase keys, document every value, and provide safe defaults.

• Versioning: version tracks the chart (SemVer) while appVersion tracks the packaged app.

• Quality practices: Run helm lint, quote strings and use | nindent for indentation, and ship a NOTES.txt for post-install guidance.

A Helm chart is a directory whose files separate metadata, default configuration, and templated manifests, so Helm can render and package it into a reusable unit.

• Chart.yaml: Required metadata: chart name, version, appVersion, and declared dependencies.

• values.yaml: Default configuration values, overridable at install with -f or --set.

• templates/: Go-templated manifests (Deployments, Services, etc.) rendered against the merged values.

• charts/: Subchart dependencies, either vendored here or pulled in via helm dependency update.

• templates/_helpers.tpl: Reusable named template snippets (e.g. label/name helpers) referenced via include; not rendered as a manifest itself.

• templates/NOTES.txt: Templated usage notes printed to the user after helm install.

• Also common: .helmignore (exclude files from packaging) and crds/ for CustomResourceDefinitions.

helm package bundles a chart directory into a versioned, compressed .tgz archive that can be shared or served from a chart repository.

• What it produces: A file named <name>-<version>.tgz using the name and version from Chart.yaml.

• Common flags:

  • --version and --app-version override chart/app versions at package time.

  • --dependency-update refreshes subcharts before packaging.

  • --sign with a key creates a provenance file for verification.

• Where it fits: Package, then run helm repo index and host the .tgz so others can helm install from the repo.

The _helpers.tpl file holds reusable named template definitions (partials) that you reference across the chart's manifests, keeping templates DRY and consistent.

• Defines named templates: Uses {{- define "chart.name" -}} blocks that you call with include or template.

• Naming convention: The leading underscore tells Helm not to render it as a Kubernetes manifest; .tpl files are template-only helpers.

• Common uses: Generating fully-qualified names, standard labels, and selector labels reused by every resource.

• Prefer include over template: include returns a string you can pipe (e.g. to nindent), which template cannot.

The .helmignore file lists patterns of files and directories to exclude when packaging a chart, similar to .gitignore, keeping the final .tgz clean and free of secrets.

• Applies at packaging time: Used by helm package (and packaging during install from a directory) to decide what to bundle.

• Pattern syntax: Supports glob patterns, comments with #, and one pattern per line.

• Why it matters: Prevents shipping .git, CI files, editor backups, tests, or secrets, reducing chart size and leakage risk.

version is the version of the chart itself, while appVersion is the version of the application the chart deploys: they change independently.

• version:

  • Must be SemVer and is bumped whenever the chart changes (templates, defaults, dependencies), even if the app is unchanged.

  • Used by Helm to track and select chart releases in a repository.

• appVersion:

  • A free-form label (often a container image tag like 1.20.0) describing the packaged software.

  • Informational only: it does not drive chart resolution.

• Why separate: You can release chart fixes (e.g. 1.2.3 to 1.2.4) without changing the app version, and vice versa.

helm create scaffolds a new chart directory with a standard, working boilerplate structure you then customize, so you don't build a chart from scratch.

• Generates the standard layout: Creates Chart.yaml, values.yaml, a templates/ directory, and charts/.

• Includes working examples: Ships a sample Deployment, Service, Ingress, ServiceAccount, plus _helpers.tpl, NOTES.txt, and a test.

• Immediately renderable: The generated chart installs as-is (a demo NGINX-style app), giving a valid starting point.

• Usage: Run helm create mychart, then edit the templates and values to fit your app.

Chart.yaml is the required metadata file at a chart's root: it declares what the chart is, its versions, dependencies, and descriptive info that Helm uses for packaging and discovery.

• Identity fields: apiVersion (v2 for Helm 3), name, and a description.

• Version fields: version: the chart's own SemVer, and appVersion: the version of the app being deployed.

• Dependencies: A dependencies list of subcharts (name, version, repository, condition, alias).

• Optional metadata: type (application/library), keywords, maintainers, home, sources, icon, and kubeVersion constraints.

NOTES.txt is a template that renders human-readable usage instructions printed after helm install or helm upgrade: it tells the user how to access or verify the release.

• It is a Go template: Has access to the same values and objects (.Values, .Release) as other templates.

• Output only, not applied: It is printed to the console, never sent to Kubernetes as a manifest.

• Typical uses: Showing the service URL, port-forward commands, or how to fetch generated secrets.

• Optional: If absent, nothing is printed; it purely improves UX.

Helm chart version fields must be valid SemVer 2 (MAJOR.MINOR.PATCH), and Helm uses those semantics for dependency constraints and version resolution.

• MAJOR.MINOR.PATCH meaning: MAJOR: breaking changes to values/templates; MINOR: backward-compatible additions; PATCH: fixes.

• Constraints in dependencies: Ranges like ~1.2.0 (patch-level), ^1.2.0 (minor-level), or >=1.2, <2.0 control which subchart versions resolve.

• Pre-release and build metadata: Supported (1.0.0-alpha.1); pre-releases are excluded from ranges unless requested.

• appVersion is not constrained: Only version must be SemVer; appVersion is a free-form label.

Yes: a single chart can define as many Deployments (and any other resources) as you want, since Helm simply renders every manifest in templates/ and applies them together as one release.

• Multiple template files or documents: Add several files, or separate manifests with --- in one file; each becomes a distinct object.

• Generate dynamically: Use range over a values list to emit N Deployments from configuration.

• Must stay uniquely named: Each Deployment needs a distinct metadata.name (often derived from a release/full name helper plus a suffix).

• Or use subcharts: Multi-service apps are often split into subcharts, each contributing its own Deployment under an umbrella chart.

helm search repo searches the repositories you've added locally, while helm search hub searches Artifact Hub, the public index of charts across many repositories.

• helm search repo:

  • Queries your locally cached repo index (from helm repo add/helm repo update).

  • Works offline against known repos and returns installable chart references.

• helm search hub:

  • Queries Artifact Hub over the network to discover charts you haven't added.

  • Returns a URL; you typically still helm repo add that repo before installing.

• Rule of thumb: Use hub to discover; use repo to find something in sources you already trust.

The helm show command displays a chart's packaged contents without installing it, letting you inspect metadata, default values, and documentation for a local or remote chart.

• helm show chart: Prints the contents of Chart.yaml: name, version, appVersion, dependencies, and metadata.

• helm show values: Dumps the default values.yaml, so you can see what is configurable before overriding.

• helm show readme: Displays the chart's README.md: usage instructions and documented parameters.

• helm show all: Concatenates chart, values, and readme in one output for a full overview.

• Works on repo charts too: e.g. helm show values bitnami/nginx inspects a remote chart without downloading it manually.

The deprecated field in Chart.yaml is a boolean that marks a chart as no longer maintained or recommended, signaling users to migrate away from it.

• It is a warning flag, not an enforcement: Setting deprecated: true still allows install, but Helm and repos surface a warning.

• Repository behavior: Chart repositories may hide deprecated charts from search results while keeping them installable.

• Best practice: Explain the replacement or migration path in the chart's README.md alongside the flag.

README.md and LICENSE are optional supporting files bundled in a chart: one documents how to use it, the other declares its legal terms.

• README.md:

  • Human-readable documentation: description, prerequisites, configurable values, and install examples.

  • Surfaced by helm show readme and typically rendered on chart repository pages.

• LICENSE:

  • A plain-text file stating the chart's license terms (e.g. Apache 2.0).

  • Clarifies redistribution and usage rights for consumers.

• Both are packaged into the .tgz but do not affect rendering: They are metadata/documentation only, never templated into Kubernetes manifests.

values.yaml holds the default configuration for a chart: templates reference these values, so users customize a release by overriding them instead of editing templates.

• It defines the chart's public API: Every knob a user is expected to tune (replica count, image tag, resources) lives here with a sensible default.

• Templates consume it via .Values: e.g. {{ .Values.replicaCount }} injects the value at render time.

• Customization without forking: Users override defaults with -f myvalues.yaml or --set, keeping the chart reusable across environments.

• Layered merging: User-supplied values are deep-merged onto the chart defaults, so you only specify what differs.

Both override default chart values, but -f/--values points to a YAML file of structured overrides, while --set specifies individual values inline on the command line: they serve different scales of change.

• -f / --values:

  • Reads a full YAML file, ideal for many or nested values; can be repeated and version-controlled.

  • Clean, readable, reviewable: the preferred way for anything non-trivial.

• --set:

  • Sets values inline with dotted paths (--set image.tag=1.2.3); great for a few dynamic values in CI.

  • Verbose and error-prone for complex structures; requires escaping and string coercion (--set-string).

• Precedence: --set wins over -f because it's applied last, letting you override a file value on the fly.

You override the chart's defaults at install time with either a values file (-f/--values) or inline flags (--set and its variants), and you can combine them.

• With a values file: helm install myapp ./chart -f custom-values.yaml; repeat -f to layer multiple files (later ones win).

• With inline flags: helm install myapp ./chart --set replicaCount=3,image.tag=1.2.0.

• Variants of --set: --set-string (force string type), --set-file (read a value's content from a file), --set-json (set a JSON value).

• Combine them: Use a file for the bulk and --set for a few dynamic overrides; --set takes precedence.

• Inspect the result: Verify with helm install --dry-run --debug or helm template before applying.

Helm templates are Kubernetes manifests written with Go templating placeholders, and values files supply the data that fills those placeholders: together they turn one parameterized chart into environment-specific manifests.

• Templates (templates/ directory):

  • YAML manifests with Go template directives ({{ .Values.x }}) plus functions and control flow (if, range, with).

  • Access built-in objects like .Release, .Chart, .Values, and use helpers from _helpers.tpl.

• Values files (values.yaml):

  • Provide default configuration as structured YAML, surfaced to templates as .Values.

  • Overridable per install with -f files and --set.

• Rendering: Helm merges values, executes the templates, and produces final manifests it sends to Kubernetes; preview with helm template.

Helm's flow control comes from Go templates: if/else branches on truthiness, with narrows the . scope to a value, and range iterates over lists and maps. All are block actions closed with end.

• if / else / else if:

  • A value is false when it's a false boolean, 0, empty string, empty list/map, or nil.

  • Often combined with eq, and, not: {{ if eq .Values.env "prod" }}.

• with:

  • Rebinds . to the given value inside the block, so {{ with .Values.image }}{{ .tag }}{{ end }}.

  • It also acts as a guard: the block is skipped if the value is empty. Use $ to reach the root inside it.

• range:

  • Iterates and rebinds . to each element; capture index/key with {{ range $i, $e := .Values.list }}.

  • Empty collections produce no iterations (no output).

• Whitespace note: Pair these with {{- and -}} so control lines don't leave blank lines that break YAML.

The .Release object is a built-in that carries metadata about the current release (the deployment instance of a chart), injected by Helm at render time.

• .Release.Name: The name of the release, commonly used as a prefix for resource names.

• .Release.Namespace: The target namespace the release is installed into.

• .Release.IsInstall and .Release.IsUpgrade: Booleans indicating whether this render is part of a fresh install or an upgrade; useful for hooks and conditional logic.

• .Release.Revision: An integer revision number, incremented on each upgrade/rollback.

• .Release.Service: The service rendering the template, always Helm.

The required function fails template rendering with a custom error message when a value is empty or missing, so you can enforce that a user supplies a mandatory setting instead of silently deploying a broken release.

• Syntax and behavior:

  • Written as required "message" .Values.foo: if the value is empty/nil, rendering aborts and prints your message.

  • If the value is present, it returns that value unchanged so you can pipe it into the template.

• When to use it:

  • For values that have no safe default (image repo, required credentials, hostnames).

  • To fail fast at helm install/template time rather than producing invalid manifests.

• Caveat: Enforced only during rendering; it does not stop someone editing the value later. Pair with default for optional fields.

Helm supports both YAML-style line comments and Go template comments; the key difference is that template comments are stripped before rendering, while YAML comments survive into the output.

• YAML comments (#) the rendered manifest: Remain in the final output and are visible in helm template results.

• Template comments ({{/* ... */}}):

  • Removed during rendering, so they never appear in output; use for notes about the template logic.

  • Can span multiple lines and can include chomping: {{- /* ... */ -}}.

They handle optional and mandatory values respectively: default supplies a fallback when a value is empty, while required aborts rendering with an error when a value is missing.

• default:

  • Written default "fallback" .Values.foo (or piped: .Values.foo | default "fallback").

  • Returns the fallback when the value is empty/nil, otherwise the value.

• required:

  • Written required "message" .Values.foo: fails the render with the message if empty.

  • Use when there is no sensible default and the user must provide the value.

• Note on emptiness: Both treat Go zero values ("", 0, false, nil) as empty, which can surprise you with numeric or boolean fields.

The default function returns a fallback value when its target is empty, letting you make chart values optional without failing the render.

• Usage: default DEFAULT VALUE or, more idiomatically piped, .Values.foo | default "bar".

• What counts as empty:

  • Go zero values: empty string, 0, false, nil, and empty collections trigger the default.

  • Watch out: a legitimate 0 or false will be replaced by the default, which is a common bug.

• When to use: Optional fields with a sensible fallback (image tag, replica count); use required instead when there is no safe default.

Both add leading spaces to every line of a string for YAML alignment; the difference is that nindent also prepends a newline before the indented block, while indent does not.

• indent N:

  • Adds N spaces to the start of every line of the piped string.

  • You must place it on the same line right after a key, so the first line lands where you already are.

• nindent N:

  • First emits a newline, then indents every line by N spaces.

  • Lets you write the template on a fresh line without worrying about trailing content on the previous line.

• Common use: rendering a nested block (labels, a toYaml map) under a key.

printf is Go template's string-formatting function: it substitutes values into a format string and returns the result, letting you build dynamic strings like names, labels, and URLs cleanly.

• Format verbs: %s for strings, %d for integers, %v for any value's default format.

• Common Helm use:

  • Composing resource names from release and chart values in a reusable way.

  • Often piped through other functions like trunc and trimSuffix to respect Kubernetes name limits.

• Returns a value: Unlike print, it applies formatting; the output can be assigned or piped further.

helm dependency update reads the dependencies in Chart.yaml, downloads the matching subchart archives into the charts/ directory, and writes the resolved versions to Chart.lock.

• What it does:

  • Resolves each version constraint against the configured repositories and fetches the .tgz packages.

  • Regenerates Chart.lock so builds are reproducible.

• Versus helm dependency build: build installs the exact versions already pinned in Chart.lock without re-resolving; update re-resolves and refreshes the lock.

• When to run: After adding or changing a dependency version in Chart.yaml.

You define a hook by writing a normal Kubernetes manifest in templates/ and adding the helm.sh/hook annotation (plus optional weight and delete-policy annotations).

• Add the hook annotation under metadata.annotations.

• Optionally add helm.sh/hook-weight for ordering and helm.sh/hook-delete-policy for cleanup.

• Most hooks are Job resources so they run to completion and Helm can wait on them.

helm install creates a brand new release (revision 1) from a chart, while helm upgrade modifies an existing release by computing and applying changes, producing a new revision.

• helm install: Requires a non-existent release name; creates revision 1 and applies all rendered resources.

• helm upgrade:

  • Requires an existing release; renders the new manifests and applies the diff, incrementing the revision number.

  • Preserves history so you can later helm rollback.

• Shared behavior: Both run relevant hooks and store a release revision as a Secret in the namespace.

• Practical note: Use upgrade --install when a script shouldn't care whether the release already exists.

A revision is a numbered snapshot of a release at a point in time: every install, upgrade, or rollback increments the revision counter and stores the full manifest and values, giving Helm an auditable, restorable history.

• What a revision captures: The rendered manifest, the computed values, chart metadata, and a status.

• How it increments: Install = revision 1; each upgrade and rollback adds a new revision (rollback copies an old one forward).

• Where it's stored: By default as a Secret per revision in the release's namespace (configurable to ConfigMap or SQL backend).

• Inspecting history:

  • helm history <release> lists revisions with status and description; helm get manifest/values <release> --revision N shows a specific one.

  • --history-max limits how many revisions are retained.

A Helm release moves through a set of well-defined statuses that describe the outcome of the last operation and whether an operation is currently in progress.

• deployed: The revision was successfully installed or upgraded and is the current live release.

• failed: The install, upgrade, or rollback did not complete successfully.

• superseded: A previously deployed revision that has been replaced by a newer one.

• pending-install, pending-upgrade, pending-rollback: The operation is in progress; a release stuck here usually means the process was interrupted.

• uninstalling: An uninstall is currently running (hooks/resource deletion).

• uninstalled: The release was removed but history was kept via --keep-history.

• Check with: helm status <release> or helm list --all to see states including failed and uninstalled releases.

Helm release management treats a set of deployed resources as one named, versioned unit so you can install, track, upgrade, roll back, and cleanly remove it; you delete safely with helm uninstall, which removes the resources Helm created and its release state.

• Purpose of release management:

  • Groups many manifests into one lifecycle object with revision history.

  • Enables atomic-ish upgrades and rollbacks instead of manual kubectl edits.

  • Gives an auditable record of what was deployed and with which values.

• Deleting safely:

  • Run helm uninstall <release> -n <ns> to delete Helm-managed resources.

  • Use --dry-run first to preview what would be removed.

  • Keep the history with --keep-history if you may want to inspect or reinstate it.

• Watch-outs:

  • PVCs, and resources with helm.sh/resource-policy: keep, are not deleted and must be cleaned up manually.

  • Resources created outside Helm (e.g. by controllers) aren't tracked and won't be removed.

Use helm list (alias helm ls) to see deployed releases; by default it shows only the current namespace, so add -A/--all-namespaces for the whole cluster.

• Columns displayed per release:

  • NAME: the release name.

  • NAMESPACE: where it is deployed.

  • REVISION: current revision number.

  • UPDATED: timestamp of the last change.

  • STATUS: e.g. deployed, failed, pending-upgrade.

  • CHART and APP VERSION: chart name/version and the app version it ships.

• Useful filters:

  • --all also shows non-deployed states (failed, superseded).

  • -o json or -o yaml for machine-readable output.

The Helm lifecycle moves a chart from authoring, through packaging and installation, into ongoing upgrades and rollbacks, and finally uninstallation, with release state tracked in the cluster at every step.

1. Create: helm create <name> scaffolds Chart.yaml, values.yaml, and templates/.

2. Validate and package:

   • helm lint and helm template check rendering, then helm package produces a .tgz.

   • Optionally push to a chart repository or OCI registry.

3. Install: helm install <release> <chart> renders templates and creates resources as revision v1.

4. Upgrade / rollback:

   • helm upgrade applies changes as new revisions; helm rollback reverts to a prior one.

   • Inspect with helm history, helm status, helm get.

5. Uninstall: helm uninstall removes managed resources and release state (unless --keep-history).

helm get retrieves the stored details of an installed release from the release's stored data (secrets/configmaps in the cluster), letting you inspect exactly what was deployed for a given revision.

• Subcommands select what to fetch:

  • helm get values: the user-supplied values (add --all to see computed values including chart defaults).

  • helm get manifest: the fully rendered Kubernetes manifests actually applied.

  • helm get notes: the rendered NOTES.txt output.

  • helm get hooks: the hook manifests defined by the chart.

  • helm get all: everything above combined.

• Revision-aware: Use --revision N to inspect a specific past revision, useful before a rollback.

• Purpose: debugging and auditing what Helm believes is deployed, not the live cluster state.

helm status shows the current high-level state of a release: its deployment status, the revision, and summary info about the resources and notes.

• Release metadata:

  • Name, namespace, last deployed timestamp, and current revision number.

  • Status such as deployed, failed, pending-upgrade, or superseded.

• Rendered NOTES: Prints the chart's NOTES.txt, often usage/access instructions.

• Resource detail (optional):

  • Add --show-resources to list the Kubernetes objects and their live state.

  • Use --revision N to see the status of a specific revision.

helm history lists the revision history of a release: every install, upgrade, and rollback recorded, so you can see how the release evolved and pick a target to roll back to.

• What each row shows: Revision number, update time, status (deployed, superseded, failed), chart version, app version, and a description of the action.

• How you use it:

  • Run helm history <release> to find a known-good revision, then helm rollback <release> <revision>.

  • Limit rows with --max N; Helm also caps stored revisions via --history-max on upgrade.

--create-namespace tells Helm to create the target namespace if it does not already exist before installing the release, saving a separate kubectl create namespace step.

• Used with -n/--namespace: Helm installs into the namespace given by --namespace and creates it first if missing.

• Scope and caveats:

  • Applies to helm install (and helm upgrade --install); without it, installing into a nonexistent namespace fails.

  • Helm does not delete the namespace on helm uninstall.

--dry-run renders and simulates a command without changing the cluster, and --debug turns on verbose output including the fully rendered manifests and extra diagnostic logging.

• --dry-run: Simulates install/upgrade so you can inspect what would happen without side effects.

• --debug: Emits verbose logs and prints the rendered YAML, helpful for troubleshooting template logic.

• Combined: helm install --dry-run --debug: A common pattern to preview the exact manifests Helm would produce and debug template errors before deploying.

Helm has two search commands: helm search repo looks through repositories you've already added locally, and helm search hub queries the Artifact Hub for charts across many public repositories.

• helm search repo:

  • Searches charts in repos added via helm repo add (offline, uses your cached index).

  • Add --versions to list all versions, or -l for details.

• helm search hub: Searches Artifact Hub, discovering charts from repositories you haven't added.

• Keeping results fresh: Run helm repo update first so local search reflects the latest chart versions.

--timeout sets how long Helm waits for operations to complete, most importantly the readiness waiting done under --wait and hook execution; it defaults to 5 minutes (5m0s).

• What it bounds:

  • The time Helm blocks waiting for resources to become ready when --wait is set.

  • The time allowed for hooks (e.g. a pre-install Job) to finish.

• Format: A Go duration string like --timeout 10m or --timeout 90s.

• On expiry the operation fails (and may roll back with --atomic); without --wait the timeout mostly just affects hooks.

helm env prints the environment variables and computed paths that Helm uses for its configuration, useful for diagnosing where Helm reads and writes things.

• Key values shown:

  • HELM_BIN: path to the Helm binary in use.

  • HELM_CONFIG_HOME: where repositories and config live.

  • HELM_DATA_HOME: where plugins and data are stored.

  • HELM_CACHE_HOME: cache location for downloaded charts and repo indexes.

  • HELM_NAMESPACE and Kubernetes-related settings like HELM_KUBECONTEXT.

• Why it helps: Lets you confirm which directories/config a Helm run will use, and override them by exporting the same variables.

You register a repo's URL locally with helm repo add, then refresh your cached copy of its index with helm repo update so Helm knows the latest available chart versions.

• helm repo add <name> <url>:

  • Downloads the repo's index.yaml and stores the mapping in your local config (repositories.yaml).

  • Supports auth via --username/--password for private repos.

• helm repo update: Re-fetches the index for all (or named) repos so helm search and installs see new versions.

• Supporting commands: helm repo list shows configured repos, helm repo remove <name> deletes one, and helm search repo <keyword> queries cached indexes.

• Key point: these are all client-side; caches are only as fresh as your last update.

Artifact Hub is the CNCF web-based catalog for discovering Helm charts (and other cloud-native artifacts); it replaced the older, chart-only Helm Hub.

• What Artifact Hub does:

  • Aggregates and indexes public chart repositories so users can search, view READMEs, versions, and security scans in one place.

  • Also lists many non-Helm artifacts (operators, OLM, Falco rules, OPA policies, plugins).

• Relationship to Helm Hub: Helm Hub was the earlier Helm-specific aggregator; it was deprecated and its content migrated into Artifact Hub.

• It is a discovery layer, not a host: Charts still live in their own repos/registries; Artifact Hub just indexes them and shows the helm repo add command to use.

A Helm chart repository is an HTTP location serving packaged charts plus an index.yaml catalog; you connect to it locally with helm repo add and keep it current with helm repo update.

• The repository: A collection of .tgz chart archives and an index.yaml that lists every chart, version, and download URL.

• helm repo add <name> <url>: Registers the repo under a short alias and caches its index locally, so you can reference charts as <name>/<chart>.

• helm repo update: Pulls the latest index.yaml so new chart versions become visible to search and install.

• Typical flow: Add, update, then helm install myrelease <name>/<chart>.

A Helm chart repository is an HTTP server hosting packaged charts, and index.yaml is its manifest: the file Helm reads to know which charts and versions exist and where to download them.

• The repository: Just a set of .tgz chart archives plus index.yaml, served over plain HTTP(S).

• Role of index.yaml:

  • Lists each chart's name, version, appVersion, and metadata.

  • Holds the download urls for each version and a digest for integrity checking.

  • Includes a generated timestamp and apiVersion.

• How it's used: helm repo add fetches and caches it; helm search and helm install resolve versions and URLs from it.

• Maintenance: regenerate it with helm repo index whenever you add or update charts.

helm version prints the Helm client version (and in Helm 2, also the Tiller/server version); the fact that Helm 3 is client-only reflects the removal of Tiller, which changed the entire security and architecture model.

• What it shows:

  • Helm 3 outputs a single client version string; there is no server component to report.

  • Helm 2 showed both Client and Server (Tiller) versions, which had to match.

• Why client-only matters:

  • No Tiller: Helm 3 talks directly to the Kubernetes API using your kubeconfig credentials.

  • Security improves: permissions are governed by your own RBAC rather than Tiller's cluster-wide service account.

  • Release state moved from Tiller's ConfigMaps to Secrets in the release's namespace.

helm lint statically examines a chart for structural and syntactic problems before you ever install it, catching issues early in development and CI.

• What it checks:

  • Required files and fields (valid Chart.yaml, proper structure).

  • Template rendering errors and malformed YAML.

  • Best-practice conventions, reported as INFO, WARNING, or ERROR.

• How it's used:

  • Run helm lint ./mychart, optionally with --values to lint against specific overrides.

  • Only ERRORs cause a nonzero exit by default; use --strict to fail on warnings too.

• Why it matters:

  • Fast feedback loop in CI prevents shipping broken charts.

  • Caveat: linting is not full validation: it does not guarantee the rendered manifests are valid Kubernetes objects.

Both are declarative deploy tools, but Helm specializes in packaging Kubernetes apps, while Terraform is a general infrastructure-as-code tool that provisions many providers and tracks state.

• Scope: Helm targets only Kubernetes workloads; Terraform provisions clusters, cloud infra, DNS, plus optionally the apps.

• State model: Terraform keeps an external state file and plans diffs; Helm stores release state as Secrets in the cluster.

• Kubernetes fluency: Helm speaks native manifests and has a rich chart ecosystem; Terraform's Kubernetes provider is more generic and verbose.

• Common pattern: Use Terraform to build the cluster/infra, then Helm (or the Terraform helm provider) to deploy apps onto it.

Helm has first-class distribution via packaged, versioned charts served from repositories; Kustomize has no native packaging and is typically shared as raw files in Git.

• Helm distribution:

  • Charts are packaged into versioned .tgz archives.

  • Published to chart repositories or OCI registries and pulled with helm repo add / helm pull.

  • Semantic versioning enables discoverable, pinned dependencies.

• Kustomize distribution:

  • No package format; bases and overlays are shared as YAML directories, usually via Git.

  • Remote bases can be referenced by Git URL in kustomization.yaml, but there is no versioned artifact or registry.

Yes: Helm stores each release's state (rendered manifests, values, revision history) inside the cluster itself, so the cluster is the source of truth for what Helm has installed.

• Where state lives (Helm 3):

  • Release data is saved as Secrets (by default) in the release's namespace, named like sh.helm.release.v1.<name>.v<n>.

  • Helm 2 stored it in ConfigMaps via Tiller instead.

• What is stored: A gzipped snapshot of the release: chart, supplied values, rendered manifests, and revision number.

• Why it matters:

  • Enables helm history, helm rollback, and diff-based upgrades.

  • If someone edits resources with kubectl directly, Helm's stored state drifts from reality.

Helm suits microservices because its templating, subcharts, and per-release lifecycle let you standardize and independently deploy many similar services from shared, reusable packaging.

• Reusable templates and values: One parameterized chart plus per-service values.yaml avoids copy-pasting manifests across dozens of services.

• Subcharts and dependencies: An umbrella chart can declare dependencies in Chart.yaml to deploy a whole system, or each service can ship its own chart for independent releases.

• Library charts: Shared template helpers (labels, probes, resources) enforce consistent conventions across teams.

• Independent lifecycle: Each service is its own release, so you upgrade or rollback one without touching the others.

• Environment overrides and hooks: Different value files per environment; hooks handle migrations or setup jobs per service.

Helm centralizes configuration in values.yaml injected into templates, whereas Kustomize keeps the actual YAML and overrides fields through overlays and patches, so there are no placeholders.

• Helm: parameterized values:

  • Defaults live in values.yaml; override per-install with --set or -f custom-values.yaml.

  • Supports conditionals, loops, and functions in templates for dynamic config.

  • Risk: you must read the template to know what a value actually affects.

• Kustomize: patch the real manifest:

  • Every environment sees genuine Kubernetes YAML; overlays merge in differences.

  • Built-in transformers set common labels, name prefixes/suffixes, namespaces, and images.

  • No logic, so config is transparent but repetitive for many variations.

• Trade-off: Helm favors reuse and distribution; Kustomize favors transparency and simplicity.

Helm has first-class release versioning and history that enable rollbacks, while Kustomize has no runtime state and relies entirely on Git history for versioning.

• Helm: built-in release tracking:

  • Each install/upgrade creates a numbered revision stored as a Secret in the cluster.

  • helm history lists revisions; helm rollback reverts to a prior one.

  • Charts also carry a version and appVersion in Chart.yaml for artifact versioning.

• Kustomize: Git is the source of truth:

  • No release objects or revision numbers; versioning = commit history.

  • Rollback means reverting a commit and re-applying, typically via a GitOps controller.

• Practical implication: Helm gives imperative rollback out of the box; Kustomize's rollback is only as good as your Git and CI/CD discipline.

Kustomize is built directly into kubectl, while Helm is a separate binary that renders and manages releases outside of kubectl.

• Kustomize: native to kubectl:

  • kubectl apply -k ./overlay builds and applies in one step.

  • kubectl kustomize ./overlay renders YAML without applying.

  • No extra tooling to install (though the standalone binary is often newer).

• Helm: separate client:

  • Requires the helm CLI; it talks to the Kubernetes API itself, not through kubectl.

  • helm template can render manifests that you then pipe to kubectl apply -f - if you want kubectl to apply them.

• Combining them: You can render a chart with helm template and post-process it with Kustomize (Helm even supports post-renderers).

Good chart practice centers on predictable structure, safe defaults, version discipline, and validation so charts are reusable and upgradeable without surprises.

• Sensible, documented values: Provide safe defaults in values.yaml, document each key, and validate with a JSON schema (values.schema.json).

• Version discipline: Bump the chart version on every change and follow SemVer; keep appVersion aligned with the shipped app.

• Keep templates DRY: Centralize labels and names in _helpers.tpl and use standard app.kubernetes.io labels.

• Validate before shipping: Run helm lint, helm template, and --dry-run in CI.

• Pin and manage dependencies: Declare subcharts in Chart.yaml with pinned versions and lock them via Chart.lock.

• Document and test: Ship a clear README and NOTES.txt; consider helm test hooks.

apiVersion in Chart.yaml declares the chart schema: v1 is the Helm 2 era format, while v2 is the Helm 3 format that changed how dependencies and chart types are declared.

• Dependencies location: v1 used a separate requirements.yaml; v2 moves dependencies into a dependencies: block in Chart.yaml.

• Chart type: v2 adds a type field (application or library), enabling library charts.

• Compatibility: Helm 3 reads both, but new charts should use v2; v1 charts are treated as legacy.

A library chart is a chart that only provides reusable template helpers for other charts to consume: it has no installable Kubernetes resources of its own, unlike an application chart which deploys a real workload.

• Declared by type: Set type: library in Chart.yaml; application charts use type: application (the default).

• Not directly installable: helm install on a library chart fails; it is meant to be added as a dependency and its define blocks reused.

• Purpose: Share common logic (labels, naming, boilerplate manifests) across many charts in an organization.

• Templates only: Its templates are typically _*.tpl helper files rather than rendered manifests.

The crds/ directory holds CustomResourceDefinition YAML that Helm installs before the rest of the chart's resources, so custom resources can be created during the same release.

• Installed first: Helm applies everything in crds/ before templates, ensuring the CRD exists before dependent objects.

• Not templated: Files here are plain YAML: Go templating and values are NOT processed.

• Never upgraded or deleted: Helm installs CRDs only if absent; it will not update them on helm upgrade or remove them on helm uninstall (to avoid data loss).

• Alternative for full lifecycle: If you need CRDs to be templated or upgradable, put them in templates/ instead, accepting the ordering trade-offs.

Bump version whenever the chart's templates or defaults change, and bump appVersion when the underlying application image/release changes: they move independently.

• chart version tracks packaging:

  • Must change on every published change, since repos key releases by chart version and won't re-serve an existing one.

  • Follows SemVer relative to template/value changes, not the app.

• appVersion tracks the app:

  • Bump it when you point to a new application release; often used as the default image tag.

  • A pure appVersion change is still a chart change, so version must bump too.

• Practical rule:

  • App-only update: patch version, update appVersion.

  • Template refactor with no app change: bump version only.

A library chart (type: library) is a chart that only provides reusable template helpers and no installable Kubernetes resources: other charts import it to share common template logic.

• Not installable on its own: It renders no manifests directly; helm install of a library chart is rejected.

• Consumed as a dependency: Listed under dependencies of an application chart, which then calls its named templates.

• Shares logic via named templates: Defines define blocks (helpers for labels, selectors, standard Deployment/Service shapes) consumed with include.

• Benefit: DRY across many charts: fix conventions in one place instead of copy-pasting boilerplate.

Chart.yaml is the chart's manifest of metadata that Helm reads to identify, version, and package it; the key distinction is that version describes the chart while appVersion describes the application it deploys.

• apiVersion: Schema version of the chart format: v2 for Helm 3 (enables dependencies and type in-file), v1 for older Helm 2.

• name: The chart's name; must match its directory and is used in release naming and templates.

• version: SemVer of the chart package itself; repos key releases by it and it must change on every publish.

• appVersion: Version of the software being deployed (free-form); informational and often used as the default image tag.

• version vs appVersion: They move independently: you can ship chart 2.4.0 that deploys app 1.16.0. A template change bumps version only; a new app image bumps appVersion (and version too, since it is still a chart change).

Helm merges values from multiple sources at install/upgrade time, with more specific and later-specified sources winning: command-line --set flags override files, which override the chart's own defaults.

• -f / --values: Supplies an entire YAML file of overrides; can be repeated, with later files taking precedence over earlier ones.

• --set: Inline overrides on the command line; Helm infers types (numbers, booleans) from the value.

• --set-string: Same as --set but forces the value to a string (e.g. keeps "1234" a string, not an int).

• --set-file: Reads the value from a file's contents, useful for certs or scripts too large for the command line.

• Precedence (lowest to highest):

  1. Chart's own values.yaml defaults.

  2. Files from -f (later files beat earlier ones).

  3. --set family flags (--set, --set-string, --set-file) override everything above.

Global values live under a special global key in the parent chart's values and are automatically shared with every subchart, letting you set a value once and use it everywhere.

• Defined under .Values.global: Anything nested there is injected into all subcharts at the same path.

• Accessible identically in parent and children: A subchart reads .Values.global.imageRegistry just as the parent does.

• Typical use cases: Shared registry, image pull secrets, storage class, or environment name across many components.

• Non-global values are scoped: To pass ordinary values to a subchart you must nest them under the subchart's name; globals bypass that requirement.

values.schema.json is a JSON Schema that Helm uses to validate user-supplied values, rejecting installs or upgrades whose values are malformed before any templates render.

• Enforces structure and types: Declare required fields, allowed types, enums, ranges, and patterns for your values.

• Validated automatically: Runs on helm install, upgrade, template, and lint, failing fast with a clear error.

• When to use it: For charts consumed by others, where you want to catch typos and misconfigurations early rather than via a broken deploy.

• Complements defaults: values.yaml provides defaults; the schema constrains what overrides are legal.

All four inject values from the command line, but they differ in how the value is interpreted: --set infers types, --set-string forces strings, --set-file reads from a file, and --set-json parses JSON structures.

• --set: Type-inferred scalars and simple arrays; --set port=8080 becomes an integer, true becomes a boolean.

• --set-string: Always stores a string, avoiding surprises like a numeric tag --set-string image.tag=1.0 staying quoted.

• --set-file: Sets the value to the contents of a file: --set-file cert=./tls.crt, good for multi-line data.

• --set-json: Parses a JSON string into complex structures: --set-json 'servers=[{"port":80}]' builds nested lists/maps hard to express with --set.

--set is convenient for quick, one-off overrides, but it becomes awkward and error-prone for anything complex or repeatable: values files are the durable, reviewable source of truth.

• Poor for complex structures: Deeply nested maps and lists need fiddly syntax (a.b.c=x, commas, escaped dots), which is hard to read and easy to get wrong.

• Type coercion surprises: Everything is a string unless coerced; values like version numbers or IDs may be misinterpreted (use --set-string to force strings).

• Not version-controlled: CLI flags live in shell history or scripts, not reviewed in Git like a values.yaml, hurting auditability and reproducibility.

• Doesn't scale: Dozens of overrides on one command line are unreadable and fragile compared with a structured file.

• Escaping pain: Commas, dots, and special characters inside values require escaping, unlike clean YAML.

Rule of thumb: use --set for a couple of dynamic values (like an image tag in CI); use -f values.yaml for everything else.

The standard pattern is a base values.yaml with shared defaults, then per-environment override files layered on top at install/upgrade time, keeping only the differences in each environment file.

• Layer values files: Keep common config in the chart's values.yaml, then supply values-dev.yaml, values-staging.yaml, values-prod.yaml with only the deltas.

• Stack files with -f: Later files override earlier ones: helm upgrade app ./chart -f values.yaml -f values-prod.yaml.

• Late-bind dynamic values: Inject per-deploy values (image tag, build number) with --set image.tag=$SHA in CI.

• Keep secrets out: Store sensitive values separately (SOPS, sealed-secrets, external secret stores), not in plain env files.

• Tooling helps: Umbrella charts or GitOps tools (Argo CD, Flux) and Helmfile formalize the base-plus-overlay approach across environments.

Helm supports two complementary validation approaches: a JSON Schema file that Helm checks automatically, and the required (and fail) template functions that enforce constraints at render time.

• values.schema.json:

  • A JSON Schema placed at the chart root; Helm validates the merged values against it during install, upgrade, lint, and template.

  • Enforces types, required properties, enums, ranges, and formats declaratively (no templating needed).

• required function: Fails rendering with a clear message if a value is missing or empty: good for a single mandatory field.

• fail function: Aborts rendering with a custom message for conditional/cross-field rules that schema can't express.

• When to use which: Prefer the schema for structural/type rules; use required/fail for logic-driven checks inside templates.

There are two things called "values": the chart's default values.yaml that ships in the chart, and the final merged values for a release, which Helm persists in the release record (a Secret by default) in the cluster.

• Default values in the chart: Stored as values.yaml at the chart root (subcharts have their own), exposed to templates as .Values.

• User overrides at deploy time: Provided via -f files and --set, merged over the defaults.

• Release state in the cluster:

  • Helm v3 stores each release's rendered manifest and computed values in a Kubernetes Secret (type helm.sh/release.v1) in the release namespace.

  • Retrieve the values you supplied with helm get values <release> (add -a for all computed values).

Helm merges values in a defined order where the last source applied wins: chart defaults are lowest, -f files come next (left to right), and --set flags are applied last, so they override everything.

1. Chart's values.yaml (lowest priority).

2. Each -f/--values file, in the order given; a later -f overrides an earlier one.

3. --set / --set-string / --set-file / --set-json flags (highest priority).

• Merge, not replace: Maps are deep-merged key by key; but lists/arrays are replaced wholesale, not merged.

• Practical implication: Put base config in files and use --set for the final, per-run overrides.

With --set you use a mini DSL where . separates keys, [n] indexes arrays, and , separates assignments: any of these characters appearing inside a key or value must be backslash-escaped so Helm doesn't treat them as syntax.

• Nested keys use dots:

  • --set outer.inner=value produces {outer: {inner: value}}.

  • A literal dot in a key name must be escaped: --set nodeSelector."kubernetes\.io/role"=master.

• Array indexes use brackets:

  • --set servers[0].port=80 builds a list; --set-string forces string typing.

  • --set name={a,b,c} sets a list literal directly.

• Special characters need backslashes:

  • Escape commas in a value: --set command="cmd\,arg", otherwise the comma starts a new assignment.

  • Because the shell also consumes backslashes, wrap in single quotes or double the backslash.

• When it gets ugly, prefer a values file: -f values.yaml or --set-file (reads a value from a file) avoids fragile escaping entirely.

Helm treats each file under templates/ as a Go text/template document: it renders the templates against a set of values and objects, producing plain YAML that is then sent to the Kubernetes API.

• Rendering pipeline:

  1. Helm loads the chart, merges default values.yaml with user overrides, and builds built-in objects like .Release.

  2. Each template is executed by the Go engine; {{ ... }} actions are replaced with computed output.

  3. The resulting text is parsed as YAML manifests and applied.

• Template syntax:

  • {{ .Values.image.tag }} injects values; pipelines chain functions: {{ .Values.name | upper | quote }}.

  • Whitespace control with {{- and -}} trims surrounding blanks so YAML indentation stays valid.

• Beyond stock Go templates: Helm adds the Sprig function library plus Helm-specific functions like include, tpl, and required.

• Key implication: Helm is text templating, not YAML-aware, so indentation and quoting are your responsibility.

Built-in objects are top-level values Helm injects into every template, giving access to release metadata, chart metadata, user values, cluster capabilities, and bundled files. They all begin with a capital letter and are addressed from the root scope (.).

• .Release: Install/upgrade info: .Release.Name, .Release.Namespace, .Release.Revision, .Release.IsUpgrade.

• .Chart: Contents of Chart.yaml: .Chart.Name, .Chart.Version, .Chart.AppVersion.

• .Values: Merged values from values.yaml plus -f/--set overrides.

• .Capabilities: Cluster info: .Capabilities.KubeVersion and .Capabilities.APIVersions.Has.

• .Files: Access non-template files in the chart: .Files.Get, .Files.Glob, .Files.AsConfig.

• .Template: The current file being rendered: .Template.Name and .Template.BasePath.

• Also .Subcharts: Lets a parent chart reach into subchart values and objects.

Variables in Helm templates are named references assigned with := and prefixed with $. They're useful for caching a value, giving a readable name to something, or preserving access to the root scope inside blocks that change the . context.

• Declaring and reassigning: {{ $name := .Values.name }} declares; {{ $name = "new" }} reassigns (Helm 3+).

• Escaping scope changes: Inside range or with, . is rebound, so capture the root first: {{ $root := . }} or use $ which always points at the top-level scope.

• Capturing index/key in range: {{ range $i, $v := .Values.list }} or {{ range $key, $val := .Values.map }}.

Named templates (partials) are reusable template blocks defined with define and invoked with template or include, usually kept in files starting with _ (like _helpers.tpl) which Helm does not render as manifests. They keep charts DRY (labels, names, selectors).

• Defining a partial: {{ define "mychart.labels" }} ... {{ end }}: names are conventionally namespaced by chart.

• Calling it: {{ template "mychart.labels" . }}: you pass a scope (often .) so the partial can read values.

• Why include is preferred:

  • template is an action that writes directly to output and returns nothing, so you cannot pipe its result.

  • include is a function that returns the rendered string, so you can pipe it: {{ include "mychart.labels" . | indent 4 }}.

  • That piping ability, especially nindent/indent for correct YAML indentation, is why include is the standard.

A pipeline chains commands so the output of one becomes the last argument of the next, using the | operator; it is the idiomatic way to transform values in Helm templates.

• How the pipe works: The value on the left is fed as the final argument to the function on the right, enabling readable left-to-right chains.

• Chaining transformations: You can string multiple functions: e.g. take a value, apply a default, then indent it.

• Equivalent forms: {{ .Values.name | upper | quote }} equals {{ quote (upper .Values.name) }} but reads more naturally.

By convention charts define named templates in _helpers.tpl that generate consistent resource names and the standard Helm/Kubernetes recommended labels, so every manifest shares the same identity.

• Naming helpers: chart.name, chart.fullname, and chart.chart build DNS-safe names, usually truncated to 63 chars with trunc 63 and trimSuffix "-".

• Recommended labels: app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/version, app.kubernetes.io/managed-by, and helm.sh/chart.

• Selector labels: A stable subset (name + instance) kept separate because a Deployment's selector is immutable and must not include version labels that change on upgrade.

Because Helm renders YAML, where indentation is significant, you control whitespace with dash modifiers on template delimiters and with indent functions to keep output valid.

• Dash trims: {{- removes preceding whitespace (including the newline) and -}} removes following whitespace, so control actions don't leave blank lines.

• indent vs nindent: indent N adds N spaces to each line; nindent N prepends a newline first, ideal for embedding blocks under a key.

• Why it matters: A stray space or misplaced newline produces invalid YAML or wrong nesting, causing install failures; use helm template to inspect rendered output.

Sprig is the Go template function library that Helm embeds, providing the bulk of the utility functions you use beyond Go's built-ins.

• String functions: upper, lower, trim, trunc, replace, quote.

• Defaults and logic: default, empty, coalesce, ternary.

• Lists and dicts: list, dict, index, keys, merge.

• Encoding, math, dates: b64enc, toYaml, add, sha256sum, now.

• Caveat: Helm disables a few non-deterministic/insecure Sprig functions (e.g. env, expandenv) to keep renders reproducible.

The .Files object gives templates access to non-template files packaged in the chart, so you can pull their contents into manifests.

• .Files.Get: Reads a single file's contents as a string, e.g. loading a config into a ConfigMap.

• .Files.Glob: Returns files matching a pattern; pair with .AsConfig or .AsSecrets to emit many key/value entries at once.

• Encoding helpers: .Files.Get "f" | b64enc for Secret data; .Files.Lines to iterate line by line.

• Limits: Cannot reach files outside the chart, and templates/ plus ignored files (.helmignore) are excluded.

Templates combine pipelines (chaining with |) and Sprig functions to validate, default, format, and indent values; a handful of functions appear in nearly every chart.

• default: Supplies a fallback when a value is empty: {{ .Values.replicas | default 1 }}.

• required: Fails the render with a message if a value is missing, enforcing mandatory config: {{ required "image is required" .Values.image }}.

• nindent: Adds a leading newline and indents a multi-line block to fit YAML structure, typically after include or toYaml.

• toYaml: Serializes a values map/list back to YAML so you can splice arbitrary structures (resources, env vars) into a manifest.

A with block rebinds the dot (.) to a specified value for its body, reducing repetition, but that rescoping is exactly what trips people up.

• How it narrows scope: Inside {{ with .Values.image }}, . now refers to .Values.image, so you write .repository instead of the full path.

• It also acts as a guard: The block only executes if the value is non-empty, so it doubles as a presence check.

• Pitfall: losing the root: Built-ins like .Release or .Values are no longer reachable via .; use the root variable $ (e.g. $.Release.Name) inside the block.

• Pitfall: skipped when empty: If the value is empty the whole body is silently omitted, which can surprise you if you expected defaults there.

The range action iterates over a list or map, and inside it the dot (.) is rebound to the current element, so the $ root-scope escape lets you reach top-level values like .Values that the loop scope has hidden.

• How range works:

  • Over a list: {{ range .Values.items }} sets . to each element.

  • Over a map or with index/key: {{ range $key, $val := .Values.map }} captures both.

• Why $ is needed:

  • Inside the loop . no longer points at the root context, so .Values.foo would resolve against the element.

  • $ always refers to the top-level scope passed to the template, regardless of nesting.

They solve the recurring problem of embedding structured data with correct YAML indentation: toYaml serializes a value into YAML, and nindent/indent align that block to the right column.

• toYaml: Converts a map or list from .Values into YAML text, so you can pass through whole blocks (resources, labels, env) without hardcoding each key.

• indent N: Prepends N spaces to every line of the string; you must supply the leading newline yourself.

• nindent N: Like indent but adds a leading newline first, which is what you usually want after a YAML key.

• Common pattern: Pipe together: {{ toYaml .Values.resources | nindent 4 }}.

Use the $ variable: it is bound once to the root context at the start of template execution and never changes, so it reaches .Release, .Values, and .Chart even when . has been rebound by range or with.

• Why the dot changes: range rebinds . to the current element; with rebinds it to the specified sub-object.

• How $ helps: $.Release.Name, $.Values.global, etc. always resolve against the original root.

• Alternative: You can also capture a named variable before entering the block, e.g. {{ $top := . }}, then use $top.

include is preferred because it returns the rendered template as a string, which you can pipe into functions like nindent or toYaml; the built-in template action only prints output inline and cannot be piped.

• template is an action, not a function:

  • It writes directly to output, so you can't capture or transform its result.

  • This makes correct indentation of shared snippets nearly impossible.

• include is a function that returns a string:

  • Signature is include "name" ., and the result flows through a pipe.

  • Lets you do {{ include "mychart.labels" . | nindent 4 }}.

• Practical takeaway: Almost always use include for named templates so output stays valid YAML.

toYaml serializes a Go/Helm value (map, list, scalar) into a YAML string, and fromYaml parses a YAML string back into a data structure you can traverse in the template.

• toYaml:

  • Turns structured values into YAML text, typically piped through nindent to place it correctly under a key.

  • Great for passing through arbitrary user config like .Values.resources without re-templating each field.

• fromYaml:

  • Parses a YAML string into a dict/list you can index and iterate.

  • Useful with .Files.Get or tpl output to read structured data.

  • There is also fromYamlArray for top-level YAML lists.

• They round-trip: fromYaml then toYaml is a common way to merge or normalize config.

The .Template built-in object gives the currently executing template information about itself: .Template.Name is the full path of the template being rendered, and .Template.BasePath is the directory path of the template files in the chart.

• .Template.Name:

  • The namespaced path of the template as Helm sees it, e.g. mychart/templates/deployment.yaml.

  • Handy for debugging or emitting a comment noting which template produced a manifest.

• .Template.BasePath:

  • The base directory of the current chart's templates, e.g. mychart/templates.

  • Occasionally used to construct paths relative to the templates directory.

• Both are read-only and reflect the template being executed, not necessarily the top-level chart (relevant inside subcharts).

ternary is a three-argument conditional: it returns the first value if the third (the boolean test) is true, otherwise the second value. The form is ternary <trueVal> <falseVal> <test>.

• Argument order matters: The condition is last, which reads oddly compared to most languages, so it is commonly used with a pipe.

• Piped style: {{ ternary "a" "b" .Values.flag }} or {{ .Values.flag | ternary "a" "b" }}.

• The test must be a real boolean: Wrap non-bool conditions with a comparison or empty/not to coerce a proper boolean.

Both pick a fallback value, but default chooses between exactly two things (a fallback and one given value), while coalesce scans a list of many arguments and returns the first non-empty one.

• default:

  • default <fallback> <value>: returns value unless it is empty, then the fallback.

  • Often piped: {{ .Values.name | default "web" }}.

• coalesce:

  • coalesce a b c ...: returns the first argument that is not empty, checking left to right.

  • Good for cascading precedence across several possible sources.

• Shared notion of "empty": Both treat 0, "", false, empty collections, and nil as empty, so a legitimate 0 or false can be overridden unexpectedly.

b64enc Base64-encodes a string and b64dec decodes it; they are used most in Secret manifests, whose data fields require Base64-encoded values.

• Encoding into Secrets:

  • Kubernetes stores Secret.data as Base64, so plaintext values from .Values are piped through b64enc.

  • Use stringData if you would rather Kubernetes do the encoding.

• Decoding: b64dec reads a value from a looked-up Secret to reuse or transform it.

• Common companions: Paired with randAlphaNum to generate credentials, or with .Files.Get to embed file contents.

• Caveat: encoding is not encryption; the value is still readable to anyone who can read the Secret.

index retrieves a value from a map or list by key/position, and by chaining keys you can walk into deeply nested or dynamically-named structures that dot notation can't reach.

• Basic syntax: index $collection key1 key2 ... descends one level per argument.

• Dynamic keys: Dot notation requires literal names; index accepts variables, so you can look up a key computed at render time.

• Keys with special characters: Keys containing dots or dashes (e.g. annotation names) can't use .Values.a.b; use index instead.

• Lists too: Pass an integer to index into a slice by position.

fail immediately stops template rendering and returns an error with your message: it's how you enforce required configuration or valid input before Helm produces manifests.

• Aborts rendering: The whole helm install/template fails fast with the message you supply, so no partial release is applied.

• When to use:

  • Validating that a mandatory value is set or within allowed values.

  • Guarding against unsupported combinations of options.

• Related helper: required is more idiomatic for a single missing value; fail suits richer conditional logic.

Helm manages dependencies by declaring other charts your chart needs; the dependencies block in Chart.yaml lists each one so Helm can fetch, version-pin, and package them alongside your chart.

• Fields per dependency:

  • name, version (supports semver ranges), and repository (a repo URL or file:// path).

  • condition and tags toggle whether a subchart is enabled from values.

  • alias lets you include the same chart under a different name.

• Workflow: helm dependency update resolves and downloads them into charts/, recording exact versions in Chart.lock.

• Configuring subcharts: Parent values under a key matching the dependency name (or alias) override that subchart's values.

A subchart is a chart nested inside another chart's charts/ directory; it packages a self-contained component that the parent (umbrella) chart depends on, letting you compose applications from reusable, independently maintained pieces.

• Modularity: Each subchart owns its own templates, values, and defaults, so a database or cache is defined once and reused across many parents.

• Independence: A subchart renders standalone; it cannot see the parent's values directly, only what's passed to it.

• Value overriding: Parents override subchart values under a key named for the subchart; a special global section is shared with all subcharts.

• Sharing logic: Named templates and .Files are exported so common helpers can be reused, promoting DRY charts.

You toggle a subchart with a condition (a boolean value path) or tags (named groups) declared in the parent's Chart.yaml dependency entry; if the resolved value is false the subchart is not rendered.

• condition:

  • A comma-separated list of value paths evaluated as booleans; the first one that exists wins.

  • Typically points at the subchart's own enabled flag, e.g. mysql.enabled.

• tags:

  • Named labels shared across multiple dependencies; setting a tag false disables the whole group at once.

  • Controlled under a top-level tags: block in values.

• Precedence: condition overrides tags when both are present for a dependency.

An umbrella (parent) chart is a chart whose main job is to bundle and orchestrate multiple subcharts as a single deployable application, often with little or no templates of its own.

• Purpose: Deploy a full application stack (frontend, backend, database) with one helm install.

• Structure:

  • Lists each component as an entry in dependencies in Chart.yaml.

  • Uses its own values.yaml to configure each subchart under its name and to set global values.

• Trade-offs:

  • Simple single-release management and shared globals.

  • Can become unwieldy: all components share one release lifecycle and version, so independent upgrades are harder.

The common chart pattern (popularized by Bitnami's common chart) is a library chart of reusable template helpers that other charts import as a dependency to avoid rewriting boilerplate like names, labels, and image references.

• It is a library chart: Declared with type: library; it ships only named template helpers, no rendered Kubernetes resources.

• What it provides:

  • Standardized helpers such as common.names.fullname, common.labels.standard, and image/registry rendering.

  • Consistent conventions across many charts in an ecosystem.

• How it's used: Added as a dependency, then invoked with {{ include "common.names.fullname" . }}.

• Benefit: DRY templating and uniform behavior; bug fixes and conventions live in one place.

Chart.lock is an auto-generated file that records the exact resolved versions and repositories of a chart's dependencies, ensuring reproducible dependency builds.

• What it contains: The resolved name, repository, and concrete version of each dependency, plus a digest of the dependencies section and a generation timestamp.

• How it's created: Written by helm dependency update when it resolves version ranges from Chart.yaml.

• Why it matters:

  • helm dependency build installs exactly what it pins, so builds are deterministic across machines and CI.

  • Commit it to version control (like a package lockfile).

• Validation: The digest lets Helm detect when Chart.yaml has drifted from the lock file.

You use alias on a dependency entry to include the same subchart multiple times under different names, so each instance gets its own values scope and produces distinct resources.

• The problem it solves: Two dependency entries pointing at the same chart would otherwise collide on the same values key and name.

• How alias works:

  • Each aliased dependency is treated as a separate subchart named by its alias.

  • Its values live under the alias key in the parent's values.yaml.

• Common use case: Deploying a primary and secondary Redis, or two databases, from one chart with different configuration.

Helm hooks are annotated Kubernetes resources that Helm runs at specific points in a release lifecycle, letting you inject setup, migration, or cleanup logic around install, upgrade, rollback, and delete.

• What they are: Ordinary manifests (often a Job) marked with the helm.sh/hook annotation so Helm schedules them out of the normal apply flow.

• Common hook types:

  • pre-install: runs before any chart resources are created (e.g. provision a secret).

  • post-install: runs after resources are created (e.g. seed data).

  • pre-upgrade / post-upgrade: run around an upgrade (e.g. DB schema migration).

  • pre-rollback / post-rollback, and pre-delete / post-delete for their respective operations.

• When to use: Database migrations, backups before upgrade, one-time initialization, validation, or cleanup that must happen at a precise lifecycle moment.

Hooks look like normal manifests but are managed outside the release's normal apply/rollback flow: Helm applies them at set lifecycle points, waits on them, and does not track them as part of the release the way it tracks regular resources.

• Timing: Normal resources are applied together during install/upgrade; hooks fire at a specific phase (e.g. pre-install).

• Lifecycle management:

  • Helm does not automatically upgrade or delete hook resources with the release; you control that via delete policies.

  • They are not rolled back or pruned like tracked resources.

• Blocking behavior: Helm waits for a hook to complete/become ready before proceeding; a failed hook fails the operation.

• Ordering: Hooks use hook-weight for ordering, separate from how normal resources are installed.

Helm hooks are chart resources annotated with helm.sh/hook that Helm executes at defined moments of a release's lifecycle, enabling actions that must happen before or after core operations.

• Install events: pre-install and post-install.

• Upgrade events: pre-upgrade and post-upgrade.

• Rollback events: pre-rollback and post-rollback.

• Delete events: pre-delete and post-delete.

• test event: test runs on helm test to validate a deployed release.

Hook weights control the order hooks run in a phase, while delete policies control when Helm removes the hook resource; together they manage sequencing and cleanup.

• Hook weights (helm.sh/hook-weight):

  • String integers (negatives allowed) sorted ascending, so lower runs first.

  • Only order hooks within the same phase; Helm waits for each before the next.

• Delete policies (helm.sh/hook-delete-policy):

  • before-hook-creation: remove the prior hook before recreating (default).

  • hook-succeeded: delete after successful run.

  • hook-failed: delete on failure; combine policies as needed.

• Practical pattern: use weights to run a migration before a seeder, and before-hook-creation,hook-succeeded to avoid leftover Jobs while keeping failures for debugging.

When a hook fails, Helm marks the whole operation as failed and stops: it does not proceed to install or upgrade the remaining resources, and by default the hook's resources are left behind for debugging.

• Operation fails immediately:

  • A failing hook (a Job/Pod that exits non-zero, or times out) aborts the release; the release status becomes failed.

  • For an install, no further chart resources are applied; for an upgrade, the new revision is marked failed and the previous one remains the deployed state.

• Hook resources are not auto-deleted by default:

  • Unless a deletion policy runs, the failed hook Job stays so you can inspect logs.

  • Control this with helm.sh/hook-delete-policy (before-hook-creation, hook-succeeded, hook-failed).

• Weights and ordering matter: Hooks run in weight order; if an early hook fails, later hooks (and the main resources) never run.

• No automatic rollback: Helm leaves things in a failed state unless you pass --atomic, which triggers an automatic rollback (and cleanup) on failure.

Rollback restores a release to a previous revision using the manifests and values Helm stored for that revision. You use it to recover quickly from a bad upgrade, and Helm treats the rollback as a brand new revision rather than deleting history.

• What it does: helm rollback <release> <revision> re-applies the stored manifest of that revision (omit the number to go to the immediately previous one).

• When to use it: An upgrade broke the app, produced bad config, or left the release in a failed state and you need a known-good version fast.

• How state is managed:

  • Each release revision is stored (by default as a Secret) in the release's namespace.

  • Rolling back to revision N creates a new revision (e.g. N+1) whose content is a copy of N; nothing is erased, so you keep an auditable trail.

  • The new revision becomes deployed and the prior one becomes superseded.

• Related automation: helm upgrade --atomic automatically rolls back on failure; --cleanup-on-fail removes resources created during a failed run.

helm install only works if the release does not already exist, while helm upgrade --install installs the release if it's absent and upgrades it if it's present, making it idempotent for automation.

• helm install: Fails with an error if a release of that name already exists.

• helm upgrade --install (the --install / -i flag): If the release exists, it upgrades; if not, it performs a first install.

• When to use --install: CI/CD pipelines and GitOps where you don't want to branch on whether the release already exists: one command handles both cases safely.

helm uninstall removes all Kubernetes resources associated with a release and, by default, deletes its history so the release name is fully freed. --keep-history preserves the release records so you can inspect or roll back later.

• Default behavior:

  • Runs pre-delete / post-delete hooks, deletes the rendered resources, and purges the stored revision history.

  • The release name becomes available for reuse.

• --keep-history:

  • Removes the workloads but keeps the release records; status becomes uninstalled.

  • You can then helm rollback to restore it, and helm list --uninstalled shows it.

• Caveats: Resources not owned by Helm (e.g. PVCs from volumeClaimTemplates) may survive.

The --history-max flag caps how many revision records Helm retains per release, pruning the oldest once the limit is exceeded so release history (and stored Secrets) doesn't grow unbounded.

• What it limits:

  • The number of revision entries kept, each of which is a stored release Secret.

  • Applies on helm upgrade (and rollback), which create new revisions.

• Default value: Defaults to 10; setting 0 means unlimited history.

• Why it matters:

  • Prevents accumulation of stale Secrets in etcd that can bloat storage.

  • Trade-off: a smaller max limits how far back you can helm rollback.

Helm records each release as a versioned object stored in the cluster itself (by default in a Secret in the release's namespace), incrementing a revision number every time the release changes so it can roll back to prior states.

• Storage backend:

  • Helm 3 defaults to Kubernetes Secret objects; can be switched to ConfigMap or SQL via HELM_DRIVER.

  • Stored in the same namespace as the release (Helm 3 is namespace-scoped, no Tiller).

• Revisions:

  • Each install/upgrade/rollback creates a new revision object (v1, v2, ...).

  • Even a rollback produces a new revision that supersedes the old one rather than deleting it.

• What each record holds: the rendered manifest, supplied values, chart metadata, hooks, and status.

• Inspect with helm history <release> and helm get manifest <release>.

In Helm 3 release names are scoped per namespace, so the same name can be reused across different namespaces but must be unique within one namespace.

• Namespace-scoped (Helm 3):

  • Release state is stored in the target namespace, so uniqueness is enforced only there.

  • You can install nginx in both dev and prod simultaneously.

• Contrast with Helm 2: Names were cluster-global (Tiller held state cluster-wide), so every release name had to be unique across the whole cluster.

• Set the namespace with -n/--namespace; commands only see releases in that namespace unless you use --all-namespaces.

Charts carry a SemVer version in Chart.yaml; helm upgrade renders the new chart with your values, diffs the result against the current release, and applies the changes as a new revision.

• Two version fields:

  • version: the chart's own SemVer, what Helm uses to pick/upgrade.

  • appVersion: informational, the version of the app packaged (not used for resolution).

• What happens on upgrade:

  1. Helm fetches/uses the target chart version and re-renders templates with merged values.

  2. It performs a three-way merge (old manifest, new manifest, live cluster state) and patches only differences.

  3. A new revision is recorded; failures can be reverted with helm rollback.

• Controls and cautions:

  • Pin the version with --version for reproducibility.

  • --atomic auto-rolls-back on failure; --dry-run previews the change.

  • Immutable fields or removed CRDs can make an upgrade fail or require manual intervention.

A rollback does not delete or rewind history: it creates a brand new revision whose content matches the target revision, and appends it to the top of the history.

• It moves forward, not backward: If you are at revision 5 and run helm rollback <release> 3, Helm creates revision 6 that reapplies revision 3's manifests/values.

• Old revisions are preserved: Previous revisions stay in history (marked superseded), so you can roll back or forward again.

• Practical notes:

  • Running with no revision number rolls back to the immediately previous one.

  • Supports --wait and --atomic behaviors similar to upgrade.

helm template renders a chart's templates into plain Kubernetes YAML locally and prints it, without contacting the cluster or creating a release: it is for previewing and generating manifests, whereas install/upgrade actually deploy and track state.

• What template does:

  • Runs the template engine offline (client-side) and outputs the rendered manifests to stdout.

  • Great for debugging templating, GitOps pipelines, or piping into kubectl apply.

• Key differences from install/upgrade:

  • No release is created and no history/status is stored.

  • By default it does not query the API server, so functions like lookup return empty and cluster capabilities are guessed (use --validate to check against the API).

  • Hooks and wait logic are not executed as they would be during a real release.

--atomic makes an install or upgrade all-or-nothing: if the operation fails, Helm automatically rolls back to the previous successful state instead of leaving a broken release.

• Behavior:

  • On failure of an upgrade, it rolls back to the prior revision; on a failed install, it uninstalls the partial release.

  • Implies --wait, so Helm waits for resources to become ready before declaring success.

• Practical notes:

  • Pair with --timeout to bound how long it waits before treating the release as failed.

  • Good for CI/CD where you never want a half-applied deployment.

--wait makes Helm block until the release's resources reach a ready state before reporting success, and --wait-for-jobs extends that waiting to include Job completion.

• --wait:

  • Waits until Pods, Deployments, StatefulSets, etc. are ready (correct replica counts, PVCs bound) within --timeout.

  • Without it, Helm returns as soon as the manifests are submitted, not when they are actually running.

• --wait-for-jobs:

  • Additionally waits for Jobs to complete successfully, useful for migration or setup Jobs.

  • Only meaningful alongside --wait.

• Both honor --timeout and are commonly combined with --atomic for safe, verified deployments.

--dry-run simulates an install/upgrade and renders the templates without actually creating or changing cluster resources, letting you inspect the manifests Helm would apply.

• --dry-run (client-side):

  • Renders templates locally and prints the output plus computed release metadata.

  • Does not talk to the API server for validation, so it can miss server-side errors.

• --dry-run=server:

  • Sends the rendered manifests to the API server for validation (admission webhooks, defaulting, lookup resolution) without persisting them.

  • Catches errors a purely client-side render can't, at the cost of needing cluster access.

• Common use: preview manifests, verify overrides, and validate before a real release.

These flags control how Helm waits for readiness, handles failures, previews changes, and prepares the namespace during install/upgrade.

• --wait: Blocks until resources (Deployments, StatefulSets, etc.) reach a ready state or the timeout expires.

• --atomic: Implies --wait; if the release fails, it automatically rolls back to the previous successful state.

• --dry-run: Simulates and renders without applying, for previewing changes.

• --create-namespace: Creates the target namespace if it doesn't already exist (only on install).

• --timeout: Sets how long to wait for operations (default 5m); pairs with --wait/--atomic.

• --values/--set: Supply override values from files or inline on the command line.

• --install: On helm upgrade --install, installs the release if it doesn't exist yet (idempotent CI pattern).

Use --wait when the command should only report success once resources are actually ready, and --atomic when a failed deploy should automatically clean up by rolling back instead of leaving a broken state.

• Use --wait when:

  • Downstream steps (smoke tests, dependent releases) need pods running before proceeding.

  • You want CI to fail if the rollout never becomes ready within the timeout.

• Use --atomic when:

  • You never want a half-applied release left behind: on failure it rolls back to the last good revision.

  • Automated pipelines where manual cleanup isn't practical.

• Trade-offs: Both add wait time and depend on a sensible --timeout; a too-short timeout can cause false failures or an unwanted rollback.

The helm-diff plugin shows a diff between the currently deployed release and what an upgrade would produce, so you can review exactly which Kubernetes resources will change before applying.

• Previews changes: helm diff upgrade renders the new manifests and compares them field-by-field to the live release.

• Better than plain --dry-run: Dry-run shows the full rendered output; diff highlights only what actually differs (added, removed, changed).

• Common uses:

  • Code-review style approval in CI/CD, catching unintended changes before production upgrades.

  • Also powers change detection in tools like Helmfile.

Both flags let Helm produce a release name for you instead of requiring one on the command line: --generate-name auto-derives one, and --name-template lets you control the generated name with a Go template.

• --generate-name:

  • Tells Helm to invent a release name so you can run helm install ./chart without an explicit name argument.

  • The generated name is based on the chart name plus a random suffix (e.g. mychart-1710000000).

• --name-template:

  • Supplies a Go template used to render the name, giving you deterministic or custom naming.

  • Example: --name-template "{{ randAlpha 6 | lower }}-web".

• They are alternatives to passing a name explicitly, useful in CI where a unique name per run is needed.

--no-hooks tells Helm to run the install/upgrade/rollback/delete without executing any lifecycle hooks defined in the chart.

• What it disables:

  • Skips hook resources like pre-install, post-install, pre-upgrade, etc. (annotated with helm.sh/hook).

  • The main manifests are still applied normally; only hook execution is suppressed.

• When to use it:

  • To bypass a failing or slow hook (e.g. a broken DB migration Job) so you can deploy the rest.

  • During debugging, to isolate whether a problem comes from hooks or the main release.

  • When you intend to run migrations or setup steps manually and don't want Helm doing them.

--skip-crds prevents Helm from installing the CustomResourceDefinitions found in a chart's crds/ directory, which Helm otherwise installs automatically before the rest of the release.

• Helm's default CRD handling:

  • Files in the special crds/ directory are installed first, before templating other resources.

  • Helm never upgrades or deletes these CRDs: they are install-once, by design, to avoid destructive schema changes.

• What the flag does:

  • Skips the initial CRD install step entirely.

  • Useful when CRDs are already present (managed by a cluster admin or another tool) and you lack permission or want to avoid conflicts.

• Caveat: if the CRDs don't already exist, the release's custom resources will fail to apply.

--force on helm upgrade makes Helm replace resources via a delete-and-recreate strategy instead of a normal patch when an update can't be applied in place.

• What it does:

  • Forces resource updates through replacement, useful for immutable fields that a patch would reject.

  • Can push through an upgrade that otherwise errors out with a conflict.

• Risks:

  • Delete-and-recreate causes downtime: Pods are torn down and rebuilt rather than rolled gracefully.

  • Can delete resources with dependents (e.g. a Service losing its endpoints) or cause data loss for stateful objects.

  • Use it deliberately, not as a default fix for failed upgrades.

helm registry login authenticates Helm to an OCI-compatible registry so you can push and pull charts stored as OCI artifacts.

• What it does:

  • Stores registry credentials (in the same config Docker uses) for subsequent helm push and helm pull against oci:// references.

  • Example: helm registry login registry.example.com -u user -p pass.

• When it's needed:

  • Whenever the OCI registry (ECR, GHCR, Harbor, etc.) requires authentication to access charts.

  • Not needed for classic HTTP chart repositories added via helm repo add, which handle auth differently.

• Log out with helm registry logout to clear the stored credentials.

A classic Helm repo is just a set of packaged charts plus an index.yaml served over HTTP, so any static file host works; OCI registries are the modern alternative.

• Build the repo contents:

  1. Package charts with helm package into .tgz files.

  2. Generate the index with helm repo index . (use --url to set the base download URL).

  3. Upload the .tgz files and index.yaml to the host.

• Static hosting options: GitHub Pages, S3/GCS buckets, or any web server: the repo is just static files.

• Purpose-built tools: ChartMuseum (an API-driven chart server), plugins like helm-s3 and helm-gcs, or products like Harbor and JFrog Artifactory.

• OCI registries: Push charts with helm push to any OCI-compliant registry, avoiding index maintenance entirely.

With OCI support, charts are treated as OCI artifacts stored in a container registry: helm push uploads a packaged chart to a registry and helm pull downloads it, both using oci:// references instead of a repo index.

• You package first, then push:

  • helm package mychart produces a .tgz, then helm push mychart-1.0.0.tgz oci://registry.example.com/charts uploads it.

  • The chart name and version become the artifact repository and tag in the registry.

• Pulling and installing reference the artifact directly:

  • helm pull oci://registry.example.com/charts/mychart --version 1.0.0 downloads it; helm install can take the same oci:// URL.

  • No helm repo add or index.yaml is involved: the registry itself lists versions.

• Authentication reuses registry login: helm registry login stores credentials so push/pull work against private registries.

index.yaml is the catalog of a classic (HTTP) chart repository: it lists every chart, its available versions, and where to download each package, so Helm clients can discover and fetch charts.

• What it holds: Per version: name, version, appVersion, the download urls, a digest (SHA-256), and creation timestamp.

• How it is generated:

  • helm repo index <dir> scans a directory of packaged .tgz charts and writes index.yaml.

  • Use --url to set the base download URL for the packages.

• How it is updated: helm repo index --merge existing-index.yaml adds new charts while preserving existing entries, so you don't lose old versions.

• How clients use it: helm repo add fetches this file, and helm repo update refreshes the local cached copy for search and install.

The helm-git plugin lets you use a Git repository directly as a chart source, so you can install charts straight from Git without publishing them to a chart repository or OCI registry.

• Adds a git:// protocol to Helm: You reference charts with URLs like git+https://github.com/org/repo@path/to/chart?ref=main.

• Pin to any Git ref: Point at a branch, tag, or commit to lock a specific chart version from source control.

• Useful cases:

  • Consuming charts that live in a repo but were never packaged or published.

  • Declaring Git-based charts as dependencies in Chart.yaml.

• Trade-off: No index or provenance semantics: it's convenience for source-based workflows, not a substitute for a managed registry.

Helm 3 removed the server-side component and made Helm a client-only tool that talks directly to the Kubernetes API, along with security, storage, and CLI improvements over Helm 2.

• No Tiller: Helm 2 needed the in-cluster Tiller server; Helm 3 uses the caller's kubeconfig and RBAC directly.

• Release storage: Helm 2 stored releases in ConfigMaps in Tiller's namespace; Helm 3 stores them as Secrets in the release's own namespace.

• Namespace-scoped releases: Release names are unique per namespace in Helm 3, not cluster-wide.

• Chart schema and validation: Helm 3 adds JSON Schema validation for values.yaml and uses apiVersion: v2 charts with dependencies in Chart.yaml (no separate requirements.yaml).

• OCI and CLI changes: Native OCI registry support, three-way strategic merge on upgrade, and helm init is gone.

Tiller was Helm 2's in-cluster server component that received commands from the client and applied resources to Kubernetes on your behalf; it was removed in Helm 3 mainly because of its security model.

• What it did: Ran as a pod in the cluster, stored release state, and executed installs/upgrades/rollbacks requested by the helm client.

• Why it was a problem:

  • It typically ran with broad, often cluster-admin, permissions, so anyone who could reach Tiller effectively inherited those rights.

  • It bypassed Kubernetes RBAC: Tiller's identity was used, not the actual user's, making access control hard to reason about.

  • Securing the gRPC channel with TLS was extra, error-prone setup.

• The Helm 3 fix: The client talks directly to the API server using the user's own kubeconfig and RBAC, so permissions match the person running the command.

In Helm 2 release names were global across the whole cluster; in Helm 3 they are scoped to a Kubernetes namespace, so the same name can exist in different namespaces.

• Helm 2: cluster-wide names:

  • Tiller tracked all releases centrally, so a release name had to be unique across the entire cluster.

  • Two teams in different namespaces could not both use a name like web.

• Helm 3: namespace-scoped names:

  • Release metadata lives in the release's own namespace, so names only need to be unique per namespace.

  • This aligns Helm with normal Kubernetes RBAC and multi-tenancy.

• Practical effect: helm list shows releases in the current namespace, and --namespace (or -A) controls scope.

Helm 3 is a pure client that talks directly to the Kubernetes API server using your kubeconfig, with no in-cluster server component to broker requests.

• Direct API access: The helm binary reads the same kubeconfig as kubectl and calls the API server directly.

• Identity and permissions: Actions run as the user's credentials, so Kubernetes RBAC governs exactly what Helm can do.

• Template rendering is local: Charts are rendered on the client into manifests, then applied to the cluster.

• State lives in the cluster: Release history is stored as Kubernetes objects (Secrets by default) rather than by a Helm daemon.

Tiller ran in-cluster with broad privileges and acted on behalf of all users, which broke least-privilege and made proper RBAC and auditing very hard.

• Over-privileged service account: Tiller was commonly given cluster-admin so it could deploy anything anywhere.

• Loss of user identity:

  • Requests were performed as Tiller, not the actual user, so RBAC could not restrict what a given user could deploy.

  • Audit logs showed Tiller as the actor, hiding who did what.

• Exposed attack surface: Its gRPC endpoint, if not locked down with TLS and auth, let anyone in the cluster escalate privileges through Tiller.

• Operational burden: Securing it required managing certificates and per-namespace Tiller installs.

In Helm 2 the client had no direct authority over the cluster, so Tiller was the in-cluster server that received chart data, rendered/applied it, and stored release state.

• Bridge to the API server: The client sent requests to Tiller, which used its own service account to create and update Kubernetes resources.

• Release state manager: Tiller tracked release history and versions (as ConfigMaps) so it could handle upgrades and rollbacks.

• Server-side rendering: Templates were combined with values inside the cluster by Tiller.

• Why it went away: Once Helm 3 used the user's kubeconfig directly, this server role was unnecessary.

Helm 3 stores release information in Kubernetes Secrets by default, whereas Helm 2 stored it in ConfigMaps managed by Tiller.

• Helm 3 default: Secrets: Stored in the release namespace, one Secret per revision, base64-encoded and better isolated by RBAC.

• Helm 2 default: ConfigMaps: Kept in Tiller's namespace (usually kube-system), tied to the Tiller server.

• Configurable drivers: Helm 3 supports secret, configmap, and sql via HELM_DRIVER (the SQL driver helps with large release histories).

Dependency management moved from the requirements.yaml file (Helm 2) into the main Chart.yaml (Helm 3), and the lock file was renamed accordingly.

• Helm 2 approach:

  • Dependencies were declared in a separate requirements.yaml, with the resolved versions pinned in requirements.lock.

  • Managed with helm dependency update.

• Helm 3 approach:

  • Dependencies live under the dependencies: key directly in Chart.yaml, and the lock file is Chart.lock.

  • apiVersion: v2 in Chart.yaml signals this format; apiVersion: v1 charts still use requirements.yaml for backward compatibility.

• Unchanged concepts: Subcharts are still stored under charts/, and conditions/tags for toggling dependencies still work.

Helm 2 auto-created the release namespace if it did not exist; Helm 3 does not by default and will fail unless you pass --create-namespace or create it yourself.

• Helm 2 behavior: Silently created the target namespace during helm install, which could mask mistakes.

• Helm 3 behavior:

  • Assumes the namespace exists; installing into a missing namespace errors out.

  • Use helm install myapp ./chart -n prod --create-namespace to have Helm create it.

• Why the change: More explicit and safer: it aligns Helm with standard kubectl behavior and prevents accidental namespace sprawl.

Both versions install CRDs before other resources, but Helm 3 moved them to a dedicated crds/ directory with deliberately limited lifecycle management to avoid destroying data.

• Helm 2: CRDs were regular templated manifests, often using the crd-install hook to install them first.

• Helm 3:

  • CRDs go in a special crds/ folder as plain YAML (no templating, no hooks).

  • They are installed before templates and only on install.

• Key limitations to know:

  • CRDs are never upgraded, rolled back, or deleted by Helm: this protects the custom resource data owned by them.

  • To change a CRD you must update it manually with kubectl.

helm test runs test Pods you define in your chart to verify a release actually works after install; the tests are templates annotated as hooks and are executed on demand.

• How it works:

  • A test is a Pod (or Job) manifest with the annotation helm.sh/hook: test, conventionally placed under templates/tests/.

  • Running helm test <release> creates those Pods; a Pod exiting 0 passes, nonzero fails.

• Writing a test:

  • Typically a container that probes the service (e.g. wget or curl against the release's endpoint) and exits based on success.

  • Use helm.sh/hook-delete-policy to control cleanup of the test Pod.

Debug a failing deployment by first inspecting what Helm actually rendered and sent, then what Kubernetes did with it, working from template output down to runtime Pod state.

• Inspect the rendered manifests:

  • helm template ./chart or helm install --dry-run --debug shows the final YAML and surfaces template errors.

  • --debug adds verbose output including computed values.

• Check release state:

  • helm status <release> and helm get manifest / values / all <release> show what was actually deployed.

  • helm history <release> reveals failed revisions to roll back from.

• Drop to the cluster layer:

  • kubectl get / describe on the resources to see scheduling, image-pull, or probe failures.

  • kubectl logs for application-level errors inside the Pods.

• Common culprits:

  • Bad values overrides, failing hooks (e.g. a broken pre-install hook blocks the whole install), or invalid rendered manifests.

  • Use --atomic to auto-rollback on failure and --wait to surface readiness issues.