Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Kubernetes CRD Controller in Rust

technosophos.com

Post reply on HN
Print view View original

31–40 of 76 posts

Re: Writing a Kubernetes CRD Controller in Rust

#31

Post by throwaway894345 »

hardwaresofton wrote: post #27

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops…

Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (or rather, type safety and correctness simply aren’t nearly as important as velocity from an economic perspective).

Rust is getting better all the time—non-lexical lifetimes and rust-analyzer have provided a surprising improvement in development velocity, but Go is still in another class. Personally I think Go is the best language for developing quickly—even better than Python for non-toy projects (I say that as one with 15 years of Python experience and almost a decade of ago experience).

Re: Writing a Kubernetes CRD Controller in Rust

#32

Post by throwaway89456 »

hardwaresofton wrote: post #27

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops…

Rust complexity is not encapsulated in libraries that parses JSON or YAML, or others.

Rust complexity is embedded in the following: in order to get something to work, you effectively need to solve a puzzle.

Solving the puzzle is fun and feels very good once completed, and the prize is definitely worth it when performance and safety are critical.

I highly doubt that "solving the puzzle" makes sense in the context of ad-hoc automation or boring sysadmin/devops stuff. Last time I checked, creating a static binary (a-la go) was not easy. It may sound stupid... but at the end of the day go is the king of pragmatism.

I think exactly the opposite though about systems languages: Rust should take over C and C++.

Re: Writing a Kubernetes CRD Controller in Rust

#33

Post by throwaway894345 »

throwaway89456 wrote: post #32
hardwaresofton wrote: post #27

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops…

Rust complexity is not encapsulated in libraries that parses JSON or YAML, or others. Rust complexity is embedded in the following: in order to get something to work, you effectively need to solve a puzzle. Solving the puzzle is fun and feels very good once completed, and the prize is definitely worth it when performance and safety are critical. I highly doubt that "solving the puzzle" makes sense in the context of a…

Even with respect to dealing with JSON, good luck deserializing a structure with borrowed references. People will tell you not to use borrowed references, but sometimes you’re at the mercy of a library author and even if you’re not it kind of sucks to have to do a big refactor across your codebase to replace borrowed fields with owned fields, right after you got everything working just because you can’t figure out how to deserialize properly and no one else appears to know how either. This is one of many problems that make Rust more difficult and time consuming in practice than Go which doesn’t distinguish between owned and borrowed. Of course this borrow checker gives you a lot more thread safety than Go provides, but I write a lot less parallel code than code that must be deserialized (or any of the other areas where pernicious borrow-checker issues creep in).

Rust improves quickly so I don’t think we should discount it, but I wish Rust folks would address these concerns when talking about how Rust is going to take over $x domain.

Re: Writing a Kubernetes CRD Controller in Rust

#34

Post by ircoder »

Thaxll wrote: post #6

"The Go version was over 1700 lines long and was loaded with boilerplate and auto-generated code. The Rust version was only 127 lines long" Right ...

I tend to agree! However, I think it has factored in the generated code as well. With something like Kubebuilder you won't have to write that many lines of code for a basic operator.

Re: Writing a Kubernetes CRD Controller in Rust

#35

Post by praveenperera »

throwaway894345 wrote: post #31
hardwaresofton wrote: post #27

Go bills itself as simple, but Rust, despite it's complexity (which is hidden from you with libraries like serde and others) is simpler to use at the higher level. Rust has a near-best-of-class type system, better abstractions, and runs on everything from embedded to the browser. Go has captured the hearts of sysadmin types and those looking for something just a step up from python (as evidenced by much of the devops…

Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (…

I really don't think Rust MAKES you think a lot about memory management.

You CAN think a lot about memory management if you care about performance.

If not, you can throw `clone()` around everywhere and still have a very fast program.

Re: Writing a Kubernetes CRD Controller in Rust

#36

Post by ircoder »

praveenperera wrote: post #16

The library used in the this post has gotten much better since this post was written (in 2019) Recently the ability to do `exec` and `attach` was added. It should reach feature parity with the Go version soon once `port forward` is added. https://github.com/clux/kube-rs

Hmm! Interesting. I'm wondering if adding a test framework like kubebuilder is on the agenda. I'm not a great fan of it (kubebuilder) but the simple-to-use (in a relative term, i.e. as simple as it can get with Go) is a huge benefit. So you won't have to deploy after every build to see how your changes look like.

Re: Writing a Kubernetes CRD Controller in Rust

#37

Post by bogomipz »

psoundy wrote: post #23
bogomipz wrote: post #15

Earlier quoted context omitted.

>"I think CRDs are useful and necessary[0], but that they are greatly overused and have expensive design flaws." Could you elaborate on the "design flaws" part? Do you feel that the CRD model itself has design flaws or are you referring to specific project's CRDs?

tl;dr If you’re operating with CRDs at trivial scale, you probably having nothing to worry about. But operating with CRDs at scale is a different story and suggests careful testing with the specific applications involved. ——- The usage patterns of native k8s types and the implications those patterns have on the scalability and reliability of etcd and the apiserver are relatively well-understood. CRDs can be a wild-ca…

Thanks for the insights. I was curious about this however:

>"But operating with CRDs at scale is a different story and suggests careful testing with the specific applications involved."

Do you mean the number of different CRDs deployed here or just the number of custom resources created? Or is it the same concern with either? I'd be curious what you are defining as "scale" as well?

Re: Writing a Kubernetes CRD Controller in Rust

#38

Post by bogomipz »

jacques_chester wrote: post #26
psoundy wrote: post #23

Earlier quoted context omitted.

tl;dr If you’re operating with CRDs at trivial scale, you probably having nothing to worry about. But operating with CRDs at scale is a different story and suggests careful testing with the specific applications involved. ——- The usage patterns of native k8s types and the implications those patterns have on the scalability and reliability of etcd and the apiserver are relatively well-understood. CRDs can be a wild-ca…

I agree with all of this, with one nitpick intended to self-aggrandise. You can actually nominate particular types be stored in particular etcd servers -- GKE does this to put Events into a separate etcd from everything else. However, it still has problems. Firstly, you can only define it for inbuilt types. Secondly, it's common for different objects to cross reference each other through objectRefs and the like, whic…

>"You can actually nominate particular types be stored in particular etcd servers -- GKE does this to put Events into a separate etcd from everything else."

Interesting. Is this documented anywhere?

Re: Writing a Kubernetes CRD Controller in Rust

#39

Post by throwaway89456 »

praveenperera wrote: post #35
throwaway894345 wrote: post #31

Earlier quoted context omitted.

Because building things quickly is important and Rust makes you think a lot about memory management. This is a fine thing for performance critical systems, but for systems where Python’s performance could be described as adequate, the extra performance Rust offers is immaterial. Of course, Rust gives you a bit more type safety than Go as well, but still not enough to justify trading off so much development velocity (…

I really don't think Rust MAKES you think a lot about memory management. You CAN think a lot about memory management if you care about performance. If not, you can throw `clone()` around everywhere and still have a very fast program.

It is not because you can that you should.

Re: Writing a Kubernetes CRD Controller in Rust

#40

Post by praveenperera »

ircoder wrote: post #36
praveenperera wrote: post #16

The library used in the this post has gotten much better since this post was written (in 2019) Recently the ability to do `exec` and `attach` was added. It should reach feature parity with the Go version soon once `port forward` is added. https://github.com/clux/kube-rs

Hmm! Interesting. I'm wondering if adding a test framework like kubebuilder is on the agenda. I'm not a great fan of it (kubebuilder) but the simple-to-use (in a relative term, i.e. as simple as it can get with Go) is a huge benefit. So you won't have to deploy after every build to see how your changes look like.

I'm not sure about that, but the maintainers are very active and receptive so maybe make an issue? Better yet a PR.
Post reply on HN