The Unikraft Project Makes Using Unikernels Easy
July 12, 2021
Research
Article shepherded by:
Rik Farrow
Thanks to their excellent performance, unikernels have always had a great deal of potential for revolutionizing the efficiency of virtualization and cloud deployments. However, after many years and several projects, unikernels, for the most part, have not seen significant, real-world deployment. In this article we argue that several factors contributed to this in the past, including lack of POSIX compatibility and the resulting lack of support for applications and languages, difficult or not widely adopted tooling ecosystems, lack of basic security features, and sometimes lessthan-stellar performance. After many years of work on the Linux Foundation’s Unikraft project, whose explicit goal is to tackle these issues directly, we believe that the time for unikernels to finally enter the main stage is now.
Unikernels [7] have always had great promise: high performance (sometimes even higher than Linux), lightweightness in the form of incredibly fast boot times (a few milliseconds) and severely reduced memory usage, as well as strong security benefits, to name a few metrics. But why hasn’t all of this potential materialized into wide use and deployment? We argue that in the past, four main reasons have hampered unikernels from becoming more widespread:
- POSIX Compatibility: Ultimately operating systems (and unikernels of course) are only as good as the applications they can run. Arguably, wide adoption depends solely on how good OSes are at running the applications and languages that people are interested in; for the most part, in the past, unikernels have had no or rather limited POSIX compatibility [10] (much more on this in Section Application Compatibility: System Calls Support).
- Tooling Ecosystem: Previous unikernel projects had little or no tooling ecosystems to improve usability. Those that did developed their own tools [4], partly because there hasn’t always been a clear de-facto standard as is the case now (e.g., Kubernetes for deployment). Asking potential users to adopt a new tooling ecosystem, or worse, having no such tooling, is always a tough ask and has been an obstacle to adoption.
- Modularity: In order to maximize lightweightness and performance through specialization, the unikernel should be fully modular. In the past, unikernel projects such as OSv and MirageOS [4, 7] relied on smaller, but still monolithic, kernels.
- Security: A few years back there were rather overblown claims about unikernels’ strong security [1]. Although unikernels do have some intrinsic features that could potentially make them more secure (e.g., a very small Trusted Computing Base, immutability, no console, etc.), unfortunately most past implementations have lacked basic security mechanisms such as stack protector and ASLR [8].
We argue that after many years of struggle and false starts, unikernels, and in particular the Unikraft [5] Linux Foundation project (www.unikraft.org) are coming of age: its fully modular design allows for extreme specialization (and thus performance and lightweightness), standard security features such as stack protector are in place, and in the past months we have been putting effort towards seamless integration with Kubernetes and Prometheus, arguably the de-facto standards for deployment and monitoring. We give a high level overview of Unikraft in Section Unikraft: a Modern, Fully Modular Unikernel, focusing on its high degree of modularity and the resulting performance/lightweightness benefits.
What about POSIX compatibility? While Linux has over 300 system calls, previous studies [11] have shown through static analysis that only a subset (224) are needed to run a Ubuntu installation. This number is actually an overestimation due to various reasons, including the fact that not all such applications make sense in a unikernel context (e.g., desktop applications) and the imprecision of static analysis. In Section Application Compatibility: System Calls Support we will show a thorough investigation of what’s actually needed to explain why Unikraft’s 160 implemented syscalls (and counting) are more than enough to run a wide spectrum of applications, including Redis, SQLite, nginx, HAProxy, TFLite and Memcached, and languages like Python, Ruby and Go, to name a few.
