Is containerless the future of Kubernetes?

WebAssembly has brought some great innovations to the Web. But lately, it has been finding its way to Kubernetes and cloud-native due to its efficiency & security. WebAssembly opens up a lot of possibilities in the cloud-native ecosystem and is a great alternative to containers. But if you are not familiar with WebAssembly it may all sound daunting and foreign. I'm here to break it all down and show you why it matters, how it works and what benefits it offers. We will look at how to get started with WebAssembly on Kubernetes using Krustlet, WasmEdge, and so on. We will look at implementations, use cases, and some examples. Get ready for an exciting ride.

Transcript

1. @deepu105 @oktaDev Is containerless the future of Kubernetes? Deepu K Sasidharan @deepu105 | deepu.tech
2. @deepu105 @oktaDev Hi, I’m Deepu K Sasidharan ➔ JHipster co-lead developer ➔ Java Champion ➔ Creator of KDash, JDL Studio ➔ Developer Advocate @ Auth0 by Okta ➔ Polyglot dev, OSS aficionado, author, speaker @deepu105 deepu.tech deepu105 deepu05
3. @deepu105 @oktaDev Containers on Kubernetes
4. @deepu105 @oktaDev Containers
5. @deepu105 @oktaDev Advantages of Containers • Container images are lightweight • Uses less system resources than a VM • Portable • Consistent and reproducible builds • Faster to boot and run • Easier to scale and manage • More secure • …
6. @deepu105 @oktaDev Limitation of Containers • Images are OS and architecture dependent ◦ Linux and Windows only • Needs a lot of low level OS primitives • Does not provide a fine grained control of security sandbox
7. @deepu105 @oktaDev Containerless == WebAssembly (WASM + WASI) WebAssembly.org
8. @deepu105 @oktaDev
9. @deepu105 @oktaDev WebAssembly on Kubernetes
10. @deepu105 @oktaDev WebAssembly on Kubernetes
11. @deepu105 @oktaDev Existing Ecosystem Compatibility https://wasmedge.org/book/en/kubernetes.html Registry Github Package Registry Azure Container Registry Google Container Registry Docker Hub Amazon ECR Distribution Language JS/TS Python Java PHP C/C++ C# (.NET) Ruby Swift Go Rust Kotlin
12. @deepu105 @oktaDev Advantages of WASM + WASI • Startup speed and near native execution speed ◦ A Wasm binary will finish execution before a docker image is initialized ◦ Near zero cold start times • Security isolation (memory isolation and sandbox) ◦ capability-based security model ◦ WASI applications follow the principle of least privilege • Memory safety and efficiency • Lightweight and portable(OS/Architecture)
13. @deepu105 @oktaDev Downsides of WASM + WASI • You can’t just take existing projects and make a Wasm binary ◦ Unlike containerized apps, Wasm applications needs to be built with compatible libraries and language. • Resource isolation is still not perfected • Networking is still being designed • Network isolation is still TBD • Not mature as still evolving • Ecosystem is quite small ATM
14. @deepu105 @oktaDev Wasm + Cloud Ecosystem
15. @deepu105 @oktaDev Krustlet • Kubelet written in Rust • Can run WASM OCI workloads in Kubernetes • Schedules WASM pods based on tolerations • CNCF sandbox project • Can be installed on most Kubernetes distributions including GKE, EKS, and AKS • Networking requires additional experimental plugins on source https://developer.okta.com/blog/2022/01/28/webassembly-on-kubernetes-with-rust
16. @deepu105 @oktaDev Krustlet
17. @deepu105 @oktaDev Wasmtime • An open-source JIT-style standalone runtime written in Rust • Makes it possible to run Wasm outside of a browser • WASM and WASI standard compliant • Fast and secure • Does not support networking ATM • Available as CLI and embeddable library for Rust, C/C++, Python, Go and .NET • Used by projects like Krustlet and Spin
18. @deepu105 @oktaDev Wasmer • An open-source runtime Wasm written in Rust • Focus on executing WebAssembly on the Server • Can run Wasm modules standalone or embedded in other languages • Fast and secure • Language integrations available for Rust, JS, C/C++, Go, Python, PHP, C# and Ruby • Used by Open Policy Agent, CleverCloud, Hyperledger, Scailable and so on.
19. @deepu105 @oktaDev WasmEdge • Wasm runtime focused on edge computing written in C++ • Powers serverless apps, embedded functions, microservices and IoT • Lightweight, high performance and extensible • CNCF Sandbox project • Compatible with Dapr and Kubernetes • Has C, Rust and Go SDKs • Can be used as an OCI compliant runtime on Kubernetes for Wasm workloads • Supports networking for wasm workloads • Baked into the crun container runtime https://wasmedge.org/book/en/kubernetes/quickstart.html
20. @deepu105 @oktaDev WasmCloud • Wasm runtime focusing on distributed actors written in Rust • Secure and fast • Has SDKs for Go and Rust • Can run on Kubernetes • Can bridge with apps running in Kubernetes • Uses OCI registries for artifacts
21. @deepu105 @oktaDev Fermyon • WebAssembly platform and tools for the cloud trying to reinvent cloud computing • Fermyon platform provides clustering, orchestration, service discovery, package management, HTTP proxy, and web UI • Spin is a OSS framework for building and deploying cloud microservices with WebAssembly ◦ Fast, secure, and composable ◦ Written in Rust • Bartholomew is a MicroCMS written in Rust for Wasm • Makes Kubernetes redundant in this setup
22. @deepu105 @oktaDev Future?
23. @deepu105 @oktaDev WebAssembly • WebAssembly on Kubernetes and cloud is still evolving ◦ More platforms and projects are upcoming • Rust has one of the best tooling and ecosystem for WASM making it an ideal language to build WASI workloads for Kubernetes and cloud ◦ We will start seeing more and more Rust projects in the space • Non-networking workloads are ideal use cases for now ◦ until networking spec is stable in WASI ◦ Workaround and plugins are available • Containerless is definitely on the horizon ◦ Wasm workloads ideally will coexist with Docker containers ◦ Docker containers will still be used for existing apps ◦ New applications might decide to be Wasm compatible ◦ Cloud providers have already started using Wasm for serverless applications
24. @deepu105 @oktaDev Thank You Deepu K Sasidharan @deepu105 | deepu.tech https://deepu.tech/tags#rust https://developer.auth0.com
25. @deepu105 @oktaDev Why Rust?
26. @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
27. @deepu105 @oktaDev Safe programming Programming Safety = Memory safety + Type safety + Thread safety
28. @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
29. @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
30. @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
31. @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
32. @deepu105 @oktaDev Zero cost abstractions
33. @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
34. @deepu105 @oktaDev Rust can be the ideal general purpose language
35. @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
36. @deepu105 @oktaDev High level language compromise • Safety • Speed • Abstractions Pick two
37. @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.
38. @deepu105 @oktaDev Performance, Memory and power From the research paper “Energy Efficiency across Programming Languages”
39. @deepu105 @oktaDev “Rust, not Firefox, is Mozilla’s greatest industry contribution” – TechRepublic