Kubernetes doesn’t have reproducibility built-in.
At least, that’s what we hear most people complain as a cloud native consultation firm serving both startups and enterprises.
I have been using Kubernetes for a while now, and it stands up to the mark of being a gold standard container orchestration tool. Sharing is caring, so I wrote a blog about it too.
A thing people often forget is that Kubernetes never was intended to have reproducibility in its scope. Still, its presence under CNCF ☂ makes it natively compatible with other projects specializing in managing reproducibility.
So, in this post, let’s dive in through a CNCF graduated project that supports k8s natively and can be a solution to all your reproducibility problems.
How does one get reproducibility from k8s?
The answer is simple, use a package manager that would install packages in your cluster.
The package would contain a reproducible template that can be used to create your entire scalable infrastructure with one command and remove the manual effort of listing each file using kubectl.
The CNCF ☂ provides you with a project named Helm. Learn more about CNCF here.
What is Helm?
Helm is a package manager that has native support for Kubernetes (from the 1.4 release). Now a graduated CNCF project, Helm resulted from a collaboration between Deis (a container tooling business that Microsoft now owns) and Google.
Helm allows you to install packages in your cluster, much like you would use apt, yum on your laptop. Just define the components that you want to install in your application, and it will take care of the installation and configuration of these components, saving you from headaches.
Despite its appearance, its reach extends well beyond that of a mere package manager. It’s a breathing project and changes heavily from version to version, with more functionalities added to it with the subsequent release. However, let’s start at the beginning and understand what’s capable of with a high-level overview.
Helm: The package manager for Kubernetes
DevOps teams use Kubernetes YAML files to configure Kubernetes workload. These YAML files define everything required for container deployment. Everything from how each Pod must be configured to how the Kubernetes cluster handles load balancing must be specified in those YAML files.
As a result, in order to set up a new Kubernetes workload, you must first build a YAML file for that workload. To do it manually, you’ll need to create multiple YAML files, one for each task.
Rather than writing individual YAML files for each application, you can create a Helm chart and let Helm deploy the application to the cluster for you. Helm charts are collections of templates for multiple Kubernetes resources that work together to construct an application. When deploying a Helm chart on several Kubernetes clusters, it can be customized. Helm charts can be built in such a way that environment or deployment-specific configurations can be extracted to a separate file, and afterward, these values can be specified when the Helm chart is deployed.
You can use one chart with different variables in your development, staging, and production environments—no need for multiple charts.
Now that you’ve generated your chart, what should you do? You upload it to a repository.
Is it necessary to download the entire repository to install those charts? No way! Helm includes a public library for the most often used charts, similar to Docker Hub.
You can also construct and host your own chart repository online and download charts from these repositories. You would find most of the charts required by you already hosted on the Helm repository. Explore the repository here.
Because a chart repository is essentially an
index.yaml file served from a static web server, you can make one anywhere you want. This allows you to have a private chart on your intranet or local server.
You can also try other open-source alternatives like ChartMuseum, an open-source Helm Chart Repository server written in Go (Golang), with support for cloud storage backends, including Google Cloud Storage, Amazon S3, Microsoft Azure Blob Storage, and other cloud providers.
Helm has the ability to adjust application configurations during deployment. The DevOps team may set the Kubernetes resources used in the application and all of the environment-specific needs for those resources. This allows teams to reuse a single Helm chart across many environments and easily update dependencies of previously deployed infrastructure.
Helm keeps track of all the versions of your releases in a database. So, if something goes wrong during deployment, reverting to the prior version is as simple as one command.
Troubleshooting and Debugging
If I am honest, Helm is quite complex. As the entire system is dependent on templating Helm charts, it is complicated to design and debug big applications that may include several Kubernetes resources. The more Helm charts there are, the more complicated the system becomes. Consider how long it would take a team to identify and fix a bug in a Helm chart template that has been used several times across several Kubernetes resources in a complicated application.
Helm makes it easier to manage Kubernetes clusters. However, producing the first Helm chart is not as straightforward as running a few commands. The procedure is highly complex, with a high learning curve that may take some time for DevOps teams to adjust. Helm aims to make things as simple as possible by providing extensive documentation on how to perform things.
With its versioned charts, Helm has proven to be a valuable tool in maintaining today’s complex infrastructures. Furthermore, the project has reduced the time it takes to develop environments in production services and locally.
Another option for reproducibility is to use Kustomize, a template-free way to customize application configurations and manage Kubernetes workloads. Both Helm and Kustomize are used depending upon use cases, and let’s keep the details for some other day.
Feel free to try Helm out and we are a text away if you want help accelerating your cloud native or reproducibility adoption.
You can check a few of our recent deep dives here: