mirrors/krata
1
0
Fork 0
mirror of https://github.com/edera-dev/krata.git synced 2025-11-03 07:19:37 +00:00
Code Issues Packages Projects Releases Wiki Activity

added links in the tech overview (#475)

Browse Source
This commit is contained in:
Ann Wallace
2025-07-03 13:34:27 -07:00
committed by GitHub
parent 699c2e09ef
commit a58bb3b0fb
1 changed files with 12 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
technical-overview.md
View File

@ -10,24 +10,26 @@ And because Edera doesn’t rely on nested virtualization, it runs wherever cont
## How Edera Works ## How Edera Works
At its core, Edera uses a custom hypervisor based on Xen, with key components rewritten in Rust for safety, performance, and maintainability. Edera introduces the concept of **zones**—independent, fast-booting virtual machines that serve as security boundaries for container workloads. At its core, Edera uses a [custom hypervisor](https://edera.dev/stories/rust-or-bust-our-rewrite-of-the-xen-control-plane) based on [Xen](https://edera.dev/stories/why-edera-built-on-xen-a-secure-container-foundation), with key components rewritten in Rust for safety, performance, and maintainability. Edera introduces the concept of **zones**—independent, fast-booting virtual machines that serve as security boundaries for container workloads.
Each zone runs its own Linux kernel and minimal init system. The kernel and other system components are delivered via OCI images, keeping things composable, cacheable, and consistent. Each zone runs its own Linux kernel and minimal init system. The kernel and other system components are delivered via OCI images, keeping things composable, cacheable, and consistent.
Zones are paravirtualized using the Xen PV protocol. This keeps them lightweight and fast—no hardware virtualization required. But when hardware support is available (e.g., on x86 with VT-x), Edera uses it to get near bare-metal performance. Zones are [paravirtualized](https://docs.edera.dev/concepts/paravirtualization/) using the Xen PV protocol. This keeps them lightweight and fast—no hardware virtualization required. But when hardware support is available (e.g., on x86 with VT-x), Edera uses it to get near bare-metal performance.
## How Edera Runs & Secures Containers ## How Edera Runs & Secures Containers
Edera allows you to compose your infrastructure the same way you compose workloads: using OCI images. Edera allows you to compose your infrastructure the same way you compose workloads: using OCI images.
Each zone consumes a small number of OCI images: Each zone consumes a small number of OCI images:
- A **kernel image** that provides the zone kernel. - A **kernel image** that provides the zone kernel.
- One or more **system extension images** that provide init systems, utilities, and kernel modules. - One or more **system extension images** that provide init systems, utilities, and kernel modules.
- Optionally, **driver zones**—zones that provide shared services (like networking) to other zones. - Optionally, **driver zones**—zones that provide shared services (like networking) to other zones.
Inside each zone, container workloads run via a minimal OCI runtime called **Styrolite**, written in Rust. Unlike traditional setups (like Kata Containers, which layer containerd and runc as external processes), Styrolite is embedded inside the zone itself. Inside each zone, container workloads run via a minimal OCI runtime called [**Styrolite**]((https://github.com/edera-dev/styrolite/)), written in Rust. Unlike traditional setups (like Kata Containers, which layer containerd and runc as external processes), Styrolite is embedded inside the zone itself.
### Key Benefits of This Design ### Key Benefits of This Design
- No external container runtime processes - No external container runtime processes
- Zone init system directly manages containers - Zone init system directly manages containers
- Minimal attack surface, optimized for secure execution - Minimal attack surface, optimized for secure execution
@ -68,19 +70,26 @@ This causes the pod to be scheduled to a node running Edera’s hypervisor. The
An Edera zone is a minimal VM built from OCI-delivered components. At launch time, the Edera daemon unpacks: An Edera zone is a minimal VM built from OCI-delivered components. At launch time, the Edera daemon unpacks:
### Kernel Image ### Kernel Image
Located under `/kernel` in the OCI image: Located under `/kernel` in the OCI image:
- `image`: the Linux kernel (vmlinuz) - `image`: the Linux kernel (vmlinuz)
- `metadata`: key-value pairs for boot parameters - `metadata`: key-value pairs for boot parameters
- `addons.squashfs`: includes kernel modules in `/modules` - `addons.squashfs`: includes kernel modules in `/modules`
- `config.gz`: the kernel configuration file - `config.gz`: the kernel configuration file
### Initramfs Contents ### Initramfs Contents
Packaged in a CPIO archive, typically mounted from: Packaged in a CPIO archive, typically mounted from:
`usr/lib/edera/protect/zone/initrd` `usr/lib/edera/protect/zone/initrd`
The initramfs includes: The initramfs includes:
- `/init`: static Rust binary that initializes the zone - `/init`: static Rust binary that initializes the zone
- `/bin/styrolite`: embedded container runtime - `/bin/styrolite`: embedded container runtime
- `/bin/zone`: control plane for managing containers and services via IDM (inter-domain messaging) - `/bin/zone`: control plane for managing containers and services via IDM (inter-domain messaging)
This structure lets Edera launch zones rapidly, with well-defined boundaries and no dependency on the host OS kernel. Everything the workload touches is defined, versioned, and validated. This structure lets Edera launch zones rapidly, with well-defined boundaries and no dependency on the host OS kernel. Everything the workload touches is defined, versioned, and validated.
---
If you want to know more check out our [docs site](https://docs.edera.dev)