How Acorn and Helm are Different

In this post we are going to discuss about how Acorn Images and Helm Charts differ in its goals and aproaches for simplifying the app provisioning process.

Helm

Helm is well known open-source package manager created in 2015. In 2018, Helm has joined CNCF incubating projects and reached the graduated level in 2020.

At the time Helm went public, Kubernetes was still in its first steps and had not yet established itself as the standard container orchestrator solution as we have it today, solutions to pack and deliver apps in a Kubernetes cluster were not widely available and Helm was presented at that time as the best solution available to achieve this goal.

Challenges working with Helm

When an application is already available in Helm Chart format, it is easy to provision and update it in a cluster, as we only need to apply the defined template passing the necessary variables.

But...

For a developer who just wants to get their application up and running on a Kubernetes cluster, how difficult it is to create, maintain, and track release version of a helm chart?

Is Helm the easiest way to get an application up and running on a Kubernetes cluster without requiring much Kubernetes knowledge?

The basic idea of working with a Helm chart is to create a repo with a particular directory tree, different from the original repository where the app code is, which includes all the Kubernetes yaml files in a templates folder and a Values file to control each configured parameter. Because of that, configuring templates requires in-depth knowledge of Kubernetes, as the Deployment, DeamonSet, Service, Ingress, ConfigMap, Secret, and all the other objects required by the application needs to be declared and configured.

The Helm directory tree requires at least the following structure with all the kubernetes yaml files inside a template’s folder.

DemoApp/ Chart.yaml
values.yaml
charts/ crds/
templates/ deployment.yaml hpa.yaml ingress.yaml service.yaml serviceaccount.yaml

In addition to demanding all knowledge of Kubernetes objects, a helm chart only describes how the app will to be provisioned referencing the images that will be used, the idea of building a container image is outside the scope of a helm chart and must be done in a different process. Which is usually done setting up multiple pipelines for each container image that is associated to the application and storing it in a container registry.

As the application grows, the Helm chart becomes more difficult to manage, as multiple templates files are created, and multiples values are passed to multiple files. This complexity makes it difficult to identify security problems, such as containers configured to run with privileged access or even the existence of components that are not necessary for running the application, resulting in the need for external tools to validate the application’s configuration.

For a developer who just wants their application to run on a cluster, learning and managing a Helm Chart becomes a tedious activity requiring hours of effort.

Acorn Images

Acorn was born with all these challenges in mind, with the aim of simplifying the entire process that developers must follow to get their applications up and running.

The Acorn Runtime creates an abstraction layer on top of the Kubernetes cluster and eliminates the need to work directly with Kubernetes objects. Instead of having a completely different repository to store Kubernetes files in a specific structure, Acorn only requires a single Acornfile where the process of building the images and publishing the application are described in a declarative way that is simplified and easy to understand for anyone with experience in yaml files. Acorn Images are the output of Acorn Files, and can encapsulate not only containers, but all of the configuration detail required in a deployment. Acorn Images can be nested within an Acorn File, making deploying complex applications easy, and allowing teams to leverage existing work.

args: { // defines arguments the consumer can provide } profiles: { // defines a set of default arguments for different deployment types } containers: { // defines the containers to run the application } volumes: { // defines persistent storage volumes for the containers to consume } jobs: { // defines tasks to run on changes or via cron } acorns: { // other Acorn applications that need to be deployed with your app (databases, etc.) } secrets: { // defines secret bits of data that are automatically generated or passed by the user } localData: { // default data and configuration variables } While helm requires multiple container images to be created and published to registries, Acorn simplifies this process by creating a single acorn image containing all the docker images needed to run the application which can be stored in any oci-compliant registry.

When running an Acorn Image on a Kubernetes cluster, the Acorn Runtime handles the entire process of creating the Kubernetes objects needed to run the application, as well as updating and removing it. In addition, this construction of objects is done taking into account the best security practices with restriction of container privileges, generation of secrets, correct configuration and association of ServiceAccount, and restriction of service ports.

Acorn leverages all the Kubernetes evolution over the past few years to deliver a streamlined, consistent, and secure provisioning experience that removes the need for in-depth Kubernetes knowledge.

Conclusion

While these Acorn Images and Helm Charts are two different ways to create and deploy containerized applications to Kubernetes, they server very different audiences. Helm charts are a complete expression of the Kubernetes API, and appropriate for users who already have experience with Kubernetes. Acorn Images are designed for users who are working at the application level and want to leverage the power of Kubernetes, without deep Kubernetes expertise.

Header Photo by Lukasz Szmigiel on Unsplash