[GSoC] Give more technical inside about containerd plugin for kata-container runtime about frakti HOT 6 CLOSED

It should related to @laijs 's area. Let's PING him

from frakti.

Disclaimer : Not an expert at this. I am also a potential intern for Gsoc. Just giving my 2 cents.

Kata Containers is an opensource project which aims to merge the Intel Clear Containers runtime and the Hyper runv runtimes. Kata already has support for Docker. It aims to be a substitute for runc.

As @urvil38 said normally the container state diagram is docked -> containerd -> runc.

When used with kubernetes, the state transition diagram is kubernetes -> cri-containerd ->containerd -> kata. This blog post may be of help if you want to understand how kubernetes works with containerd. I believe the rest would be clear to you then.

As far as the benefits are concerned, when you run a container with Kata as a runtime, a new QEMU based virtual machine is spawned, this gives you much better hardware based isolation than the traditional software (OS) based isolation. There is no sharing of the host kernel when you run with kata as the guest is now insde a VM. A kata runtime based container uses its own minimalistic linux kernel.

For more details you may like to visit the Kata Containers, Clear containers or runv repos.

from frakti.

This doc presented in an earlier architecture committee meeting may be helpful if you wish to learn more about the architecture of the kata runtime

from frakti.

@urvil38 dockerd -> containerd -> kata-runtime is already a ready solution that kata-containers community has been working long with as the same GSoC doc says. This solution is excellent except that the data path is too long: dockerd -> containerd -> containerd-shim -> kata-shim -> [vm: agent -> container]. In this paradigm, containerd-shim is very specified for containerd+runc which hold something including Stdio and reaper ownership that keeps the container running when containerd is dead. In kata-cantainers case, the hypervisor along with the agent can do the same thing and we can shorten the data path. kata-shim is also specified for dockerd/containerd and acts as a presentation in the host with a referencable system pid.

Both containerd-shim and kata-shim are unnecessary in containerd's runtime plugin with kata-containers. So a new containerd-kata plugin will be introduced for it, which is also the aim of this Gsoc project. After it is done, the data/control path will be:
dockerd/kublet -> containerd with containerd-kata runtime plugin -> [vm: agent -> container]
and remove the unnecessary interlayer.

from frakti.

thanks, @ydjainopensource and @laijs.
Any data are available for how much time it will take to create vm sandbox and container inside it with kata-container runtime?I am curious about how much time hypervisor-based container take to start and stop than normal OS based container.

@laijs can you give some inside about what is a current state of frakti and containerd-kata runtime plugin?

from frakti.

less than 100ms when work with proper VM factory.

from frakti.