Is containerless the future of Kubernetes?

@deepu105
@oktaDev
Is containerless the
future of Kubernetes?
Deepu K Sasidharan
@deepu105 | deepu.tech

View Slide

@deepu105
@oktaDev
Hi, I’m Deepu K Sasidharan
JHipster co-lead developer
Java Champion
Creator of KDash, JDL Studio
Developer Advocate @ Okta
OSS aficionado, author, speaker, polyglot dev
@deepu105
deepu.tech
deepu105

View Slide

@deepu105
@oktaDev
Containers on Kubernetes

View Slide

@deepu105
@oktaDev
Containers

View Slide

@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
● …

View Slide

@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

View Slide

@deepu105
@oktaDev
Containerless == WebAssembly
(WASM + WASI)
WebAssembly.org

View Slide

@deepu105
@oktaDev

View Slide

@deepu105
@oktaDev
WebAssembly on Kubernetes

View Slide

@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

View Slide

@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)

View Slide

@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

View Slide

@deepu105
@oktaDev
Wasm + Cloud Ecosystem

View Slide

@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

View Slide

@deepu105
@oktaDev
Krustlet

View Slide

@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

View Slide

@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.

View Slide

@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

View Slide

@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

View Slide

@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

View Slide

@deepu105
@oktaDev
Future?

View Slide

@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

View Slide

@deepu105
@oktaDev
Thank You
Deepu K Sasidharan
@deepu105 | deepu.tech
https://deepu.tech/tags#rust

View Slide

@deepu105
@oktaDev
Why Rust?

View Slide

@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

View Slide

@deepu105
@oktaDev
Safe programming
Programming Safety = Memory safety + Type safety + Thread safety

View Slide

@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
○ Slammer worm, WannaCry, Trident exploit, HeartBleed, Stagefright, Ghost
CVE galore from memory safety issues

View Slide

@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

View Slide

@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
"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

View Slide

@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

View Slide

@deepu105
@oktaDev
Zero cost abstractions

View Slide

@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 ﬁnd 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 overﬂow 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

View Slide

@deepu105
@oktaDev
Rust can be the ideal general
purpose language

View Slide

@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

View Slide

@deepu105
@oktaDev
High level language compromise
● Safety
● Speed
● Abstractions
Pick two

View Slide

@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.

View Slide

@deepu105
@oktaDev
Performance, Memory and power
From the research paper “Energy Efficiency across Programming Languages”

View Slide

@deepu105
@oktaDev
“Rust, not Firefox, is Mozilla’s greatest
industry contribution”
– TechRepublic

View Slide

Is containerless the future of Kubernetes?

Is containerless the future of Kubernetes?

Deepu K Sasidharan

More Decks by Deepu K Sasidharan

Other Decks in Programming

Featured

Transcript