Edera architecture overview
TL;DR
Edera starts with a hypervisor based on Xen, with a majority of the components rebuilt in Rust for the modern cloud-native world. Edera implements the concept of zones, which are independent virtual machines running a Linux kernel and a minimal init service.
A zone is composed of a Linux kernel and a set of system extensions, each distributed as an OCI image. These aren’t heavyweight VMs—zones use paravirtualization (specifically the Xen PV protocol) to boot quickly and provide high performance.
Edera doesn’t require hardware virtualization, making it suitable for a wide range of environments. But if hardware virtualization is available, it’s used to match bare-metal performance. Otherwise, a minor performance tradeoff yields strong isolation that outpaces traditional container security boundaries.
What does Edera do?
Edera provides performant container isolation to all cloud or on-premise environments, unlocking a single platform to secure containers without management burden and costly migration. Deploying Edera to nodes in your Kubernetes cluster enables the ability to run a separate lightweight virtual machine for each workload, which has its own Linux kernel. This eliminates the risk of a shared kernel and provides a high degree of isolation without the standard tradeoffs.
How is Edera implemented?
Edera starts with a hypervisor based on Xen with a majority of the components rebuilt in Rust for the modern cloud-native world. Edera implements a concept called zones, which are independent virtual machines that run a Linux kernel and a tiny init service. A zone is composed of a Linux kernel and a set of system extensions, each distributed as an OCI image. A zone does not run with a heavyweight virtual machine; instead, it utilizes the paravirtualization support in the Linux kernel (specifically the Xen PV protocol) to boot Linux extremely quickly and provide a high degree of performance.
Importantly, Edera does not require hardware virtualization, which is not usually available in customer environments. This is possible with paravirtualization technology, which unlocks the ability to control and restrict memory and interrupts—a task that would normally require hardware instructions and controls. If hardware virtualization is available, it will be used by the hypervisor to provide equal performance to bare metal. If hardware virtualization is unavailable, a minor performance hit is taken from bare metal, while enabling a high degree of security that exceeds what is feasible with the standard namespace/cgroup strategy.
Why is hardware virtualization not a base requirement?
Edera was designed to not require hardware virtualization (often called nested virtualization) because of the inability to use such features across a wide variety of clouds, environments, and instance types. For example, on AWS the only way to get hardware virtualization is to use the metal instance types, which are much more costly. Edera runs on 98% of all AWS instance types, while a solution such as Kata Containers runs on just 7% of AWS instance types.
Users have stated clearly that the requirement to use bare metal is a huge prohibitive factor for adopting hard container isolation. gVisor is the only option available to these users, but gVisor has a significant performance hit, sometimes as high as 40% on common tasks such as building software on a CI/CD platform.
Edera has a minimal (<15%) performance impact from running in bare metal Docker in a worst-case scenario of a shared CPU with lots of preemption and no hardware virtualization. With hardware virtualization, the impact can be 1% or less. Adoption of container isolation across the industry requires a solution for users who do not have hardware isolation—whether it’s for their multi-cloud environment or their bare metal instances. Users also want a single way to run their containers securely. The management burden and risks of supporting multiple types of isolation make a unified platform clearly desirable.
Why not use KVM?
KVM is what most virtualization technologies have landed on. Although KVM is useful, it requires hardware virtualization. We were inspired by the Xen style of paravirtualization because of its ability to run across many environments and instance types. We knew that performance of gVisor, which is implemented in userspace, was extremely lacking.
Early research showed that Xen “paravirtops” in the Linux kernel performed significantly better than gVisor while not requiring the hardware virtualization that is known to be prohibitive to many users. Edera implements the majority of the hypervisor stack in Rust. Xen’s core hypervisor microkernel is utilized in automotive and safety-critical applications, such as in the infotainment system in some Tesla vehicles. Xen is also well supported on ARM, with ARM directly supporting Xen development.
Utilizing Xen’s base technology concepts while rewriting it for safety in Rust results in Edera having a close connection with the underlying hardware, making our platform extremely compelling to users—especially those leveraging Edera AI features that require deep hardware integration.
How does driver isolation work and what makes it different from Kata Containers?
One key differentiating factor from Kata Containers is that Edera is designed to be componentized such that each driver or device can be separated into its own zone. This is very different from Kata or other KVM projects, which rely on the root system running the VMM all in the same OS.
Edera allows you to compose your entire system with a set of OCI images that run in independent zones, and implements a concept called a driver zone. This lets Edera run zones that provide services to all or a subset of other zones.
Driver zones allow for a greater degree of isolation than Kata can attain. For example, a GPU driver stack like NVIDIA’s does not have to be installed on the host (root) OS. Instead, it can be packaged as an OCI image using Edera system extensions and run in a separate zone. This reduces the risk that vulnerabilities in the GPU stack could compromise the entire cluster.
Another advantage of this design is that storage and networking can be offloaded onto driver zones with hardware devices directly attached, and then those