Type 1 Fun with Type 1 Hypervisors: The comeback of hardware-backed isolation
A talk by EDERA - one of the sponsors of Cloud Natice Rejekts.
The types of fun
- Just fun (fun to do, fun to remember)
- Fun after you’re finisehed, pain while you’re at it
- Not any fun (not while doing it, not afterwards) -> Maybe a good story
Hypervisors
I skipped the basic ideas of hypervisors in these notes
- Type 2: Runs on an existing OS and virtualizes devices to an emulated system -> Security/Isolation depends on the host-os
- Type 1: Runs on the hardware (manages hardware partitioning) -> Security/Isolation is in the hypervisor seperated from all other management stuff
Kubernetes joins the game
- Background: Kubernetes is built for containers and not for deep isolation
- Existing solutions: KubeVirt (manage KVM through KubeAPI)m kada Containers (Deeper Sandbox), GVisor (emulated syscalls)
- EDERA’s idea: Their own CRI (container runtime interface) that makes vm management transparent and can run vms alongside containers
- Potential Problems:
- Kubernetes assumes that cgropups exist
- Kublet assumes some calls for observability exist
- Scheduling between shared pod-memory and isolated vm-memory
- Their solutions:
- Processes: They have to fake a running process on the kubelet level even if the vm is owned by the hypervisor below
- Metrics: DRA and their own metrics server that bypasses kubelet in favor of the cri
Questions/Answers
- Their hypervisor is a fork of zen with some rust additions
- Live Migrations: They support it but kubernetes doesn’t (so if you use the hypervisor outside of kubernetes it works)