firecracker-containerd VS lxd

My team is working on multi-cloud AWS Bottlerocket remix (Azure, GCP) with opt-in support for [firecracker-containerd](https://github.com/firecracker-microvm/firecracker-containerd) for our in-house CNCF distro, investigating microkernels applicability (tldr; they are not production-ready). We test kubernetes compat and migration plans for over 40+ cherry-picked solutions, and facing numerous compat issues for every k8s update. We do have support for Container Managed Control Planes described above, as well.

You could use a container sandbox like gVisor, light virtual machines as containers (Kata containers, firecracker + containerd) or full virtual machines (virtlet as a CRI).

There is this project, which I have never used, but seems promising. https://github.com/firecracker-microvm/firecracker-container...

Exactly, it is about secure multi-tennancy. If I recall correctly firecracker doesn't replace containerd, microVMs still runs some sort of it. Anyway, you still need a base OS because container doesn't have the whole OS image. Also I think you can have multiple containers in a single Fargate task so they have to be isolated too.

How does that compare to firecracker-containerd?

https://github.com/firecracker-microvm/firecracker-container...

This repository enables the use of a container runtime, containerd, to manage Firecracker microVMs. Like traditional containers, Firecracker microVMs offer fast start-up and shut-down and minimal overhead. Unlike traditional containers, however, they can provide an additional layer of isolation via the KVM hypervisor.

https://github.com/firecracker-microvm/firecracker-container...

Running NixOS on a virtual machine (VM) is a safe and reproducible way to test such configurations. As for VMs, I have used VirtualBox, Vagrant and lxd in the past. However, I have found QEMU to be the simplest and most flexible solution for my needs.

Please correct me if I'm wrong, but the post also links the "add Canonical CLA check #12665" [0], and my understanding is that "retain copyright" here is like a typical forum agreement where you going forward must agree to a perpetual worldwide unlimited license to Canonical that they can use as they please per [1]:

>In effect, you’re giving us a licence, but you still own the copyright — so you retain the right to modify your code and use it in other projects.

You explicitly do retain ownership, so you can then take that same code and contribute it elsewhere under any license you wish. The same author could contribute the same patch to both the LXD and the Incus fork. But some might object to being required to allow Canonical to specially license as they want.

So your characterization seems unfair, and then gets kind of nasty at the end:

>The author is pissed off because he can't build custom versions without redistributing the modifications

Incus is a full fork, and Canonical has apparently been taking changes back from it as well as is often the case with such forks where both sides get value from each other. It's perfectly understandable for some folks to be bummed if that's no longer the case, and there is nothing evil about the Apache2 license. There's plenty of history that in OSS going back to the beginning, no need for insinuations or attacks.

----

0: https://github.com/canonical/lxd/pull/12665/commits/eb5c773d...

1: https://ubuntu.com/legal/contributors

You could consider LXD which lets you easily run both containers and VMs: https://ubuntu.com/lxd

I hope this doesn't affect LXC negatively.

LXC and LXD share plenty of contributors.

https://github.com/lxc/lxc/graphs/contributors

https://github.com/canonical/lxd/graphs/contributors

I use an "unprivileged LXC container" setup on several Debian bullseye hosts. It works fantastic, and each LXC container feels like a real server.

Compare that to Docker's "one-container-one-process" philosophy, reinventing the wheel by awkwardly composing multiple containers.

[1] https://linuxcontainers.org/lxd/

The expected changes are: - https://github.com/lxc/lxd will now become https://github.com/canonical/lxd - https://linuxcontainers.org/lxd will disappear and be replaced with a mention directing users to https://ubuntu.com/lxd - The LXD YouTube channel will be handed over to the Canonical team - The LXD section on the LinuxContainers community forum will slowly be sunset in favor of the Ubuntu Discourse forum run by Canonical - The LXD CI infrastructure will be moved under Canonical’s care - Image building for Linux Containers will no longer be relying on systems provided by Canonical, limiting image building to x86_64 and aarch64.