[deleted]
Ignite – Use Firecracker VMs with Docker images
11–20 of 84 posts
Re: Ignite – Use Firecracker VMs with Docker images
#12[deleted]
Re: Ignite – Use Firecracker VMs with Docker images
#13Earlier quoted context omitted.
I think lightweight VMs will have a major impact. VMs are powerful and solve legions of problems that arise trying to make containers match them, which is exactly the road currently being paved by so much of Kubernetes. Firecracker has a number of limitations, however. Firecracker is tailored to the highly vertical 'lambda' use case and too much of the power of the kernel and userspace is stripped away. You can't eve…
Why would you want to migrate a firecracker vm? They are supposed to be for small, short lived processes. Or in this case, Docker containers (which are likely to be controlled by some kind of orchestration). If you want to be able to migrate a running VM, do you still really need it to start super fast? It’s going to be a long lived service (otherwise you wouldn’t migrate it), so a longer spin up time should be accep…
I think that is GP's point: Firecracker shouldn't be considered a general-purpose solution for more secure containerized workloads.
Re: Ignite – Use Firecracker VMs with Docker images
#14Earlier quoted context omitted.
Which kernel powers are you specifically talking about having been stripped away, and how are they relevant to serverside workloads? GPUs are the common one that gets brought up, but I'm not familiar with many others. Firecracker doesn't strip anything out of the guest kernel --- it boots a vanilla Linux kernel, which can be as heavy or light as you compile it to be.
From https://firecracker-microvm.github.io/ : Firecracker is an alternative to QEMU that is purpose-built for running serverless functions and containers safely and efficiently, and nothing more. Firecracker is written in Rust, provides a minimal required device model to the guest operating system while excluding non-essential functionality (only 5 emulated devices are available: virtio-net, virtio-block, virtio-vsoc…
Can you be specific about what those hardware things are, and why they matter for serverside workloads? Yes: the premise of Firecracker is that the hypervisor only supports the virtio devices, and doesn't emulate real hardware. Where does that end up being problematic?
I'm not sure what you mean by your "CPU and memory" being "limited", either.
Re: Ignite – Use Firecracker VMs with Docker images
#15Earlier quoted context omitted.
Why would you want to migrate a firecracker vm? They are supposed to be for small, short lived processes. Or in this case, Docker containers (which are likely to be controlled by some kind of orchestration). If you want to be able to migrate a running VM, do you still really need it to start super fast? It’s going to be a long lived service (otherwise you wouldn’t migrate it), so a longer spin up time should be accep…
I think that is GP's point: Firecracker shouldn't be considered a general-purpose solution for more secure containerized workloads.
Can you try to make that a little more specific? What does "general-purpose" mean here? "Secure containerized workloads" tends to imply serverside. It's hard to think of things --- other than GPU access --- that Firecracker takes away here.
Re: Ignite – Use Firecracker VMs with Docker images
#16The major reason for the initial excitement about containers was the relative efficiency as compared to VMs. I understand that Firecracker has a low memory overhead and a fast startup time but I'd be interested to know what the virtualization overhead is in terms of cpu performance. I poked around on google a bit for a few minutes but didn't find anything.
Re: Ignite – Use Firecracker VMs with Docker images
#17The major reason for the initial excitement about containers was the relative efficiency as compared to VMs. I understand that Firecracker has a low memory overhead and a fast startup time but I'd be interested to know what the virtualization overhead is in terms of cpu performance. I poked around on google a bit for a few minutes but didn't find anything.
My understanding is that it's just KVM under the hood, so cpu perf should match KVM. Firecracker is mostly just optimizing startup time and memory overhead.
Re: Ignite – Use Firecracker VMs with Docker images
#18Earlier quoted context omitted.
I think lightweight VMs will have a major impact. VMs are powerful and solve legions of problems that arise trying to make containers match them, which is exactly the road currently being paved by so much of Kubernetes. Firecracker has a number of limitations, however. Firecracker is tailored to the highly vertical 'lambda' use case and too much of the power of the kernel and userspace is stripped away. You can't eve…
Why would you want to migrate a firecracker vm? They are supposed to be for small, short lived processes. Or in this case, Docker containers (which are likely to be controlled by some kind of orchestration). If you want to be able to migrate a running VM, do you still really need it to start super fast? It’s going to be a long lived service (otherwise you wouldn’t migrate it), so a longer spin up time should be accep…
> Why would you want to migrate a firecracker vm?
I wouldn't. I pointed out the lack of live migration as an of example why firecracker can't cut it as the basis of general purpose VM orchestration platform.
> then you can use a different VM tech that supports migration (KVM/Xen/etc)
"KVM/Zen/etc" are in the dark ages compared to the state of the art of Kubernetes container orchestration.
The reason for that isn't technical; KVM is incredible and full-featured VMs conceivably could be orchestrated with the same fidelity as containers. The reason is business: the cloud behemoths invest only in their serverless business models; thus k8s, firecracker, etc. I contend there is an enormous market for orchestration of more complex workloads that VMs suit well.
Re: Ignite – Use Firecracker VMs with Docker images
#19Earlier quoted context omitted.
I think that is GP's point: Firecracker shouldn't be considered a general-purpose solution for more secure containerized workloads.
Can you try to make that a little more specific? What does "general-purpose" mean here? "Secure containerized workloads" tends to imply serverside. It's hard to think of things --- other than GPU access --- that Firecracker takes away here.
> It's hard to think of things
No, it isn't. Investigate the K8S world and observe the backflips and somersaults being performed there to deal with networking and storage. Much of that is a consequence of people trying make containers do things that should be run in VMs. A full featured Linux kernel and certain key user space tools can obviate much of that nonsense with ease, deliver better performance, use less resources and be vastly less complex.
Re: Ignite – Use Firecracker VMs with Docker images
#20Earlier quoted context omitted.
Can you try to make that a little more specific? What does "general-purpose" mean here? "Secure containerized workloads" tends to imply serverside. It's hard to think of things --- other than GPU access --- that Firecracker takes away here.
> It's hard to think of things No, it isn't. Investigate the K8S world and observe the backflips and somersaults being performed there to deal with networking and storage. Much of that is a consequence of people trying make containers do things that should be run in VMs. A full featured Linux kernel and certain key user space tools can obviate much of that nonsense with ease, deliver better performance, use less reso…
If it's not hard to name a thing that Firecracker makes difficult for a serverside workload, could you... name one?
Firecracker runs a full-featured Linux kernel. It's a hypervisor. It's not a kind of kernel.