Introduction

In this tutorial, we will explore the helm template command and understand why it is useful in Helm-based Kubernetes deployments. The Helm team initially introduced the --dry-run option to help debug templates before installation or upgrade. However, teams started using these generated templates directly with kubectl, leading to unexpected issues. To address these concerns, Helm provides the helm template command.

Why Use helm template?

The helm template command is an alternative to helm install --dry-run that does not perform any validation, unlike --dry-run, which contacts the Kubernetes API server to validate templates. that allows users to generate Kubernetes manifests from Helm charts without requiring a connection to a Kubernetes cluster. This is particularly useful for CI/CD pipelines and environments where direct cluster access is unavailable.

Issues with --dry-run

Many users attempted to use helm install --dry-run for purposes other than debugging, such as extracting the generated YAML templates and applying them with kubectl. However, this approach has the following drawbacks:

1. Non-YAML Syntax in Output: The --dry-run command includes metadata such as release notes, which are not valid YAML syntax. Copying and using this output directly can lead to issues.
2. Different Behavior for Install and Upgrade:
   • When used with helm install --dry-run, the output includes all necessary configurations for a fresh installation.
   • When used with helm upgrade --dry-run, only the differences from the previous installation are included, which can be confusing.
3. Requires Kubernetes Cluster Access: The --dry-run command communicates with the Kubernetes API server to validate the generated templates. This requires an active cluster and appropriate connection settings.

Introducing helm template

To overcome these challenges, Helm provides the helm template command:

Basic Syntax

How helm template Works

• It processes the first four phases of the Helm rendering process, just like --dry-run, but differs in key aspects:
  1. No Release Metadata: Unlike --dry-run, helm template does not include release-related information such as release notes.
  2. No API Server Communication: helm template does not require an active Kubernetes cluster, making it ideal for environments without direct cluster access.
  3. Acts Only as an Installation: Unlike --dry-run, which behaves differently for installs and upgrades, helm template always generates templates as if it were a new installation.
  4. Handles Kubernetes Functions Differently: Any Helm charts containing Kubernetes-specific functions (e.g., fetching data dynamically from the cluster) will replace these functions with default values instead of querying the cluster.

Use Cases for helm template

• CI/CD Pipelines: Generate Kubernetes manifests without requiring direct cluster access.
• Manual Validation: Review and modify Helm-generated YAML before applying it with kubectl.
• Configuration Management: Store rendered YAML files in version control for auditing and reproducibility.

Conclusion

The helm template command provides a robust alternative to helm install --dry-run, eliminating issues with YAML formatting, upgrade inconsistencies, and cluster dependency. It is a powerful tool for Kubernetes administrators and developers who need Helm-generated templates without deploying them immediately.

In the next tutorial, we will compare helm template and helm --dry-run in detail, highlighting their differences with practical examples.