Fundamentals of Helm

Fundamentals of Helm encompass the core concepts, components, and operational models that enable Helm to function as a package manager for Kubernetes, simplifying the deployment, management, and upgrade of containerized applications. Helm abstracts complex Kubernetes manifests into reusable, configurable packages called charts, streamlining application lifecycle management.

Helm Installation

Client and Server Components

Helm operates primarily as a client-side tool, with the Helm client interacting directly with the Kubernetes API server. Earlier Helm versions (prior to Helm 3) required a server-side component called Tiller, but modern Helm versions have eliminated Tiller, improving security and simplifying architecture.

Installation Methods

Helm can be installed on various operating systems through official binaries, package managers (such as Homebrew for macOS, Chocolatey for Windows, or apt for Debian-based Linux), or by building from source. Once installed, Helm interacts with Kubernetes clusters using kubeconfig settings.

Verifying Installation

After installation, the helm version command confirms the Helm client version and connection status to the Kubernetes cluster.

Application Packaging Model

Charts

A Helm chart is a directory containing a collection of files that describe a related set of Kubernetes resources. It encapsulates all necessary manifests, templates, and metadata needed to deploy an application or service.

Chart Structure

Typical files and directories in a chart include:

• Chart.yaml: Contains metadata such as chart name, version, description, and maintainers.
• values.yaml: Defines default configuration values that can be overridden by users.
• templates/: Contains Kubernetes manifest templates that use Helm’s templating language.
• charts/: Optional subcharts or dependencies.
• README.md: Documentation for the chart.

Chart Dependencies

Charts can declare dependencies on other charts, allowing modularity and reuse. Dependencies are managed in Chart.yaml and can be updated or vendored into the chart source.

Configuration Model

Values and Overrides

Helm allows customization of charts through configuration values defined in values.yaml. Users can override these defaults during installation or upgrade by providing custom values files or setting individual values via command-line options.

Template Variables

Templates access configuration values using a key-value map. Variables can represent strings, numbers, booleans, lists, or dictionaries, enabling dynamic resource generation based on user input or defaults.

Conditional Logic and Control Structures

Helm templates support conditional statements (if, else), loops (range), and other control structures to generate manifests conditionally or iteratively, enhancing flexibility.

Rendering Model

Template Rendering Process

When a Helm command is executed to install or upgrade a release, Helm processes chart templates by rendering them with the configured values. This produces a set of Kubernetes manifests in YAML format.

Go Templating Engine

Helm’s rendering engine is based on Go templates, augmented with custom functions that facilitate Kubernetes-specific operations such as generating resource names, including other templates, or manipulating strings and data structures.

Output Artifacts

The rendered manifests are then either applied directly to the cluster or output to stdout for inspection or further processing.

Release Management Model

Releases

A release is a particular deployment of a chart with a specific configuration in a Kubernetes cluster. Multiple releases of the same chart can coexist in a cluster, each identified by a unique release name.

Lifecycle Operations

Helm manages the lifecycle of releases, supporting operations such as install, upgrade, rollback, and uninstall. These operations modify the Kubernetes resources associated with the release accordingly.

Revision History

Helm tracks revisions of releases, enabling users to roll back to previous states if necessary. Each upgrade increments the revision number, maintaining a history of changes.

Resource Ownership Model

Ownership and Garbage Collection

Helm labels Kubernetes resources it manages with metadata that associates them with releases. This metadata enables Helm to identify and manage these resources during upgrades or uninstalls.

Hooks and Lifecycle Events

Helm supports hooks—special Kubernetes resources executed at certain points in a release lifecycle (e.g., pre-install, post-upgrade)—allowing custom actions and workflows to be integrated into deployments.

Namespace Model

Namespace Scoping

Helm releases are deployed into specific Kubernetes namespaces. Namespaces provide scope and isolation for resources, enabling multiple releases or applications to coexist without conflict.

Cross-Namespace Operations

While Helm can interact with multiple namespaces, each release is namespace-scoped. Helm commands typically specify the target namespace, defaulting to the current Kubernetes context namespace if not provided.

Client-Side Operation

Interaction with Kubernetes API

The Helm client communicates directly with the Kubernetes API server using credentials and context from the kubeconfig file. This direct client-side interaction eliminates the need for a server-side component.

Local State Management

Helm stores release information locally as well as in Kubernetes secrets or ConfigMaps within the cluster, enabling state tracking and synchronization between client and cluster state.

Helm State Model

Storage Backends

Helm stores release information as Kubernetes Secrets or ConfigMaps in the cluster namespace where the release is deployed. This storage maintains metadata about deployed resources, revisions, and configuration.

State Consistency

The state model ensures consistency between the deployed resources and Helm’s internal records, allowing safe upgrades and rollbacks.

Security Considerations

Storing release data in Kubernetes objects limits the attack surface by avoiding persistent external storage, and access to release data is controlled by Kubernetes RBAC policies.

The fundamentals of Helm provide a comprehensive abstraction over Kubernetes resource management, enabling developers and operators to package, configure, deploy, and maintain applications with ease and repeatability. Through its packaging model, templating mechanisms, and release management capabilities, Helm significantly enhances Kubernetes usability and operational efficiency.