Helm Template
Helm templates are indispensable Kubernetes manifest files that describe resources you want on the cluster for GitOps-driven automation.
Further reading
Kubernetes gained popularity as it simplifies the scalability and management of containerized applications. It enables you to deploy and manage nodes, pods, containers, services, and configuration maps across the entire application lifecycle. It was difficult to achieve such flexibility and control with scripts. But thanks to Kubernetes’ declarative approach to infrastructure, you can define precise changes at any scale. Kubernetes also empowers you to integrate multiple tools to facilitate automated scheduling, deployment, monitoring for the containers. One such tool is Helm, a CNCF adopted automation framework that has gained popularity not just in Kubernetes circles, but in the GitOps ecosystem as well. In this post, we look at how Helm helps automate the deployment of cloud-native applications on Kubernetes the GitOps way.
What is Helm?
Although described as a package manager, Helm is a powerful tool to automate installation, deployment, upgrade and management of Kubernetes applications. Managing Kubernetes manifests is a task that grows in complexity as systems scale. A single deployment needs multiple YAML files with duplicated and hardcoded values. This required a better way to manage Kubernetes YAML files through a simple packaging format, which led to Helm Charts. However, Helm’s scope goes beyond templating.
What are Helm Charts?
Helm Charts are deployable units for Kubernetes applications. Each chart can contain the files, metadata, and infrastructure of the application. Written in Go, Charts are stored in specific template directories along with associated variables, versions, and descriptions. These Charts can be shared across your development team for reusability by storing them as archives in a Repository.
Once a copy of a Chart is installed in the Kubernetes cluster, it is called a Release. A new release is created every time the Chart is deployed, which can happen multiple times. Releases help you track and install Charts.
Below is the structure of Helm charts, as described by the Charts Guide:
- Chart.yaml: The main file that holds the description of your chart
- Values.yaml: A file that contains the default values of your chart
- Charts: A directory that houses sub-charts
- Templates: A directory where Kubernetes resources are defined as templates
What is a Helm Template?
Helm templates are indispensable Kubernetes manifest files that describe your wanted resources on the cluster. A template folder contains the application’s configuration files, which will be deployed to the cluster. The files within the templates directory call their values from values.yaml.
When Helm evaluates a chart, it will send all the files listed in the templates directory through the template rendering engine. All of the template results are then collected and sent on to Kubernetes.
Structure of a Helm Template
The template directory should be structured with these guidelines from Helm.sh:
- Template files should have the extension .yaml if they produce YAML output. The extension .tpl can be used for template files that produce no formatted content.
- Template file names should use dashed notation (my-example-configmap.yaml), not camelcase.
- Each resource definition should be in its own template file.
- Template file names should reflect the resource kind in the name. e.g. foo-pod.yaml, bar-svc.yaml
Why Helm?
Helm adds great value to a continuous delivery ecosystem as it brings the below benefits.
- Improved productivity: Helm (along with other deployment tools like Flux) allows you to deploy software with just a click of a button or a single command. This will help your team to direct focus solely on software development.
- Simplifies process: The concept of charts allows you to duplicate the same chart across the pipeline - development, test, and production - or across different teams’ workflow. This significantly reduces complexity.
- Scalability: Charts are designed to align with Kubernetes cluster architecture, which eases scalability.
- Easy rollback: Since Helm manages all releases, it helps you roll back changes easily when there are issues.
GitOps leverages both Helm & Flux
Helm can manage complex releases and keep things simple as you scale. However, when changes are introduced progressively, Helm will need additional tools to keep the Kubernetes cluster updated. Flux is a great complementary solution to Helm as it acts as a bridge between Helm and the all-important Git repositories from where the entire Kubernetes cluster and app spec are defined.
Flux is a deployment automation solution based on the GitOps model that puts Git in focus as the starting point, and source of truth for all changes. Flux enables you to maintain consistency between code repositories and Kubernetes clusters, and automates deployments when code changes are introduced.
In a nutshell, Flux automates Helm Chart releases by synchronizing Charts from Git to the Kubernetes cluster.
Learn more about Flux CD and it's integration with Helm in this comprehensive technology page: "What is Flux CD?"
How does Flux work with Helm?
In order to use Flux as the GitOps operator, you store all Helm Charts along with their YAML files and Kubernetes custom resources in a Git repository. Also, you push immutable images of these resources to a container registry.
Once you commit a change in Git via a 'pull’ request, Flux checks your repository and provides the required resources. The changes are then merged into the production cluster. This, of course, simplifies the process and there is a lot more you can do along the way - such as run smoke tests, or have an SRE approve specific changes - but we’ll keep it simple for now.
If you want to learn more about how Flux 2 and Helm work together to increase velocity, and reliability while decreasing downtime, watch this youtube talk by Scott Rigby.
Things to watch out for: Security guardrails
Both Helm and Flux ensure that a single source of truth is maintained through a Git-based source control system. They ensure that the system remains in sync with the desired state via templates and manifests stored in repositories. However, adding effective security guardrails is critical to prevent misconfigurations
To better understand security implications, identify risks and implement best practices, it takes a policy-based security enforcement platform like Weave Policy Engine. The policy engine will check Helm charts against 100s of out-of-the-box policies for Kubernetes deployments and deliver immediate feedback on policy violations. It enables visibility into Kubernetes clusters and enforces security and compliance policies - such as CIS, PCI DSS, and MITRE ATT&CK - policies on deployments.
Conclusion
Helm reduces the complexity of operating Kubernetes significantly. It adds great value to the GitOps pipeline with the concept of Charts or templates. Having said so, there are other needs beyond templating, such as end-to-end deployment automation. This is where tools like Weave GitOps Enterprise and Flux are essential to make the most of Helm. Additionally, the integration security guardrails via the Weave Policy Engine ensures Helm releases are compliant and secure.
Weave GitOps is a continuous delivery solution that helps manage Kubernetes at scale. It eases the adoption and execution of GitOps in any organization. Weave GitOps simplifies operations clusters with commands such as ‘gitops install’ to enable GitOps and ‘gitops add app’ to add your application. These commands abstract away the underlying complex tasks that are otherwise involved in deployment automation. Weave GitOps brings together the entire GitOps pipeline including Helm, Flux, and more — so you can get started with GitOps without wasting any time.
Further reading
Helm Charts in Kubernetes
Putting Helm at the Heart of your GitOps Pipeline
Managing Helm Deployment and Releases with GitOps
