3 ms·

1. I expect people to move towards a VM per pod model, even in private setups. Firecracker claims a memory overhead of 5 MB, and a minimal QEMU setup shouldn't

1. I expect people to move towards a VM per pod model, even in private setups. Firecracker claims a memory overhead of 5 MB, and a minimal QEMU setup shouldn't be too bad either. 2. It sounds like this paper is mainly about covert channels not side channels. Covert channels assume cooperation between both sides, so they're only relevant if one of the sides can't communicate trivially (e.g. via network)

jamiesonbecker 6y ago
> vm per pod .. firecracker agreed. AWS gets a lot of flak, but open sourcing firecracker was really great. I'd really prefer to see us move toward vms instead of containers, even if we kept the same k8s abstractions. > .. covert .. thanks for the catch, should have taken more time. Here's a better paper: https://hal.inria.fr/hal-01591808/document https://hal.inria.fr/hal-01591808/document
- CodesInChaos 6y ago
  > I'd really prefer to see us move toward vms instead of containers, even if we kept the same k8s abstractions 1. For me containers are one of those abstractions, defined by exposing an application controlled userspace. Containers can be implemented by different isolation technologies, from simple chroot/cgroup/namespaces... to VMs. 2. I'd still use chroot&co to partially isolate containers within a pod, while using VMs to strongly isolate pods from each other. This enables features like shared block-devices, unix-domain-sockets and monitoring the processes in an application container from a separate diagnostics container.