KraftCloud(github.com)
github.com
KraftCloud
https://github.com/unikraft/unikraft
38 comments
Cynically awaiting an open sourced internal google product dealing with unikernel management and scaling which is woefully complex, utilizes its own nomenclature for simple concepts like 'input' and 'output'. Becomes foundational to can-you-even-scale-bro job interviews. Appears on every bootcampers resume. Now each job posting requires 10 years of experience in it which is more or less organizing its nonsensical convoluted yaml files.
This is related to an earlier post [0] and shows the underlying open-source repo.
[0]: https://news.ycombinator.com/item?id=39902949
[0]: https://news.ycombinator.com/item?id=39902949
Hi, Alex here from Unikraft, that's right!
You can find more information about Unikraft here:
- https://unikraft.io -- The Unikraft Company
- https://unikraft.org -- The open-source project
- https://kraft.cloud -- The Millisecond Cloud Platform based on Unikraft
You can find more information about Unikraft here:
- https://unikraft.io -- The Unikraft Company
- https://unikraft.org -- The open-source project
- https://kraft.cloud -- The Millisecond Cloud Platform based on Unikraft
Conceptually I really like unikernels, but I don't think they have much purpose in the software world today.
A lot of companies aren't running their stuff on metal anymore, they're running on Kubernetes. It's what people know and are familiar with. How many people know unikernels? How do you even debug an app running on a unikernel? How do you convert a "legacy" app to be runnable on a unikernel?
There are already very stripped down Linux distributions out there for running apps on Kubernetes like Bottlerocket OS. This removes the majority of the attack surface that unikernels remove. And you get to keep the Linux ABI.
Unikernels may strip out a lot of bloat and attack surface, but they also introduce a lot of complexity of their own.
A lot of companies aren't running their stuff on metal anymore, they're running on Kubernetes. It's what people know and are familiar with. How many people know unikernels? How do you even debug an app running on a unikernel? How do you convert a "legacy" app to be runnable on a unikernel?
There are already very stripped down Linux distributions out there for running apps on Kubernetes like Bottlerocket OS. This removes the majority of the attack surface that unikernels remove. And you get to keep the Linux ABI.
Unikernels may strip out a lot of bloat and attack surface, but they also introduce a lot of complexity of their own.
> Most people don't run metal today
We are seeing an increasing trend towards On-prem/Cloud-prem/Co-los[0], mainly due to cost and reduced complexity. Inversely, most smaller companies (1-10 emp) who use hyperscalers do not use their metal offerings, because of cost. They wish to scale with demand which metal cannot provide. Using EKS and other similar services have the benefit of being familiar and elastic, but are in fact slow and soon become quite expensive[1].
[0]: https://www.gartner.com/en/newsroom/press-releases/2023-05-1...
[1]: https://a16z.com/the-cost-of-cloud-a-trillion-dollar-paradox...
> How many people know unikernels?
This has been a goal of Unikraft for a long time, to make using unikernels simple and familiar to use (in fact, transparent). This is why we use OCI images as the root filesystem; why it's possible to start unikernels through Docker; why we have several types of Kubernetes integrations.
> How do you debug a running app?
For one, you can attach a gdb server and step through both application code and kernel code together. Secondly, at Unikraft at least, we are introducing a virtual shell that allows you to introspect the filesystem, main threads, see system stats, etc.
> Stripped down Linux distros reduces attack surface
This is may reduce the attack surface, but one bad-actor application can still take down the host and all the other containers since they are still process (software) isolated. With unikernels you get hardware-level isolation AND, interestingly, the performance thanks to the lack of strong syscall boundaries.
> Unikernels increase complexity
Give us a chance and try out one of our examples :-)
https://github.com/unikraft/catalog/tree/main/examples
We are seeing an increasing trend towards On-prem/Cloud-prem/Co-los[0], mainly due to cost and reduced complexity. Inversely, most smaller companies (1-10 emp) who use hyperscalers do not use their metal offerings, because of cost. They wish to scale with demand which metal cannot provide. Using EKS and other similar services have the benefit of being familiar and elastic, but are in fact slow and soon become quite expensive[1].
[0]: https://www.gartner.com/en/newsroom/press-releases/2023-05-1...
[1]: https://a16z.com/the-cost-of-cloud-a-trillion-dollar-paradox...
> How many people know unikernels?
This has been a goal of Unikraft for a long time, to make using unikernels simple and familiar to use (in fact, transparent). This is why we use OCI images as the root filesystem; why it's possible to start unikernels through Docker; why we have several types of Kubernetes integrations.
> How do you debug a running app?
For one, you can attach a gdb server and step through both application code and kernel code together. Secondly, at Unikraft at least, we are introducing a virtual shell that allows you to introspect the filesystem, main threads, see system stats, etc.
> Stripped down Linux distros reduces attack surface
This is may reduce the attack surface, but one bad-actor application can still take down the host and all the other containers since they are still process (software) isolated. With unikernels you get hardware-level isolation AND, interestingly, the performance thanks to the lack of strong syscall boundaries.
> Unikernels increase complexity
Give us a chance and try out one of our examples :-)
https://github.com/unikraft/catalog/tree/main/examples
> With unikernels you get hardware-level isolation AND, interestingly, the performance thanks to the lack of strong syscall boundaries
How does this compare to gVisor? My understanding is that it's the same.
Thanks for the detailed response. I might give it a go some weekend.
How does this compare to gVisor? My understanding is that it's the same.
Thanks for the detailed response. I might give it a go some weekend.
In fact gVisor is the opposite, it injects more guard instructions between the application and the kernel across the syscall layer in order to make stronger security guarantees. These additional guards slow the application even further by however long it takes to perform necessary permission checks.
It is not necessary to have such checks in a unikernel because the kernel inherently trusts the application because together they were constructed in the same pipeline. The hardware then protects the two together.
It is not necessary to have such checks in a unikernel because the kernel inherently trusts the application because together they were constructed in the same pipeline. The hardware then protects the two together.
Out of curiosity when you say "we", what vantage point are you referring to?
I was under the impression that containers/Kubernetes actually depend more on the kernel than virtualization as they run the containers by sharing the kernel? I may be misunderstanding it and need some HN knowledge power!
The approach is similar to how to debug or convert an application to run on serveless, or cloud managed runtimes.
The unikernels benefit is exactly for such cloud offerings to be even leaner in resource usage.
The unikernels benefit is exactly for such cloud offerings to be even leaner in resource usage.
So the market for this is cloud providers? If so, I think it's failed. Amazon, Cloudflare, et al have already developed their own lightweight runtimes based on Firecracker/V8.
They might not be quite as light as unikernels, but within the same order of magnitude for sure, and I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible.
They might not be quite as light as unikernels, but within the same order of magnitude for sure, and I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible.
Why would it automatically fail just because others have ship their products first? It's always good when new ideas are tried and bring something new to the table. Never say never.
> I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible.
I have been following the news on Unikraft development for a few years now (since 2019 I think) and now fortunately am a beta tester on kraftcloud. I have seen their website and documentation transform from something that only linux kernel wizards would use to what it is now. So definitely they put some work on making sure unikraft is easy to adopt.
As the current state of kraftcloud, some apps can already be deployed by copy-pasting the config file (that usually consists of 4 or so lines), install the CLI and hit the deploy button. If you want to enable the scale-to-zero you only need to put -0 at the end of the deploy command. If your use cases not covered in their documentation asking their support or joining the discord is a good start if you don't want to deal directly with the "complexity" (which from my experience mainly consist of copy-pasting some .so files into the root folder).
> I doubt the savings justify additional development complexity. As a cloud provider, your goal is to make your services as easy to adopt as possible.
I have been following the news on Unikraft development for a few years now (since 2019 I think) and now fortunately am a beta tester on kraftcloud. I have seen their website and documentation transform from something that only linux kernel wizards would use to what it is now. So definitely they put some work on making sure unikraft is easy to adopt.
As the current state of kraftcloud, some apps can already be deployed by copy-pasting the config file (that usually consists of 4 or so lines), install the CLI and hit the deploy button. If you want to enable the scale-to-zero you only need to put -0 at the end of the deploy command. If your use cases not covered in their documentation asking their support or joining the discord is a good start if you don't want to deal directly with the "complexity" (which from my experience mainly consist of copy-pasting some .so files into the root folder).
As Oxide, Joyent. Netfly, Vercel, GraalOne,... are showing, there is a lot of market out there beyond hyperscalers.
One doesn't need to be yet another AWS to be a sustainable business.
One doesn't need to be yet another AWS to be a sustainable business.
Was totally expecting this to be about the Kraft food company creating their own cloud service as an April fools joke.
Oddly enough, I was wondering if this project for some reason came from Unilever -- the logo is quite similar!
Their dev kit would include a Mac and cheese.
Another unikernel.
I wonder how mature is that.
I wonder how mature is that.
Hi,
[Disclaimer, I'm one of the maintainers]
Another unikernel yes, sorry about that! :) . Unikraft started back in 2017 initially as a research project, and has been a Linux Foundation OSS project since 2018.
While Unikraft OSS is used in different use cases, our primary target is cloud deployments. Unikraft has 3 key principles:
1. A fully modular OS -- so that we can specialize the resulting unikernels (VMs) as much as possible
2. Linux-API compatibility -- so that we don't break applications
3. Integration with Docker/Dockerfiles (and other tools) -- for ease of use
Unikraft powers kraft.cloud . You can see the platform's guides to get an idea of the apps/frameworks it supports: https://docs.kraft.cloud/guides/
[Disclaimer, I'm one of the maintainers]
Another unikernel yes, sorry about that! :) . Unikraft started back in 2017 initially as a research project, and has been a Linux Foundation OSS project since 2018.
While Unikraft OSS is used in different use cases, our primary target is cloud deployments. Unikraft has 3 key principles:
1. A fully modular OS -- so that we can specialize the resulting unikernels (VMs) as much as possible
2. Linux-API compatibility -- so that we don't break applications
3. Integration with Docker/Dockerfiles (and other tools) -- for ease of use
Unikraft powers kraft.cloud . You can see the platform's guides to get an idea of the apps/frameworks it supports: https://docs.kraft.cloud/guides/
The part that I don't understand about 'fully modular' unikernels, is that you can build a linux kernel with exactly what features you want, but no one does that, so why would they do this?
In fact this is not true with Linux. We did a study of this[0] and found that there are too many interdependencies between Linux kernel subsystems. The smallest, usable Linux kernel we test with sometimes is around 30MB.
In comparison, compiling NGINX together with Unikraft results in a kernel size of under 2MB. This means that there is 28MB of kernel we didn't need or want.
[0]: https://arxiv.org/abs/2104.12721 (See Figure 1)
In comparison, compiling NGINX together with Unikraft results in a kernel size of under 2MB. This means that there is 28MB of kernel we didn't need or want.
[0]: https://arxiv.org/abs/2104.12721 (See Figure 1)
You can get an uncompressed Linux image (built with only virtio support, including SMP and networking) under 12MB; it's not 2, but also not 30MB.
This is without LTO, so you could probably get it lower.
It has a menuconfig :D
At least I know from talking to Alex that they actually know what users and people playing with kernels like in his toolchain.
Kraftcloud is just them eating their own dogfood. In my opinion it's all about the toolchain(I mean not only) and these people understand that.
In my opinion Linux didn't win because it has the best design on every front. It won, because it had the easiest toolchain for someone like me with zero experience to just read a total after school and start building a kernel.
This is similar. Building is simple, configuring is simple, packaging is simple. It has the added bonus of having people behind it, that are ALSO good researchers.
I hope that at some point they will pay for a professional audit, but it's already awesome to see where they got.
At least I know from talking to Alex that they actually know what users and people playing with kernels like in his toolchain.
Kraftcloud is just them eating their own dogfood. In my opinion it's all about the toolchain(I mean not only) and these people understand that.
In my opinion Linux didn't win because it has the best design on every front. It won, because it had the easiest toolchain for someone like me with zero experience to just read a total after school and start building a kernel.
This is similar. Building is simple, configuring is simple, packaging is simple. It has the added bonus of having people behind it, that are ALSO good researchers.
I hope that at some point they will pay for a professional audit, but it's already awesome to see where they got.
very good point. the world is devolving into everything is a jvm for the linux api, and the one with menuconfig at least sounds funny
Also what is the particular use case here? Why use it over one of the other kernels out there? I see a lot of 'safe' and 'modern' but nothing showing how it is better/worse than the competition. What are the trade offs here? What do you get with this kernel and what is missing?
Hi, [disclaimer, I am a project maintainer].
The key difference between unikernels (and library OSes) vs. other kernels is that each kernel is different with a unikernel. Your application goes through a process of specialization, where you can decide exactly the necessary features (e.g. libraries, syscalls, memory allocation, scheduler, etc.) are necessary or desired for your application. Additionally, other kernels are typically multi-process whereas a unikernel is inherently single-process since it does not support syscalls like fork. (That said, at Unikraft, we are working on supporting fork, eta. late April).
Additionally, before Unikraft, one of the major trade-offs was developer time and effort to get your application into a unikernel. Since Unikraft has been actively developed for several years by ~100+ people, it has become much more stable, feature complete and easier to use; ultimately making unikernels easier to approach.
Today, in-addition to multi-process applications, the trade-off now really depends on your usecase and so selecting whether you wish to deploy your application as a unikernel or on top of a monolithic kernel or microkernel. For example, developer environments which require many subsystems, multiple programs, etc., where you can't know everything ahead-of-time, are still best suited for multi-user, monolithic kernels that can run most workloads.
Another thing to note is that unikernels are designed to be immutable and are often created in a CI/CD context. This means that they are single-purpose and if you wish to change them, you need to re-build (or re-package).
The key difference between unikernels (and library OSes) vs. other kernels is that each kernel is different with a unikernel. Your application goes through a process of specialization, where you can decide exactly the necessary features (e.g. libraries, syscalls, memory allocation, scheduler, etc.) are necessary or desired for your application. Additionally, other kernels are typically multi-process whereas a unikernel is inherently single-process since it does not support syscalls like fork. (That said, at Unikraft, we are working on supporting fork, eta. late April).
Additionally, before Unikraft, one of the major trade-offs was developer time and effort to get your application into a unikernel. Since Unikraft has been actively developed for several years by ~100+ people, it has become much more stable, feature complete and easier to use; ultimately making unikernels easier to approach.
Today, in-addition to multi-process applications, the trade-off now really depends on your usecase and so selecting whether you wish to deploy your application as a unikernel or on top of a monolithic kernel or microkernel. For example, developer environments which require many subsystems, multiple programs, etc., where you can't know everything ahead-of-time, are still best suited for multi-user, monolithic kernels that can run most workloads.
Another thing to note is that unikernels are designed to be immutable and are often created in a CI/CD context. This means that they are single-purpose and if you wish to change them, you need to re-build (or re-package).
Unikraft has been around for a while I think.
Looks like microVM.
That's a giant stretch. Kraft is a surname. I assumed it was an April fools joke that Kraft the cheese company was making their own cloud (which would be hilarious).
I wonder whether we could get Kraft to sponsor us :) . Unikraft used to be called Unicraft but was changed to a "k" for name clash reasons. Agree that names are hard.
I jumped to Kraft Dinner and wondered why that was the kind of perception you’d want to cause people to have about your product.
Kraft Dinner and Kraft Singles, my two favourite almost cheese products.
Names are really hard.
Kraft Dinner and Kraft Singles, my two favourite almost cheese products.
Names are really hard.
Sounds like craft. Seems more likely to me an intentional misspelling of “craft” or related to the Kraft Foods company if you’re in the US.
Absolutely nothing about this headline had me thinking about consensus protocols.
Absolutely nothing about this headline had me thinking about consensus protocols.
LOL. Kraft is german for power/strength.
I caught on to that immediately. My statement was meant to mean that it would so so unlikely to indicate the Raft protocol, that it’s more likely to have been a reference to these other things. It is not a reference to those things, but it even less of a reference to Raft.
Yes, we're a German company, it's a play on words :)
Kraft is just a the German word for strength or force.
The parent is downvoted because the original comment contained some stretch logic talking about possible confusion with Raft consensus protocol due to naming similarities, the current comment is after the ninja edit.
And Kraft (Kafka without Zookeeper).
Yes, our kraft CLI tool (https://github.com/unikraft/kraftkit/) definitely has a clash with KRaft .