4 ms·

This is the approach used by Kata Containers/Firecracker. It's not much heavier than the shared kernel approach, but has significantly better security. An bug i

by haiku2077 1y ago

This is the approach used by Kata Containers/Firecracker. It's not much heavier than the shared kernel approach, but has significantly better security. An bug in the container runtime doesn't immediately break the separation between containers. The performance overhead of the VM is minimal, the main tradeoffs is container startup time.

surajrmal 1y ago
Ram overhead can be nontrivial. Each kernel has its own page cache.
- haiku2077 1y ago
  On a non Linux OS that should be offset by being able to allocate RAM separately to each container instead of the current approach in Docker Desktop where a static slice of your system memory is always allocated to the Docker VM.
- fpoling 1y ago
  This a feature targeting developers or perhaps apps running on end-user machine where page cache sharing between applications or container does not typically get much of RAM saving. Linux kernel overhead itself while non-trivial is still very manageable in those settings. AWS Nitro stripped down VM kernel is about 40 MB, I suppose for Apple solution it will be similar.
Yeroc 1y ago
I wonder why Apple cared so much about the security aspect to take the isolated VM approach versus shared VM approach. Seems unlikely that Apple hardware is going to be used to host containerized applications in production where this would be more of a concern. On the other hand, it's more likely to be used for development purposes where the memory overhead could be a bigger concern.
- haiku2077 1y ago
  One of the use cases for this feature is for macOS desktop apps to run Linux sidecars, so this needed to be secure for end user devices.
- ghostly_s 1y ago
  > Seems unlikely that Apple hardware is going to be used to host containerized applications in production I imagine this is certainly happening already inside Apple datacenters.
deleted 1y ago
[deleted]

surajrmal 1y ago

Ram overhead can be nontrivial. Each kernel has its own page cache.

haiku2077 1y ago
On a non Linux OS that should be offset by being able to allocate RAM separately to each container instead of the current approach in Docker Desktop where a static slice of your system memory is always allocated to the Docker VM.
fpoling 1y ago
This a feature targeting developers or perhaps apps running on end-user machine where page cache sharing between applications or container does not typically get much of RAM saving. Linux kernel overhead itself while non-trivial is still very manageable in those settings. AWS Nitro stripped down VM kernel is about 40 MB, I suppose for Apple solution it will be similar.

Yeroc 1y ago

I wonder why Apple cared so much about the security aspect to take the isolated VM approach versus shared VM approach. Seems unlikely that Apple hardware is going to be used to host containerized applications in production where this would be more of a concern. On the other hand, it's more likely to be used for development purposes where the memory overhead could be a bigger concern.

haiku2077 1y ago
One of the use cases for this feature is for macOS desktop apps to run Linux sidecars, so this needed to be secure for end user devices.
ghostly_s 1y ago
> Seems unlikely that Apple hardware is going to be used to host containerized applications in production I imagine this is certainly happening already inside Apple datacenters.

deleted 1y ago

[deleted]