How To Continuously Test and Deploy Your Helm Charts on Kubernetes Clusters Using Kind

Set up your CI/CD tools to easily test and publish charts on ephemeral Kubernetes clusters

Photo by Markus Winkler on Unsplash.

When you are packaging your application for Kubernetes, you generally have two options:

• Helm uses templates and a package manager-like approach to bundle applications as “charts”.
• Kustomize allows you to patch your original resources to produce new manifests and reach the desired configuration.

However, Helm and Kustomize are not mutually exclusive and you may benefit from both of them at the same time. For example, you could generate the bulk of your resources using Helm templating and do some ad hoc patching using Kustomize on the generated manifests.

Whatever technology you are using, you build charts or “Kustomization” to package your applications. Then, you can distribute them, but are you sure they are working as intended? Can they be deployed without error in a Kubernetes cluster? Or in your customers’ clusters with their variety of API versions?

In this article, I will show you how to build, test, and continuously deploy your Helm applications against real Kubernetes clusters.

Table of Contents

1. Helm Basics
2. Considering a CI/CD Approach for Charts
3. Choosing the Right Tools
4. Writing the Build, Test, and Deploy Jobs
5. Handling Multiple Versions of Kubernetes
6. Publishing the Chart

Helm Basics

Let’s quickly review the Helm fundamentals:

• Helm is templating tool: A Helm chart is made of Golang templates of Kubernetes manifests and a Chart.yaml metadata descriptor with things like the chart name and version.
• Helm is a packaging tool: Your chart is packaged as a tar archive and uploaded to a remote versioned Helm repository. Helm then allows you to push or pull the chart from repositories.
• Helm is a deployment tool: You give the Helm CLI a chart and value replacements as a…