Mistletoe (WIP) - the Polyglot Kubernetes Package Manager

Site | Blog | Book

Mistletoe is a Kubernetes package manager that goes about things in a different way than the rest of the ecosystem. It's built around a runtime where the packages are WebAssembly modules:

mistletoe_package! {"
  name: namespace-example
  labels:
    mistletoe.dev/group: mistletoe-examples
"}

#[derive(Deserialize)]
pub struct Inputs {
    name: String,
}

pub fn generate(inputs: Inputs) -> MistResult {
    let name = inputs.name;

    let output = MistOutput::new()
        .with_file("namespace.yaml".to_string(), formatdoc!("
            apiVersion: v1
            kind: Namespace
            metadata:
              name: {name}
        "));

    Ok(output)
}

The above is a simple package written in Rust. If you run it with:

mistctl generate my-namespace -p mistletoe/examples/namespace-example:0.1.2

You get the following YAML back:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace

This is one of a nearly-unlimited number of ways to write a package. All you need is a language with a YAML parser that can compile to WebAssembly.

Roadmap

Mistletoe is still very early on in the development lifecycle, but we've made some progress!

As of note, we've implemented the registry system that's used by the above example -- you can add registries by Git URL and reference packages inside them by name now!

There's also a default "mistletoe" registry added that points to mistletoe-registry. There's only the example package up now, but more will be coming soon!

That said, there are still a handful of things that need to be addressed before it could reasonably be opened up for use:

1. The mistctl utility currently only supports YAML generation -- it should be expanded to support installation to clusters. This also implies all the usual goodies around lifecycle management, notably upgrades and uninstallation.
2. Need documentation, documentation, and more documentation. The only way to guarantee adoption is to provide best-in-class documentation covering everything from general usage, to package development in multiple languages, to the nitty-gritty advanced information about the runtime for eager hackers.

There's all that, as well as a number of less-important, but also-desired efforts worth evaluating:

1. Dynamic dependencies! We can get a lot more value by adding a way for packages to declare and call dependencies outside of whatever is compiled into the package. This gets really useful when you consider #3 below.
2. Explicit support for other languages. While any WebAssembly-ready language will work, the project is written in Rust and provides Rust-first tooling. For the next push, I'm looking to expand library support to TypeScript via the QuickJS runtime.
3. Since the runtime is pretty open, we could theoretically package other package managers. This means we could provide a system to install Helm packages as if they were any other Mistletoe package.
4. We could use some package templates. The templating engine in Helm is a blessing and a curse -- it makes generating manifests pretty easy, but tends to get really overcomplicated really quickly depending on what logic is entailed in deploying the system. Mistletoe addresses the curse pretty well, but we should provide some easy-build package templates to recreate the blessing.