The Yoke Project is a set of tools for working with package management differently than the status quo. Where once only YAML and templates of YAML ruled the representation of Kubernetes resources and the packages thereof, we can now work with code and benefit from native control flow, type checking, compiler guarantees, testing, linters, and other fundamental tools of software engineering.
It consists of:
A client-side package manager for deploying code packages to Kubernetes.
An ArgoCD Config Management Plugin that enables ArgoCD to work with code packages.
A server-side controller that allows you to create CustomResourceDefinitions (CRDs) to represent packages natively in Kubernetes.
Go packages to facilitate the transition from Helm Charts to Yoke Flights (code packages).
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.
