UKL: A Unikernel Based on Linux
next.redhat.com
next.redhat.com
However, I am still skeptical of the idea that unikernels will ever be production friendly. The biggest deficiency, by the definition of a unikernel, is the complete lack of debugging tools available. There is no top, perf, etc in a unikernel. In docker, I can still exec into a running container to debug and investigate. Unikernel issues lend themselves to “just restart it” rather than “let’s debug and fix it” mindsets.
I’ve run a k8s environment with kata containers for a while and as time has gone on, I’ve found that Solaris Zones (smartOS) are probably the most scalable way to achieve process/VM isolation for applications.
one of the biggest misconceptions about unikernels is that they are somehow of a slimmed down linux - it's easier to think about them as individual programs provisioned as vms - would you ssh into a process? why?
all 'debugging' tools work perfectly fine w/unikernels although I'd draw a fine line between real application level debugging which should never happen on production and ops tooling
Sorry, but that's just plain wrong. One very common reason why people do that is, because performance debugging may give very different results on dev, staging and production systems that's why people want tooling that gives them as accurate as possible application level debugging information without impeding the behavior of the system. It's a very common problem in large scale systems.
And you will want a mechanism to iterate quickly to see effects of tweaks.
Eventually you have built an interactive debugger.
One that could improve.
Oh god, I wish. It's more common that you probably think.
You have a lot of options approximating this with a lot of thicker runtimes like Java/JVMs and Erlang/BeamVM or interpreted REPL'd languages like Python or Lisps. And they're incredibly useful.
Pulling up a REPL into a running process like a JS console in the browser is basically the same thing.
The kernel debugging technology exists for a long time now, and I don't think its far fetched to see public clouds exposing those abilities in a secure manner, and unikernels including their own tools for remote debugging. Any kernel can be debugged, and unikernels are no exception.
Answer: you don't. You don't know what corner you're painting yourself into.
The linux kernel, outside of its excessive amounts of drivers, is full of code that is useful for computers, vms, and containers in lots of different situations: normal operation, compromised, at load, in distress, etc.
I doubt you can even make a list of the utilities you'd need ahead of time for getting stats on the container's state. network? disk? processes? memory?
Linux obviously used to scale to very constrained computers (386/486s with a couple megs of ram was the PC state of the art when Linux was initially developed) up to the current supercomputers and large vms on AWS and other vendors.
A lot of the size bloat in linux for container images is the drivers. For containers and VMs, one really doesn't need all the driver variants because a VM/container should just be presented a limited virtual hardware interface. Then you could greatly reduce the driver portion of the monokernel.
Once you get rid of that, linux should probably concern itself with a couple "power of 1000" kernels.
kiloherz/kilobytes of ram (maybe not even bother with this) aka the 80s computer. Since this is an 8 or 16 bit computer, linux may not be practically back-scalable to this mode of computing, but I don't know linux history enough
megahertz/megabytes of ram aka the 90s computer aka the 32 bit era.
gigahertz/gigabytes+ (2000s to modern) aka the 64 bit era.
terascale is basically served by 64 bit kernels afaik.
Your typical container will basically fit into one of these profiles I would guess. But the basic linux/unix model should work for every one of them... because it has, since the 70s, on machines from the PDP-7 on up.
So IMO, container focused derivatives of Linux should concentrate work on tailoring to these levels.
Container applications should basically be targetted at one of the levels.
Granted, maybe the 1000 factor jump is a bit big. Economically there is a big difference between 1, 10, 100 MB and gigabyte memory spaces in particular, and what you can cram into a machine or pod. But the KB image should be able to overlap with the low end MB (although that takes ugly segmentation pointers and other memory extension hacks). The MB image can DEFINITELY encroach on the low end GB image.
And a blog writeup on it: https://blog.acolyer.org/2018/11/14/unikernels-as-processes/
disclaimer: I'm interested in nabla containers and have an open PR on the runtime.
https://github.com/razaaliraza/ukl
Now that I think about it a little more, they're kind of similar but I think unikernels are more of a way to get an application to run on hardware without all the extra bloat of a monolithic kernel (like if you're running a web service on a small virtualized machine) and the LKL is just for re-using Linux code.
I have yet to see a production stack without this.
UML is pretty much in use on the enterprise space.
UML runs Linux kernel in ring 3. It emulates hardware protection mechanisms in order to make debugging easier and to run VMs when there is no kernel access.
UKL runs userspace apps in ring 0. It discards hardware protection mechanisms in order to make processes run faster, decrease boot time, and decrease management overhead.
In this sort of setup, unsafe Rust is like kernel code -- it effectively has privilege to read/write to any memory.
I'd also feel better if the kernel itself were written in something like Rust.
You don't have the risk of leaking secrets or malicious interference between applications that are supposed to be isolated if you've only got one app, but I could still see where someone might rather have memory protection than not in a single-user/single-application environment.