3 ms·

I've written CRD controllers. This is an accurate description of what your code looks like. Because of Golang's anemic type system, massive code generation is

I've written CRD controllers. This is an accurate description of what your code looks like. Because of Golang's anemic type system, massive code generation is the only viable way to deal with the dynamic blackboard that the API Server presents to clients.

Thaxll 6y ago
I also write CRD, but I don't beleive for one second that you have more than 10x less code, especially for generated code that you don't touch at all. 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.
- jacques_chester 6y ago
  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/ https://apisnoop.cncf.io/
  - Arnavion 6y ago
    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.md 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.
    - lars_francke 6y ago
      Thank you so much for your work on this and keeping it up to date.
    - jacques_chester 6y ago
      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.
      - psoundy 6y ago
        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.
  - dilyevsky 6y ago
    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.
- dilyevsky 6y ago
  It’s a perfectly fine idea. Kubernetes uses standard rest endpoints with defined semantics and data types are strictly defined via protos

Thaxll 6y ago

I also write CRD, but I don't beleive for one second that you have more than 10x less code, especially for generated code that you don't touch at all. 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.

jacques_chester 6y ago
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/ https://apisnoop.cncf.io/
- Arnavion 6y ago
  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.md 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.
  - lars_francke 6y ago
    Thank you so much for your work on this and keeping it up to date.
  - jacques_chester 6y ago
    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.
    - psoundy 6y ago
      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.
- dilyevsky 6y ago
  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.
dilyevsky 6y ago
It’s a perfectly fine idea. Kubernetes uses standard rest endpoints with defined semantics and data types are strictly defined via protos