Exporting as YAML
Tanka provides you with a day-to-day workflow for working with Kubernetes clusters:
tk show
for quickly checking the YAML representation looks goodtk diff
to ensure your changes will behave like they shouldtk apply
makes it happen
However sometimes it can be required to integrate with other tooling that does
only support .yaml
files.
For that case, tk export
can be used:
This will create a separate .yaml
file for each Kubernetes resource included in your Jsonnet.
Filenames
Tanka by default uses the following pattern:
If that does not fit your need, you can provide your own pattern using the --format
flag:
The syntax is Go
text/template
. See https://pkg.go.dev/text/template for reference.
This would include the label named app
, the name
and kind
of the resource:
You can optionally use the template function lower
for lower-casing fields, e.g. in the above example
would yield
etc.
You can also use a different file extension by providing --extension='yml'
, for example.
Multiple environments
Tanka can also export multiple inline environments, as showcased in Use case: consistent inline
environments. This follows the same
principles as describe before with the addition that you can also refer to Environment specific data through the env
keyword.
For example an export might refer to data from the Environment spec:
Even more advanced use cases allow you to export multiple environments in a single execution:
Performance features
When exporting a large amount of environments, jsonnet evaluation can become a bottleneck. To speed up the process, Tanka provides a few optional features.
Partial export (in a GitOps context)
Given multiple environments, one may want to only export the environments that were modified since the last export. This is enabled by passing both the --merge-strategy=replace-envs
flags.
When these flags are passed, Tanka will:
- Delete the manifests that were previously exported by the environments that are being exported. This is done by looking at the
manifest.json
file that is generated by Tanka when exporting. The related entries are also removed from themanifest.json
file. - Generate the manifests for the targeted environments into the output directory.
- Add in the new manifests entries into the
manifest.json
file and re-export it.
Finding out which environments to export
Tanka provides the tk tool importers
command to figure out which main.jsonnet
need to be re-exported based on what files were modified in a workspace.
If, for example, the lib/my-lib/main.libsonnet
file was modified, you could run the command like this to find which files to export:
Note that deleted environments need special consideration when doing this.
The tk tool importers
utility only works with existing files so deleting an environment will result in stale manifest.json
entries and moving an environment will result in manifest conflicts.
In order to correctly handle deleted environments, they need to be passed to the export command:
Using a memory ballast
Read this blog post for more information about memory ballasts.
For large environments that load lots of data into memory on evaluation, a memory ballast can dramatically improve performance. This feature is exposed through the --mem-ballast-size-bytes
flag on the export command.
Anecdotally (Grafana Labs), environments that took around a minute to load were able to load in around 45 secs with a ballast of 5GB (--mem-ballast-size-bytes=5368709120
). Decreasing the ballast size resulted in negative impact on performance, and increasing it more did not result in any noticeable impact.
Caching
Tanka can also cache the results of the export. This is useful if you often export the same files and want to avoid recomputing them. The cache key is calculated from the main file and all of its transitive imports, so any change to any file possibly used in an environment will invalidate the cache.
This is configured by two flags:
--cache-path
: The local filesystem path where the cache will be stored. The cache is a flat directory of json files (one per environment).--cache-envs
: If exporting multiple environments, this flag can be used to specify, with regexes, which environments to cache. If not specified, all environments are cached.
Notes:
- Using the cache might be slower than evaluating jsonnet directy. It is only recommended for environments that are very CPU intensive to evaluate.
- To use object storage, you can point the
--cache-path
to a FUSE mount, such ass3fs