Comparing Application Packaging Solutions on Kubernetes

We look into the differences between YAML, Jsonnet, Grafana Tanka, Helm, Operators and Acorn.

Packaging and distributing your Kubernetes application is one of the important aspects for application developers. On the flip side, site reliability engineers have to deal with installing, configuring and upgrading various applications on a daily basis. Choosing the right packaging and distribution solution for your Kubernetes application is very important to make it easier and faster to deploy it. It is even more important for advanced applications such as some of the monitoring solutions, databases etc. with a lot of configuration parameters. Choosing the right packaging and distribution solution can mean the difference between spending a few days to a few mins installing, configuring and troubleshooting a deployed application.

Although there are some well known solutions in this area, there also are some up and coming ones that offer promising potential. In this post we will go over some of the Kubernetes application packaging and distribution solutions to see what they are, how they work and what are their pros and cons.

YAML

YAML is the first thing that comes to mind when thinking about distributing Kubernetes applications. It is something which you can’t escape when you’re working with Kubernetes. In the initial days, YAML stood for Yet Another Markup Language which was then repurposed to YAML Ain’t Markup Language. It is a human-friendly data serialization language. We use it to define the various Kubernetes object manifests to distribute our containerized applications.

Pros

• Easy to read/write
• Can combine multiple objects in a single file using — document separator

Cons

• Verbose
• No support for variables, conditionals, loops, etc.
• Duplication of configuration parameters
• Difficult to maintain

Possible Use cases

• Small to medium sized applications with less configuration parameters
• Initial development phases of the application

Jsonnet

Jsonnet is a configuration language for app and tool developers. It is primarily designed to configure complex systems. This makes it useful to configure complex kubernetes applications. Each Jsonnet document is a superset of JSON. It follows the JSON syntax but also allows you to use variables, conditionals, functions, imports, etc. that makes it a data serialization format as well as a programming language. Though JSON is more verbose than YAML, the use of variables, functions, imports along with other features help in making Jsonnet documents smaller in size and easier to maintain.

Jsonnet as superset of JSON

Pros

• Based on the familiar JSON syntax
• Concise
• Easy to maintain

Cons

• Steeper learning curve than typical DSLs
• Limited tools and library support

Possible Use cases

• Small to medium sized applications

Grafana Tanka

Grafana Tanka is a configuration utility for your Kubernetes cluster, powered by Jsonnet language. It uses the capabilities of Jsonnet and provides additional libraries and tools to enhance the Jsonnet capabilities. Tanka aims to solve a peculiar limitation with Jsonnet. Jsonnet lets you define and use functions to make the application specs concise. Though you would also need to maintain these functions as Kubernetes updates its object specs with newer versions. Tanka has generated and maintains a library, called k8s-libsonnet, which contains the Jsonnet functions for various Kubernetes objects for you to use in your specs.

Along with the library, Tanka also offers a CLI utility to help with project creation, applying the jsonnet files to Kubernetes clusters, among other things.

Pros

• Easier application spec creation and management than with plain Jsonnet
• More concise spec files than Jsonnet

Cons

• No versioning support
• Difficult application upgrades/rollbacks
• Less community support

Possible Use cases

• Medium to large applications
• Later phases of application development

Helm

Helm is another popular choice for packaging and distributing Kubernetes applications. It is a package manager for Kubernetes. With Helm, you can define the application configuration as Helm charts. The charts are defined mainly by using YAML files and Go Templates. They may also include JSON files and optionally some metadata files such as readme, license, etc. Every chart must have a chart.yaml file which defines its name, description, version and other important pieces of information. You can build each chart as a chart package and publish to a repository. The packages can be hosted in classic Helm repositories, which contain a generated index.yaml file and optionally some Helm chart packages. Starting with Helm version 3, they can also be hosted in OCI-based container registries.

Pros

• Kubernetes Applications managed as packages
• Chart dependency support
• Versioning support
• Good documentation
• Community support
• Easy application upgrades and rollbacks

Cons

• Steeper learning curve
• Complex application configurations and chart maintenance

Possible Use cases

• Medium to large applications
• Later phases of application development

Operators

Operators follow the Kubernetes Operator Pattern to manage Kubernetes native applications. It makes use of the Kubernetes’ built-in ability for automation to install, upgrade and manage the lifecycle of applications. Each Kubernetes Operator is a custom controller. It follows the Kubernetes principle of control loop to synchronize the desired state of the application according to the custom resource. You can use an existing operator from any of the available operator repositories such as operator hub or write your own operator. Writing an operator yourself is the most involved task in this list of Kubernetes App Packaging and Distribution solutions. It requires in-depth Kubernetes, programming and automation knowledge. Although with the added complexity, it allows you to use all the capabilities in the Kubernetes capability model.

Kubernetes Capability Model

Pros

• Makes use of Kubernetes’ built-in automation ability
• Uses Kubernetes control loop to continually keep the application in sync
• Offers Level 5 capabilities in the capability model
• Good documentation
• Community support

Cons

• Steep learning curve
• Difficult to write and maintain custom operators

Possible Use cases

• Medium to large applications
• Later phases of application development

Acorn

Acorn is a Kubernetes application packaging and deployment framework. Unlike other options in this list, Acorn is able to package all of the application’s container images, along with configuration and deployment specs into an Acorn package. This Acorn package can then be pushed to any OCI compliant container registry for easy distribution. Like Helm, Acorn also allows versioning so that you can maintain different versions of an application and seamlessly upgrade between versions.

To create a new Acorn package you need to write an Acornfile and build it using Acorn CLI. The Acornfile uses a syntax similar to JSON and YAML to lower the learning curve and for better readability. It is comparable with Helm from the capabilities point of view, allowing you to manage install, configuration and upgrade of complex applications, while not being as complicated as operators to write one yourself.

Pros

• Gentle learning curve
• Easy package management with OCI registries
• Versioning support -Auto upgrade support
• Ability to combine application build, container build and Acorn image build steps into one
• Dev mode support
• Good documentation

Cons

• Evolving community support

###Possible Use cases

• Small to large applications
• Any phase of application development

Comparative Overview

We looked into the various packaging options for Kubernetes. Tools like YAML and Jsonnet are suited for small applications with less configurations. Tanka and Helm are more suited for mid to large applications that are complex and have a lot of configurations. Operators can be used with mid to large size applications usually at the later stages of development. Lastly, Acorn can be used for small and large applications alike and at any phase of the development cycle. Below is a handy comparison of all the tools and their features.

Conclusion

In this post we saw various Packaging and Distribution Solutions for Kubernetes applications. We saw what each solution is and a brief overview of how to use it. We also went over some of the pros and cons of each solution. Hope this information helps you make an informed decision when you need to package and distribute your application across multiple users and/or environments.

Two of the solutions in this list, viz. Helm and Acorn, creates OCI compliant packages. In the next posts we will see what OCI is and how to create an OCI compliant package yourself with basic tools. If you are interested, you can learn more about Acorn at https://docs.acorn.io/ or by joining a hands-on training class.

Sameer Kulkarni is a software engineer with 14+ years of experience and is working as a Principal Engineer at InfraCloud. You can chat with him on Twitter and read more of his work on Medium.

Header Photo by orbtal media on Unsplash