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

Is containerless the future of Kubernetes?

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.

Deepu K Sasidharan

June 24, 2022
Tweet

More Decks by Deepu K Sasidharan

Other Decks in Programming

Transcript

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

    View Slide

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

  3. @deepu105
    @oktaDev
    Containers on Kubernetes

    View Slide

  4. @deepu105
    @oktaDev
    Containers

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  8. @deepu105
    @oktaDev

    View Slide

  9. @deepu105
    @oktaDev
    WebAssembly on Kubernetes

    View Slide

  10. @deepu105
    @oktaDev
    WebAssembly on Kubernetes

    View Slide

  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

    View Slide

  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)

    View Slide

  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

    View Slide

  14. @deepu105
    @oktaDev
    Wasm + Cloud Ecosystem

    View Slide

  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

    View Slide

  16. @deepu105
    @oktaDev
    Krustlet

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  22. @deepu105
    @oktaDev
    Future?

    View Slide

  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

    View Slide

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

    View Slide

  25. @deepu105
    @oktaDev
    Why Rust?

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  32. @deepu105
    @oktaDev
    Zero cost abstractions

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  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.

    View Slide

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

    View Slide

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

    View Slide