Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Is Rust a great language for building Kubernete...

Is Rust a great language for building Kubernetes ecosystem

When it comes to building tools for the Kubernetes ecosystem, your first thought would be Golang, I'm here to explore if Rust is a better alternative, especially for in-cluster tooling that needs to have minimal overhead and for WebAssembly workloads. Rust is also great for building Kubernetes tooling like CLI apps and so on.

I'll be also sharing and showcasing KDash - a Kubernetes CLI dashboard that I built using Rust and we will look at the Kubernetes-Rust ecosystem that is rapidly evolving and why you should consider it

- Rust vs Golang for k8s use cases
- Advantages of Rust over Golang
- Ideal Kubernetes use cases for Rust (WASI, tools, proxies)
- Real-life use case and example (KDash)
- State of the Rust ecosystem for DevOps and K8s

Deepu K Sasidharan

April 28, 2022
Tweet

More Decks by Deepu K Sasidharan

Other Decks in Programming

Transcript

  1. @deepu105 @oktaDev Is Rust a great language for building the

    Kubernetes ecosystem? Deepu K Sasidharan @deepu105 | deepu.tech
  2. @deepu105 @oktaDev Deepu K Sasidharan JHipster co-lead, Java Champion Creator

    of KDash, JDL Studio Developer Advocate @ Okta OSS aficionado, author, speaker, polyglot dev @deepu105 deepu.tech deepu105
  3. @deepu105 @oktaDev KDash • A simple terminal dashboard for Kubernetes

    • Provides resource views, Node metrics, logs and common view features • Resources utilizations for nodes, pods and namespaces based on metrics server. • Context switching • Easy full keyboard navigation and themes https://github.com/kdash-rs/kdash
  4. @deepu105 @oktaDev Why another dashboard Kdash is obviously inspired by

    k9s, so why build another dashboard? • User experience: I wanted the stuff that is most used easily available and a workflow suitable for daily use • Better navigation: I wanted a better overview and keyboard shortcuts for everything • Better metrics: I wanted to see better resource metrics for the cluster • PoC for Rust tooling: I wanted to build something useful in Rust for the k8s space • Speed: While Go based tooling can be almost as fast, I wanted to build something faster and efficient with Rust. Why not? ◦ KDash uses way less memory/cpu than k9s and even Kubectl watch
  5. @deepu105 @oktaDev Rust = High level general purpose language •

    Multi-paradigm, ideal for functional, imperative and even OOP • Modern tooling • Ideal for systems programming, embedded, web servers and more • Memory safe • Concurrent • No garbage collection • Performance focused • Most loved language in Stack Overflow survey for 6 years in a row
  6. @deepu105 @oktaDev • About 70% of all CVEs at Microsoft

    are memory safety issues • Two-thirds of Linux kernel vulnerabilities come from memory safety issues • An Apple study found that 60-70% of vulnerabilities in iOS and macOS are memory safety vulnerabilities • Google estimated that 90% of Android vulnerabilities are memory safety issues • 70% of all Chrome security bugs are memory safety issues • An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were memory safety issues • Some of the most popular security issues of all time are memory safety issues ◦ Slammer worm, WannaCry, Trident exploit, HeartBleed, Stagefright, Ghost CVE galore from memory safety issues
  7. @deepu105 @oktaDev Security issues from thread safety • Information loss

    caused by a thread overwriting information from another ◦ Pointer corruption that allows privilege escalation or remote execution • Integrity loss due to information from multiple threads being interlaced ◦ The best-known attack of this type is called a TOCTOU (time of check to time of use) attack caused by race conditions
  8. @deepu105 @oktaDev Security issues from type safety • Low level

    exploits are possible in languages that are not type safe. • Type safety is important for memory safety as type safety issues can lead to memory safety issues "For comparison, last week we caught a significant race condition in another Kubernetes-related project we maintain called Helm (written in Go) that has been there for a year or more, and which passed the race checker for Go. That error would never have escaped the Rust compiler, preventing the bug from ever existing in the first place." – Microsoft team
  9. @deepu105 @oktaDev Zero cost abstractions “What you don’t use, you

    don’t pay for. And further: What you do use, you couldn’t hand code any better.” – Bjarne Stroustrup • Your programming style or paradigm does not affect performance • Number of abstractions does not affect performance as the compiler always translates your code to the best possible machine code • You could not get more performance from hand written optimizations • In-built abstractions are often more performant than hand written code • Compiler produces identical assembly code for almost all variations
  10. @deepu105 @oktaDev Tooling and community • Hands down, one of

    the best compilers out there and great backward compatibility • One of the best tooling you can find in terms of features and developer experience. Cargo is one stop shop for Rust tooling, build, compilation, formatting, linting, and so on • One of the best documentation, which is shipped with the tooling • A very diverse and vibrant community ◦ Community formed from other languages hence bringing in best of many ◦ Very welcoming and helpful ◦ Rapidly maturing ecosystem with growing number of libraries and use cases ◦ Has a forum which is used more than stack overflow for Rust • Big names like Google, Apple, Microsoft, Amazon and Facebook are already behind rust and investing it. • It’s on path to become the second supported language in Linux development. • Use case has already extended to embedded, web assembly, kubernetes, web development, game development and even client side • It’s only a matter of time until you can do any use case in Rust
  11. @deepu105 @oktaDev High level vs Low level language High level

    language • Human oriented • Easier to read • Portable • Need to be compiled to machine code • Not as efficient as a low level language • Provides features like memory management, abstractions and so on Low level language • Machine oriented • Harder to read • Hardware specific • Can be understood by machines • Fast and efficient • No fancy features
  12. @deepu105 @oktaDev High level language compromise • Safety • Speed

    • Abstractions With Rust we can get all three. Hence Rust is a high level language with performance and memory efficiency closest to a low level language. The only tradeoff you will make with Rust is the learning curve.
  13. @deepu105 @oktaDev Performance, Memory and power From the research paper

    “Energy Efficiency across Programming Languages”
  14. @deepu105 @oktaDev WebAssembly • WebAssembly System Interface (WASI) makes it

    possible to run Wasm workloads in Kubernetes ◦ Still quite new and has a lot of rough edges ◦ Could be the future of containerless Kubernetes. • Rust has one of the best tooling and ecosystem for WASM making it an ideal language to build WASI workloads for Kubernetes as well. • Wasmtime (a JIT-style standalone runtime) makes it possible to run Wasm outside of a browser and it is written in Rust. • WasmEdge is another runtime focused on microservices built using C++ and Rust. • WasmCloud is another runtime focusing on distributed actors and is written in Rust. • Krustlet is a Kubelet written in Rust and can run WASM OCI workloads in Kubernetes. https://developer.okta.com/blog/2022/01/28/webassembly-on-kubernetes-with-rust
  15. @deepu105 @oktaDev In cluster tools • Proxies/Sidecars/ServiceMesh ◦ Speed, safety

    and efficiency of Rust makes it the best choice for proxies and sidecars ◦ Linkerd proxy is written in Rust • K8s Operators ◦ Rust’s asynchronous programming model is a perfect match for building high performance/throughput/parallel operators ◦ Light on resource usage and footprint and less code to write • Log aggregation/Monitoring/eBPF ◦ Ideal for low footprint observability/tracing ◦ Redbpf: A Rust eBPF toolchain already exists
  16. @deepu105 @oktaDev User space tools • KDash: uses very minimal

    resources compared even to kubectl • Kubie: K8s context switching and prompt modification for shell • kubectl-view-allocations: kubectl plugin to list allocations • Click: Command Line Interactive Controller for Kubernetes
  17. @deepu105 @oktaDev Notable Libraries • kube-rs: Kubernetes client for Rust

    • K8s-openapi: Rust bindings for Kubernetes API • kubert: Rust Kubernetes runtime helpers • Roperator: Write kubernetes operator in Rust with minimal code • Rusoto: Rust SDK for AWS • aws-sdk-rust: Rust SDK for AWS • Prometheus-parser: parse and validate Prometheus query expressions
  18. @deepu105 @oktaDev Major Libraries used • tui-rs: Library to build

    rich terminal user interfaces and dashboards • Crossterm: Terminal manipulation library • Tokio: An event-driven, non-blocking async I/O platform • kube-rs (k8s-openapi, Openssl): Kubernetes client for Rust • kubectl-view-allocations: Library to fetch resource allocations for k8s • clap: Command line argument parser • rust-clipboard: cross-platform library for OS-level clipboard management • duct.rs: Library for running child processes • Serde: Serialization and deserialization library
  19. @deepu105 @oktaDev Data architecture • Event driven ◦ Async I/O

    using dedicated channels • Multi threaded ◦ Single data-store using ARC + Mutex ◦ Separate threads for UI, streams, network and CMD • Non-blocking UI ◦ Only bottleneck is network I/O with kube-api-server
  20. @deepu105 @oktaDev Challenges • Log streaming was blocking due to

    how the kube-rs lib works ◦ Solution: Seperate thread for log streaming with tokio-streams ◦ Some quirks exists and needs to be investigated and fixed • UI was blocking and not very smooth ◦ Solution: Seperate thread for network calls and event driven I/O • Kube-rs version updates are coupled to another library used ◦ No proper solution yet