Grafana TankaFlexible, reusable and concise configuration for Kubernetes
Edit page
IntroductionInstallation
Tutorial
Writing Jsonnet
Libraries
Output filteringExporting as YAMLGarbage collectionCommand-line completionDiff strategiesConfiguration ReferenceDirectory structureEnvironment variablesFrequently asked questionsWhat is Jsonnet?How is this different from ksonnet?What about kubecfg ?Why not Helm?Known issues

Frequently asked questions

What is Jsonnet?

Jsonnet is a data templating language, originally created by Google.

It is a superset of JSON, which adds common structures from full programming languages to data modeling. Because it being a superset of JSON and ultimately always compiling to JSON, it is guaranteed that the output will be valid JSON (or YAML).

By allowing functions and imports, rich abstraction is possible, even across project boundaries.

For more, refer to the official documentation: https://jsonnet.org/

How is this different from ksonnet?

Tanka aims to be a fully compatible, drop-in replacement for the main workflow of ksonnet (show, diff, apply).

In general, both tools are very similar when it comes to how they handle Jsonnet and apply to a Kubernetes cluster.

However, ksonnet included a rich code generator for establishing a CLI based workflow for editing Kubernetes objects. It also used to manage dependencies itself and had a lot of concepts for different levels of abstractions. When designing Tanka, we felt these add more complexity for the user than they provide additional value. To keep Tanka as minimal as possible, these are not available and are not likely to be ever added.

What about kubecfg ?

Tanka development has started at the time when kubecfg was a part of already-deprecated ksonnet project. Although these projects are similar, Tanka aims to provide continuity for ksonnet users, whereas kubecfg is (according to the project's README.md really just a thin Kubernetes-specific wrapper around jsonnet evaluation.

Why not Helm?

Helm relies heavily on string templating .yaml files. We feel this is the wrong way to approach the absence of abstractions inside of yaml, because the templating part of the application has no idea of the structure and syntax of yaml.

This makes debugging very hard. Furthermore, helm is not able to provide an adequate solution for edge cases. If I wanted to set some parameters that are not already implemented by the Chart, I have no choice but to modify the Chart first.

Jsonnet on the other hand got you covered by supporting mixing (patching, deep-merging) objects on top of the libraries output if required.