davidmdm91

Hey folks

I’ve been working on a project called Yoke, which lets you manage Kubernetes resources using real, type-safe Go code instead of YAML. In this blog post, I explore a new feature in Yoke’s Air Traffic Controller called dynamic-mode airways.

To highlight what it can do, I tackle an age-old Kubernetes question: How do you restart a deployment when a secret changes?

It’s a problem many newcomers run into, and I thought it was a great way to show how dynamic airways bring reactive behavior to custom resources—without writing your own controller.

The post is conversational, not too formal, and aimed at sharing ideas and gathering feedback. Would love to hear your thoughts!

Thanks! Very appreciated.

Also, it has a kro-like operator for deploying packages defined as code. If the operators you are writing are just managing resources and not doing anything special with the outside world, then you can use the AirTrafficController to build your CRDs and all you need to provide is the program to transform a CR into the underlying resources. Just in case that part interests you.

Thank you for the feedback. Its very appreciated.

Managing Kubernetes resources with YAML templates can quickly turn into an unreadable mess. I got tired of fighting it, so I built Yoke.

Yoke is a client-side CLI (like Helm) but instead of YAML charts, it allows you to describe your charts (“flights” in Yoke terminology) as code.

Your Kubernetes “packages” are actual programs, not templated text, which means you can use actual programming languages to define your packages; Allowing you to fully leverage your development environment.

At its core a flight is a program that reads inputs from stdin and writes resources to stdout. It is packaged as a WebAssembly Module for portability and security. This allows you to leverage any programming language that supports WebAssembly like Go or Rust to build your "chart" logic.

With yoke your packages get: control flow, static typing and intilisense, type checking, test frameworks, package ecosystem (go modules, rust cargo, npm, and so on), and so on!

What's more Yoke doesn't stop at client-side package management. You can integrate your packages directly into the Kubernetes API with Yoke's Air-Traffic-Controller, enabling you to manage your packages as first-class Kubernetes resources.

This is still an early project, and I’d love feedback. Here is the Github Repository and the documentation.

Repo: https://github.com/yokecd/yoke Docs: https://yokecd.github.io/docs

Would love to hear thoughts—good, bad, or otherwise.

Writing your own operator is a lot of complexity when what you want to do is deploy a package.

Via Yoke's AirTrafficController, it's easy to define a package as a CRD and its implementation (a program that takes the CR and outputs the desired underlying resources) and the AirTrafficController takes care of the rest.

You no longer need to think about reconciler loops, figuring out any orphaned state, etc.

Hi. I think the article was just showing the example that IaC tools use configuration languages instead of code. Yoke is not a terraform replacement, and does not mention terraform anywhere its documentation.

It does sit at the same level as helm & timoni. It just takes a code-based approach to managing your cluster (which in turn can manage your infra but that wasn't the larger point).

I actually really like CUE. I use it kind of extensively as a YAML replacement where I can, and at my work we've done our best to integrate cue with our charts to validate the values used to invoke our charts and to unify the value space.

However there's something about a full blown general purpose language that is so much more flexible.

I don't think that the fact that people can and do write bad programs disqualifies general purpose languages from being great tools to build packages.

I am sure there is just as equally bad CUE, Jsonette, PKL, etc out there.

Other than CDK8s I don't know of other tools that have tried in this space to use general purpose languages to define their packages, and I think CDk8s uses are generally happy. Much more so than helm users at least.

I am not sure I can agree with this statement > We’ve learned the hard way general purpose languages are poor for configuration at scale

I think we've just assumed this, or seen a pulumi project we didn't like working in.

I believe and hope there will be plenty of room to experiment and innovate in this space!

I am not saying that Turing incomplete languages don’t or can’t be a good fit for this task.

However there’s no reason we should rule out general purpose languages.

We have a lot of configuration based IaC and configuration tooling a la jsonnette and cue and yet these are riddled with their own problems and DX issues.

Anyways we don’t need to see eye to to eye on this but I respect your position.

Why limit yourself to those types of tools?

To protect against somebody writing a non-terminating program?

General programming languages come with a lot of general purpose benefits from their ecosystems like package managers npm, cargo, go modules, etc.

They have test runners, and control flow.

Lots of them already have type definitions for kubernetes and if you are working in Go you have access to almost the entire kubernetes ecosystem.

Maybe we are throwing the baby out with the bath water when we disqualify general purpose languages?

I have been developing my own package manager, and my core idea is that proper programming languages are the proper level for describing packages.

Programs take inputs and can output arbitrary data such as resources. However they can do so with type safety, and everything else a programming ecosystem can achieve.

For asset distribution it uses wasm, and that's it!

If you want to check it out its here: github: (https://github.com/davidmdm/yoke) docs: (https://davidmdm.github.io/yoke-website)

I like that you said: > I think proper programming language support is the way to go.

I think we need to stop writing new ways of generating yaml since we already have the perfect way of doing so. Typed languages!