diff --git a/content/day-2/02_type1fun.md b/content/day-2/02_type1fun.md new file mode 100644 index 0000000..c01409f --- /dev/null +++ b/content/day-2/02_type1fun.md @@ -0,0 +1,43 @@ +--- +title: Type 1 Fun with Type 1 Hypervisors: The comeback of hardware-backed isolation +weight: 2 +tags: + - rejekts + - virtualization +--- + + + + +A talk by EDERA - one of the sponsors of Cloud Natice Rejekts. + +## The types of fun + +1. Just fun (fun to do, fun to remember) +2. Fun after you're finisehed, pain while you're at it +3. 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) \ No newline at end of file