Helm v4: Exploring Key Differences from Helm v3

Helm v4, the first major release in six years, is finally here. This article dives into the key changes, including the switch to Server-Side Apply, the introduction of WASM plugins, a new resource readiness engine, and content-based chart caching. We'll also explore the persistent challenges Helm still faces.

Server-Side Apply Replaces 3-Way Merge

Server-Side Apply (SSA), a resource update mechanism introduced in Kubernetes 1.14, is now the standard in Helm. It replaces the old 3-Way Merge (3WM) strategy, which often caused incorrect resource updates. For example, 3WM could fail to remove a field that was deleted from a chart because it couldn't reliably track changes between releases.

SSA solves this by offloading the heavy lifting. Instead of calculating patches itself, Helm now sends the entire manifest to the Kubernetes API, which then computes and applies the necessary changes. You can enable SSA using the --server-side=true flag:

To automatically resolve conflicts by always prioritizing the rendered manifest, use the --force-conflicts flag. This is disabled by default, but we recommend enabling it for smoother workflows.

Enhanced Extensibility with WASM Plugins

Helm 4 introduces support for WASM plugins alongside the existing plugin system. While the user experience remains similar, this change provides a much more powerful API for plugin developers. Plugins now come in three types:

• CLI plugins: Function like Helm 3 plugins, executing a command with arguments passed from Helm.
• Post-renderer plugins: Run after manifest templating to modify resources before deployment, perfect for patching.
• Getter plugins: Triggered when fetching charts or subcharts, allowing you to load charts from custom sources like Git or S3.

While official documentation is still sparse, you can find more details in the official HIP proposal.

Smarter Deployments with kstatus

In Helm 3, the --wait flag enabled basic readiness checks for a limited set of resources like Deployments and StatefulSets. Helm 4 replaces this homegrown solution with kstatus, a standard library for determining resource status. For users, this means more accurate and reliable readiness checks.

You can enable kstatus-powered waiting for all resources, not just hooks, with the --wait=watcher flag:

Efficient Caching via Content Hashes

Helm 3 cached downloaded charts by name and version. Unfortunately, this wasn't enough to uniquely identify them, forcing Helm to distrust its own cache and frequently re-download charts.

Helm 4 fixes this by identifying charts with a hash of their content, ensuring that cached charts can be reliably reused. Note that this new caching mechanism does not yet apply to OCI charts.

Other Notable Changes

• New template functions: mustToYaml and mustToJson.
• OCI charts can now be installed by their digest.
• Post-renderers now work with hooks.
• The Helm SDK has been made easier to use.
• values.yaml can now contain multiple YAML documents separated by ---.
• A new apiVersion: v3 for Chart.yaml is available, which removes support for requirements.yaml and requirements.lock.

The Final Verdict

Most changes in Helm 4 focus on paying down technical debt by replacing legacy components with modern standards. For end-users, the main benefit is finally moving past the pitfalls of 3-Way Merge.

For a comprehensive overview, check out the official Major Changes Summary or the detailed full changelog.

#helm #news