nvidia-container-runtime
kata-containers
nvidia-container-runtime | kata-containers | |
---|---|---|
3 | 14 | |
1,089 | 5,791 | |
- | 1.8% | |
0.0 | 9.9 | |
over 1 year ago | 2 days ago | |
Makefile | 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.
nvidia-container-runtime
-
Comparing 3 Docker container runtimes - Runc, gVisor and Kata Containers
Now you can even choose a runtime which creates a virtual machine or a container with a more secure isolation. Once there was a runtime for using an NVIDIA GPU called nvidia-container-runtime. That project is now deprecated and Docker has the "--gpus" option instead. Talking about GPUs is not the scope of this blogpost, but it is a good example of a special runtime that gave additional capabilities to containers.
-
Can you add CUDA to a docker container?
Yes, you can, actually already exist images with Cuda installed https://hub.docker.com/r/nvidia/cuda . To be able to use the GPU device within the docker container you need to install `nvidia-container-runtime` https://github.com/NVIDIA/nvidia-container-runtime.
- "Unknown runtime specified nvidia" trying to configure Plex Docker container with GPU passthrough
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?
container-images
kubevirt - Kubernetes Virtualization API and runtime in order to define and manage virtual machines.
nvidia-docker - Build and run Docker containers leveraging NVIDIA GPUs
lxd - Powerful system container and virtual machine manager
gvisor - Application Kernel for Containers
sysbox - An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.
firecracker-containerd - firecracker-containerd enables containerd to manage containers as Firecracker microVMs
ignite - Ignite a Firecracker microVM
cloud-hypervisor - A Virtual Machine Monitor for modern Cloud workloads. Features include CPU, memory and device hotplug, support for running Windows and Linux guests, device offload with vhost-user and a minimal compact footprint. Written in Rust with a strong focus on security.
firecracker-container
Virtualization-Emulation-Guide - Virtualization/Emulation Guide
lxd - Powerful system container and virtual machine manager [Moved to: https://github.com/canonical/lxd]