Yoke: Introducing the Infrastructure as Code
Package Manager for Kubernetes

Getting started

Install the Yoke CLI

From source

go install github.com/davidmdm/yoke/cmd/yoke@latest

Deploy your first package

yoke takeoff my-release https://my-domain.com/example/v1/main.wasm.gz

Visit the core docs

What is Yoke?

Yoke is a Kubernetes package manager that facilitates the downloading and deployment of packages to Kubernetes.

The primary distinction between Yoke and other Kubernetes package managers, such as Helm and Timoni, lies in how Yoke describes packages. In the context of yoke packages are called Flights (Flights are to Yoke what Charts are to Helm). Unlike Helm and Timoni, which define packages using YAML, CUE, or other data/configuration languages, yoke utilizes general-purpose code to describe kubernetes packages .

With yoke, Flights are programs that generate the desired Kubernetes resources in either JSON or YAML format and output them to stdout. . Flights are typically packaged as WebAssembly (wasm) executables , with Yoke embedding Wazero, a zero-dependency wasm runtime for Go, to execute these programs.

Sharing packages is the same as sharing code. Package components can be distributed and versioned using the respective language's ecosystem package manager, such as npm, cargo, or Go modules. Any language that compiles to wasm enjoys first-class support in Yoke . If your chosen language does not compile to wasm, you can still invoke the program and pipe the output directly to Yoke. However, this approach comes with certain drawbacks, including potential issues related to portability and security.

Why Another Package Manager?

As the DevOps ecosystem transitions from platform-operators to platform-engineering, our tools for interfacing with Kubernetes (K8s) must evolve accordingly. Describing Kubernetes resources through text templates represents the minimum standard we have set. It's evident that this approach doesn't align with software engineering practices. It lacks essential features such as proper type safety, compiler guarantees, validation, testing, autocompletion, and consistent IDE support.

The crucial observation to note is that Kubernetes (K8s) resources differ fundamentally from web pages or emails. So, why do we use templates as if they were? These files represent diverse APIs supported by Kubernetes; in essence, they are structured data. The most effective tools for handling structured data are programming languages .

Working with raw yaml manifests for representing Kubernetes APIs is error prone. When we template them we are no longer concerned with the configuration of our resources but instead the rendering of the format of our configuration.

New tools like CUE, jsonnette, PKL, and others have emerged to address some of the short comings of raw YAML configuration and templating. Inspiring new K8s package managers such as timoni . However it is yoke's stance that these tools will always fall short of the safety, flexibility and power of building your packages from code.

With the emergence of a shared cross-platform target for code, WebAssembly (wasm), it is now possible to package and utilize the Kubernetes ecosystem with greater emphasis on type safety, testing, and developer experience than ever before. This is the niche Yoke aims to fill within the K8s Package Management Landscape.