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

51–60 of 76 posts

Re: Writing a Kubernetes CRD Controller in Rust

#51

Post by psoundy »

bogomipz wrote: post #37
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…

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?

The number of deployed CRDs is not likely to be an issue. The number and size of custom resources (CRs - instances of CRDs) is potentially an issue.

Scalability is relative, and depends on many factors including but not limited to:

- the resources available on the hosts running apiservers and etcd members

- the number and size of resources (custom and native) that controllers will maintain

Relatively speaking, a cluster of a given size might be perfectly capable of handling on the order of many thousands of resources . Push that an order of magnitude and the overhead of serving LIST calls - marshaling json from etcd to golang structs for apimachinery and back again for sending over the wire - could exhaust an apiserver’s memory allocation. And since the impact of resources is cumulative, any one application relying on lots of CRDs might not destabilize a cluster on its own but might well contribute to an unhealthy cluster when running alongside similarly CRD-heavy applications.

The key takeaway is that the kube api is best thought of as a specialized operational store rather than a general-purpose database. Anyone wanting to rely on CRDs at non-trivial scale would be well-advised to test carefully.

Re: Writing a Kubernetes CRD Controller in Rust

#52

Post by felipellrocha »

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 (…

You're missing his point. Rust is simpler, so it's easier to use. The language is designed in a way that you don't really think about memory management unless you want to, and if you want to, it'll be pretty straight forward.

Re: Writing a Kubernetes CRD Controller in Rust

#53

Post by felipellrocha »

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…

> Last time I checked, creating a static binary (a-la go) was not easy

When was the last time you checked?

Re: Writing a Kubernetes CRD Controller in Rust

#54

Post by throwaway89456 »

felipellrocha wrote: post #53
throwaway89456 wrote: post #32

Earlier quoted context omitted.

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…

> Last time I checked, creating a static binary (a-la go) was not easy When was the last time you checked?

Today, go produces static binary by default, not Rust.

Re: Writing a Kubernetes CRD Controller in Rust

#55

Post by moldavi »

felipellrocha wrote: post #52
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 (…

You're missing his point. Rust is simpler, so it's easier to use. The language is designed in a way that you don't really think about memory management unless you want to, and if you want to, it'll be pretty straight forward.

Either Rust improved dramatically while I wasn't looking the last few days, or that's some of the most beautiful trolling I've ever seen. Someone needs to be congratulated, either way ;)

I love Rust. It's like a beautiful puzzle that keeps my mind sharp and lets me make things that are truly elegant and performant. But the borrow checker is omnipresent, inescapable, and complexity-inducing... far from straightforward.

Re: Writing a Kubernetes CRD Controller in Rust

#56

Post by throwaway89456 »

FridgeSeal wrote: post #50
Thaxll wrote: post #44

Earlier quoted context omitted.

And yet reading some giant lib.rs is a bigger mess / un-readable than duplicated Go code. I think people gives too much credit to Rust sometimes. You give some Go and Rust code to some team that never used either language, I can tell you right away that the Rust code will never be properly understand. Go is easy to read and to maintain, I can't say the same for some Rust code. Go itself has been stable for years, the…

I will take a longer on-boarding in return for better long-term code any day of the week. I’ve been down the “developer speed above all else” rabbit hole with Python, and I don’t think it ever ended up working out meaningfully better than the “think the problem through first” approach. Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the…

The “developer speed above all else” mindset is driven by economics rather than technic. There are no reasons why one should not produce a good design in a any language. In the end it's a "people problem" most of the time.

> Personally I don’t find go easy to read: the noise of the “mechanics” of the implementation gets in the way of the intent behind the code in my opinion

I'd add another dimension: reading go is slower than reading Rust, but it's easy. Rust may be faster to read, but you can hit some very rough patch and serious head scratchers.

It's all a trade-off at the end of the day.

Re: Writing a Kubernetes CRD Controller in Rust

#57

Post by bbkane »

yawaramin wrote: post #41
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 believe OCaml is the best language for fast development. It's got a super-fast compiler (faster than Go's), better type system than both Rust and Go (of course aside from lifetime analysis), and its performance is quite impressive (described as within xN of C where N can be counted with the fingers of one hand).

I haven't tried it, but I've heard OCaml has a much smaller community (fewer libraries and general knowledge) and a lack of tooling and corporate sponsorship- I know Jane Street works with it and they have their own version of a stdlib.

Re: Writing a Kubernetes CRD Controller in Rust

#58

Post by bombela »

throwaway89456 wrote: post #54
felipellrocha wrote: post #53

Earlier quoted context omitted.

> Last time I checked, creating a static binary (a-la go) was not easy When was the last time you checked?

Today, go produces static binary by default, not Rust.

By default, Go dynamically link to libc on Linux if you use networking. I believe because of a dependency on nss.

I recall it's truly static on MacOS though.

Re: Writing a Kubernetes CRD Controller in Rust

#59

Post by skohan »

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.

In my experience, 98% of the time, I don't have to think much about memory management in Rust. The other 2% of the time I am untangling some kind of tricky, arcane situation.

Re: Writing a Kubernetes CRD Controller in Rust

#60

Post by skohan »

felipellrocha wrote: post #52
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 (…

You're missing his point. Rust is simpler, so it's easier to use. The language is designed in a way that you don't really think about memory management unless you want to, and if you want to, it'll be pretty straight forward.

Rust has a lot of great qualities but simplicity is certainly not one of them.
Post reply on HN