Live data from Hacker News

Ignite – Use Firecracker VMs with Docker images

github.com

81–84 of 84 posts

Re: Ignite – Use Firecracker VMs with Docker images

#81
post #76

Earlier quoted context omitted.

I think the other way to look at it is there's just different workloads that need different solutions. Firecracker is perfect for Lamba-style workloads . But some companies (who don't want to manage datacenter resources, but do want the large scale and flexibility of cloud computing) want a whiz-bang multi-tenant enterprise containerized solution (say, using K8s as orchestrator). And maybe one of their critical appli…

What you're calling a "Lambda-style workload" really seems to capture >95% of the EC2-style workload.

I'll bet you it's more like 85%. AWS has a good amount of hardware designed to pass through into the VM, various custom guest drivers, some advanced high-performance networking stuff, and the GPU support like you mentioned. Customers probably pay a hefty premium, so we shouldn't discount it from either a business or technical perspective.

Re: Ignite – Use Firecracker VMs with Docker images

#82
post #74

Earlier quoted context omitted.

Assume any suggestion starting with "just" is equally obvious to the operators as it is to you. In this case, it would be helpful to start from the observation that live migration is non-negotiable, which immediately rules out any form of "turn it on then off again."

In this case, I think the “just” is justified. (Normally I’d agree with you) If you’re starting from the premise that live migration is non-negotiable, then I’d argue that you likely don’t need a quick start. Long lived services can afford a slower start using a different VM technology. We’re not talking hours to provision a server, but the difference between 100ms and a few minutes. My question to you is — what kind…

Doesn't matter what the service is. The features are used and therefore valued by two different audiences (who may in some circumstances be the same individuals wearing different hats). Live migration: platform ops. Fast boot: platform users.

The platform ops people want to offer the best service possible to the platform users. Fast boot is a feature users may want for their services, so the operators want to offer it. It's directly user-facing, and is a feature users can evaluate on when selecting the platform.

The platform ops people also want to offer high uptime and good performance. So behind the scenes they use live migration to mitigate host risk and balance load. Live migration is not user-facing, and is not a feature users can or should evaluate on when selecting the platform, because they shouldn't have to care.

> what kind of service would need to start fast and be able to migrate?

For ops, all VMs need to be able to migrate. For users, some services need fast boot. Therefore all services that need fast boot also need to migrate.

Re: Ignite – Use Firecracker VMs with Docker images

#83
post #64

Earlier quoted context omitted.

"guarantees". cgroups are indeed designed for isolation, but they are a feature that's been added on over time and still exposes the entire kernel as attack surface. It's considered way less trustworthy than VMs, especially minimal-surface ones like Firecracker.

So, marketing hype to sell your clients, not a real technical use-case. Cgroups and kvm are basically the same age (kernel support in 2.6) so saying “cgroups is newer so it must be more insecure” is fairly false. Firecracker is, in fact, quite new, and may or may not be more vulnerable as it is a completely new implementation of a kernel.

Firecracker is essentially just KVM with some extremely opinionated choices to allow it to be as fast as it is. I’m hand-waving over a lot here but to differentiate it from KVM isn’t very useful here.

Re: Ignite – Use Firecracker VMs with Docker images

#84
post #41

Earlier quoted context omitted.

I have the same question. WeaveWorks has another project called footloose which allows docker containers to be used like VMs. Also dead. The only other project/company (aside from Kata) promoting firecracker was Talos. But not sure if they maintain their integration still. https://www.talos.dev/v1.2/reference/cli/#talosctl-cluster-c...

Talos no longer supports creating a cluster automatically in a firecracker VM (which you can still do in docker, via `talosctl cluster create`) but you can certainly run Talos Linux in firecracker VMs and create a cluster that way.

Interesting. So Talos is both a Linux and a k8s distribution?

I am less interested in running k8s itself in Firecracker (or kata, or similar), but the pods started by it. I think there are advantages to that.

Post reply on HN