Comment by jacques_chester | Hacker News Reader

Comment by jacques_chester | Hacker News Reader

Parent Full thread

jacques_chester

It's a different language with a different type system. I've also interacted with the API Server using a Ruby library that relied on metaprogramming. I could do things in a dozen lines that would require thousands of lines of checked-in Go.

Replying to your edit:

> It's just a bad idea to write something for Kubernetes that is not in Go, you have 0 support and k8s releases a new version every 6month, good luck keeping up with that.

Well, a few things.

First, using client-go doesn't save you from version shifts. It is explicitly unsupported, so if they break your downstream system, stiff shit.

Second, client-go is derived from code generators. The same generators also produce other clients. Unfortunately they are terrible, by virtue of OpenAPI generator being a hellish maze and because they leak Go-isms like a spiteful sieve. I've used that code generator to develop a proxy. It sucked.

Third, this library is derived independently. It uses the same OpenAPI definitions as client-go, client-java and so forth. It's as easy to keep up to date as any of the others.

Fourth, the Kubernetes API isn't fully tested. Not even close. Many libraries can rightfully claim to be just as conformant as client-go, despite being broken on ~66% of endpoints: https://apisnoop.cncf.io/

As the maintainer of the Rust bindings that the library used in the article (kube) is backed by, I can confirm that Kubernetes' openapi spec requires a lot of Kubernetes-specific handling to generate a good client that generic openapi generators do not provide. Yes, that includes all the other Kubernetes clients in github.com/kubernetes-client like Python and .Net too.

See https://github.com/Arnavion/k8s-openapi/blob/master/README.m... for a full description.

I also confirm that I keep it up-to-date with Kubernetes releases and have been doing so for the ~3 years that it's been around. Not just the minor ones every few months, but even the point ones; these days the latter usually only involves updating the test cases instead of code changes and they're done within a few hours of the upstream release.

Thank you so much for your work on this and keeping it up to date.

Truthfully, the fact that your bindings don't use OpenAPI generators has tempted me to learn Rust just so that I can escape their madness.

Not sure why you’re being downvoted. OpenAPI schema generation is one of the most challenging elements of developing with CRDs. Anyone who is not an apimachinery SME is likely to struggle at some point to get their schema generated as expected.

I don’t think openapi is necessary. All endpoint paths are easy to construct knowing gvk tuples which can be easily extracted from k8s.io/api using some go package analysis (you can also do it at runtime by parsing openapi endpoint). The data types are all defined in generated.proto in the same repo.

It depends again on language. The ruby library I used exploited exactly this discoverability to create objects at runtime. It was awesome, except when time came to navigate my codebase. Where does the FooKind exist? How do I checkpoint it? Drat.

The generated codebases like client-go provide a great deal more navigability of code rather than APIs. It is the code that I actually interface with. I have my complaints about the necessity of code generation, but I do like having some kind of in-advance typing to help me figure things out.

Reply on news.ycombinator.com