Knowasiak

Knowledge Social Network

Sign up
𝕱𝖊𝖆𝖙𝖚𝖗𝖊𝖉

Unikernels

Knowasiak
Knowasiak
17 February 2022
77
Unikernels

Unikernels are specialised, single address space machine images constructed by using library operating systems — Wikipedia

Unikernels promise lightweight, secure, minimalistic image to boot and run. They assume being run in a secure hypervisor, so can do away with a lot of complexity of a modern OS. There are two main approaches:

  1. clean slate, where a new, minimal unikernel is written in a modern language
  2. strip-down, where an existing kernel is simplified to reduce its overhead and remove unnecessary features

TL;DR

Feb 2022 (is this out of date? Send a PR)

Despite a lot of hype around 2015-2016, the unikernels didn’t blow up in popularity the way that containers or Kubernetes did.

The main blockers for a wider adoption of unikernels appear to be:

  • compatibility with existing code
  • lacking debuggability (monitoring, logging, familar tools, …)
  • lacking universality – each unikernel only supports a subset of languages
  • lacking accepted standard (like Linux or Docker)
  • running as VMs means applications can’t share some resources (unused RAM) like they can in Linux containers

A few thoughts (correct me):

  • Security one of the strongest arguments for a unikernel is the reduced attack surface. While that’s difficult to argue with, that same approach makes for more difficult debugging. Similar to debugging a FROM SCRATCH container from inside the container. While this can be alleviated by baking in debugging and monitoring tools, this goes against the whole idea.
  • Lightweight another strong argument for unikernels: low overhead and small memory footprint. The flip side, is that you will need to allocate a certain amount of resources for your VM, that can’t be shared with other applications like they can with Linux containers. So you might not be able to flatpack as much as you can with containers.
  • Performance while a simple kernel without the overhead of syscall switch does increase the performance of some operations, it’s not clear how well that applies to applications for which the syscalls aren’t bottlecks. Besides, the high performance comes at a cost, so will only be an acceptable tradeoff for a subset of applications.
  • Debugging/Monitoring with the advent of eBPF, the visibility into the kernel has increased dramatically, so the standard have risen. Unikernels would need to provide a viable alternative for massive adoption to happen.
  • Scheduling containers now have a few options for scheduling (Kubernetes, Nomad, etc). Scheduling VMs with something like OpenStack would require a lot of improvement to get to the level of ease/speed that the container-specific solutions provide. This could be alleviated with things like Firecracker that can integrate with Kubernetes, but these haven’t exactly blown up in popularity either.
  • Compatibility containers package existing software and run it unchaged. Unikernels require compiling the kernel together with the application. There are some solutions that can produce a Linux binary for debugging and a kernel image for production. Keeping your unikernel (mostly) Linux-compatible is possible, but requires some glue.

Currently, the only two with commercial support I could find are Unikraft and NanoOS. If you’re looking to learn to make your own, check out StardustOS used to teach at St Andrews university, which includes a minimal kernel for Xen that’s easy to browse through.

Unikernels

Toolchains

Links

Papers

Books

Talks

Articles

Linux

Read More

Knowasiak
WRITTEN BY

Knowasiak

Hey! look, i give tutorials to all my users and i help them!