[Sandbox] Yoke

[davidmdm]

Application contact emails

[email protected]

Project Summary

An ecosystem for K8s Packages as Code powered by WASM

Project Description

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.

In Yoke packages are executable programs compiled to WASM (wasip1) that output the desired K8s resources constituting the package.

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).

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/yokecd

Project repo URL in scope of application

https://github.com/yokecd/yoke

Additional repos in scope of the application

• https://github.com/yokecd/docs - documentation
• https://github.com/yokecd/examples - examples (under construction)

Website URL

https://yokecd.github.io/docs

Roadmap

N/A

Roadmap context

• stability of yoke internals (we are pre v1.0.0)
• stability of Air-Traffic-Controller (we are pre v1.0.0)
  • TUI application for viewing and monitoring packages deployed via ATC

Contributing Guide

https://github.com/yokecd/yoke/blob/main/contributing.md

Code of Conduct (CoC)

https://github.com/yokecd/yoke/blob/main/code-of-conduct.md

Adopters

No response

Contributing or Sponsoring Org

No response

Maintainers file

N/A

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

Yoke is another evolution of Cloud (K8s) package managers, and brings new ideas and possibilities for writing robust and scalable packages.
I have done my best to give the project shape and substance. However, for this project to succeed, it needs credibility, community, contributions, and adoptions. Having the project recognized as a CNCF project will go along way to making those things happen.

Benefit to the Landscape

This project allows users to build deployable packages for kubernetes in a new way that scales better than text based templates.
It allows user to write code to express packages, taking advantage of control flow, tests, type systems, and compiler guarantees. All this while leveraging WASM to allow packages to be written agnostic of coding language (as much as possible).

It also provides new ways to extend the the Kubernetes Control Plane via the Yoke Air Traffic Controller. A server side component allowing you to describe new K8s CustomResourceDefinitions and bind them to Yoke Flights (Code Packages), thus allowing you to deploy packages to kubernetes as Custom Resources with specific APIs defined by you and validated natively by Kubernetes.

Cloud Native 'Fit'

It fits into the Continuous deployment aspect of Cloud Native. It changes the way that we can deploy resources into kubernetes, by describing our resources via code. Taking advantage of the existing ecosystem.

The projet is similar to a mix between helm and cdk8s but applies new ideas for delivering code (via wasm) and provides varying tools for working with this new ecosystem.

Cloud Native 'Integration'

It is generally standalone but also complements Continuous Delivery/Deployment tools such as ArgoCD, either directly via its ArgoCD Config-Management-Plugin, or indirectly via its server side component allowing k8s operators to express packages as Custom Resources of their design.

Cloud Native Overlap

It overlaps with projects such as helm and timoni as in that fundamentally it is a package manager. The packages have a different format, and the project brings about novel approaches to server-side package management as in answer to the acknowledgement that client-side package managers are not the future of kubernetes.

Similar projects

CDK8s is a similar project and has similiar aesthetics by describing resources as code but stops at being a yaml generator.

Yoke goes beyond that by introducing a package format (WASM/wasip1) and contract, and tries to build an ecosystem for deploying packages described as code to kubernetes.

Landscape

I am not.

Business Product or Service to Project separation

it is not.

Project Domain Technical Review

No response

CNCF Contacts

No response

Additional information

No response

[dims]

@davidmdm have you had some discussions with folks from Helm or Carvel yet?

[davidmdm]

@dims I have not! Open to discussing with them.

[davidmdm]

@dims Although personally I think this project more closely ressembles CDK8s in spirit or KubeWarden in implementation.

Although the core CLI is a package manager like helm or timoni, the project has other ambitions beyond being a client-side package manager.

See:

• User defined Server-Side Packages via CR(D)s
  
• ArgoCD Integration

TLDR; The project's main goal is to build an ecosystem such that we can leverage packages as code, and bring the advantages a programming environment to hand when working with and deploying to K8s.

[davidmdm]

Want to add to the roadmap:

• add cross cluster deployment support to the AirTrafficController
• Horizontal scaling for the AirTrafficController