Kata Containers
Kata Containers#
- Virtual machines - bigger, slower with more isolation. Boot time of minutes
- Containers - quick, simple but less isolation
Kata Containers blends the two: security and isolation of virtual machines without the usual VM bloat.
It is a vm
How do you use Kata Containers?#
It looks like runc an OCI compatible runtime
runC is the universal container runtime
History#
Before kata there was Intel Clear Containers
Traditional containers#
You have a host and a kernel. Your containers run within namespaces on that host. All good until somebody breaks out of a container - which you have access to all containers.
Traditional containers in a VM#
A Vm within a VM with containers in it
Kata has lightweight virtual machines
Kata Containers#
- Every container or pod gets its own virtual machine
- Container does not know it is a VM, so the deployment process is the same
Architecture and integrations#
Components:
- QEMU - KVM
- Runtime (Kata Runtime)
- Kernel - sits inside the VM
- rootfs image - VM has to boot something, and rootfs sets up the container
- Agent - work to happen: mount points, networks, memory resources and cgroups
- Shim
- Proxy
CRI-O and Kata#
Kubelet -> CRI (Container Runtime Interface) -> CRI-o/ContainerD -> runc -> kata-runtime -> vm
Can choose which you want - if you don’t trust it run it in a kata container
Fairly seamless.
Networking and Storage#
Containers run at layer 3 but vm’s run at layer 2
Storage:
- 9pfs (overlay) - easy to use network based file system with plan9 (just works) - default. Not a full POSIX unix filesystem
- Block devices (device mapper) - vm can find block device , map and mount to virtual machine (not going over network connection)
- Network (ceph, gluster) - Network storage works as you expect
Overhead#
- 50MB per container
- Boot in less than a second
Road Map#
Primarily around security and isolation
Security, in container: seccomp
Security, on host: cgroup isolation, more namespace isolation, root-less QEMU and SELinux policy