libkrun
kata-containers
libkrun | kata-containers | |
---|---|---|
8 | 14 | |
924 | 5,614 | |
5.7% | 1.9% | |
9.0 | 10.0 | |
5 days ago | 6 days ago | |
Rust | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
libkrun
-
Hyperlight: Virtual machine-based security for functions at scale
libkrun (on Linux) is probably a closer comparison (though still not quite the same). https://github.com/containers/libkrun
- My VM is lighter (and safer) than your container
-
Krunvm – Create MicroVMs from OCI Images
These specific microVMs are managed by: https://github.com/containers/libkrun#goals-and-non-goals (linked directly to project scopes).
In summary though (others redacted):
# Goals
- Execute Docker Containers as QEMU MicroVMs
-
Show HN: krunvm – Create and run lightweight VMs from OCI images
The key is that libkrun (https://github.com/containers/libkrun), the library that krunvm uses for running the VMs, as recently integrated support for Hypervisor.framework on ARM64, in addition to KVM.
As for buildah, the Homebrew repo contains a build that includes this PR (https://github.com/containers/storage/pull/811).
kata-containers
-
Comparing 3 Docker container runtimes - Runc, gVisor and Kata Containers
I bet the first thing you think that it is a bug. There is an issue on GitHub where someone thought the same. The fact is that Kata containers are different and there are Limitations. The first I noticed too, that there is no way to share process or network namespaces between Docker containers. The fact that you cannot use the process namespace or network namespace of the host is easily understandable because we have a VM and not just a host kernel isolating our processes.
-
Unfashionably secure: why we use isolated VMs
> I actually wonder how much "overhead" a VM actually has. i.e. a linux kernel that doesn't do anything (say perhaps just boots to an init that mounts proc and every n seconds read in/prints out /proc/meminfo) how much memory would the kernel actually be using?
There's already some memory sharing available using DAX in Kata Containers at least: https://github.com/kata-containers/kata-containers/blob/main...
- My VM is lighter (and safer) than your container
- Maestro: A Linux-compatible kernel in Rust
-
Fly Kubernetes
Seems like Fly.io Machines are trying reimplement Kata Containers with the Firecracker backend [0].
Kata has a guest image and guest agent to run multiple isolated containers [1].
[0] https://katacontainers.io/
[1] https://github.com/kata-containers/kata-containers/blob/main...
-
Kata Containers: Virtual Machines (VMs) that feel and perform like containers
> Last time I looked (a few months ago), the documentation was pretty sparse or outdated.
It still is, though it works somewhat seamlessly when installing with https://github.com/kata-containers/kata-containers/blob/main...
Though only one of the hypervisors works well.
-
Method to block possible internet traffic from LLaMA on MacOS
Better to use a secure VM, can even get container-like VMs with kata-containers
-
Kata Containers vs gVisor?
As I understand,Kata Containers
-
Firecracker MicroVMs
Kubernetes using Kata containers as a containerd backend
https://github.com/kata-containers/kata-containers/blob/main...
-
Container security best practices: Ultimate guide
My home k8s cluster is now "locked down" using micro-vms (kata-containers[0]), pod level firewalling (cilium[1]), permission-limited container users, and mostly immutable environments. Given how quickly I rolled this out; the tools to enhance cluster environment security seem more accessible now than my previous research a few years ago.
I know it's not exactly a production setup, but I really do feel that it's the most secure runtime environment I've ever had accessible at home. Probably more so than my desktops, which you could argue undermines most of my effort, but I like to think I'm pretty careful.
In the beginning I was very skeptical, but being able to just build a docker/OCI image and then manage its relationships with other services with "one pane of glass" that I can commit to git is so much simpler to me than my previous workflows. My previous setup involved messing with a bunch of tools like packer, cloud-init, terraform, ansible, libvirt, whatever firewall frontend was on the OS, and occasionally sshing in for anything not covered.
[0] https://github.com/kata-containers/kata-containers
What are some alternatives?
firecracker - Secure and fast microVMs for serverless computing.
kubevirt - Kubernetes Virtualization API and runtime in order to define and manage virtual machines.
libkrunfw - A dynamic library bundling the guest payload consumed by libkrun
firecracker-containerd - firecracker-containerd enables containerd to manage containers as Firecracker microVMs
harvester - Open source hyperconverged infrastructure (HCI) software
lxd - Powerful system container and virtual machine manager [Moved to: https://github.com/canonical/lxd]
slim - Build and run tiny vms from Dockerfiles. Small and sleek.
sysbox - An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.
krunvm - Create microVMs from OCI images
gvisor - Application Kernel for Containers
kwarantine - Kwarantine can run strongly isolated containers in a multi-tenant setting
ignite - Ignite a Firecracker microVM