Kubernetes-free kube crate

[rektide]

Would you like to work on this feature?

None

What problem are you trying to solve?

There is excellent tooling in kube for creating reconciliation machinery in rust. So much of those code is not Kubernetes specific. It would be lovely to be able to use this library elsewhere. However there are some large Kubernetes elements that are always brought in, such as kube-client and k8s-openapi, that make it impractical to ship for many uses.

Describe the solution you'd like

I don't know the exact solution, but ideally, there would be good ways to use this library without the heavier Kube specific dependencies. Perhaps feature gates?

Describe alternatives you've considered

Not sure what else to try! Maybe split kube into a kube-less core then layer kubernetes needs atop as a separate crate?

Documentation, Adoption, Migration Strategy

I asked Fable for an implementation of this idea, and got this: rektide#1 , which seems like a fairly ok distillation of kube that leaves the library intact, with little external changes, while allowing other uses outside Kubernetes.

Target crate for feature

No response

[aviramha]

I like the idea! We plan on extending our k8s operator to support other runtimes and that'd be nice to keep using same building blocks.

[doxxx93]

@aviramha would you like to work on this? ah maybe checking trade off needs to be preceded

[aviramha]

@aviramha would you like to work on this? ah maybe checking trade off needs to be preceded

I don't think we can prioritize our team to work on it yet, but might in the near future.

[nightkr]

I assume that this is largely about kube_runtime, since the rest of kube-rs doesn't really make much sense outside of it. (Basic CRUD and config loading that is going to vary per target anyway.)

1. kube::runtime was written against Kubernetes' semantics. Any detangling from that should try to find the actual semantics we rely on and codify them, not just make it possible to sub in another pretend-Kubernetes. I don't know what system you're planning on targetting instead, but if it's not already targetting Kubernetes semantics then it's probably not going to look enough like Kubernetes that everything else matches 1:1 either.
2. The core of the controller machinery is applier, and it does intentionally not make any API calls by itself (the main kubeism there is that it and reflector assume the presence of the GVK/namespace/name hierarchy), the rest of controller is just hooking it all up against the K8s API
3. watcher is largely just plumbing between K8s semantics and applier semantics, if you're not targetting K8s then you should probably tailor the adapter to your actual target API. (Again, maaaaybe pieces could be salvaged from watcher but that takes actually specifying what it expects beyond "just be k8s lol".)
4. We definitely shouldn't just switcheroo-in our own kube::k8s depending on feature flags, that breaks the cardinal rule about feature flags always being purely additive.
5. I can only speak for myself, but posting slop is a pretty surefire way to put me off the whole effort. Please don't do that?

[doxxx93]

thanks for clearing up

I just saw the pr link in the issue description, it looks like mutually exclusive feature.