Cntr: Lightweight OS Containers

[gaocegege]

https://www.usenix.org/conference/atc18/presentation/thalheim

ATC'18

https://github.com/Mic92/cntr

[gaocegege]

这篇文章主要想解决的问题与 #290 类似，这两篇文章是相同的一作。目前 Docker 落地非常广泛，但是在调试的时候我们通常需要很多工具，这些工具在正常运行的时候不需要，但是调试的时候就需要安装。如果 attach 进去然后再装会非常麻烦。

这个问题如果在 K8s 里可以用最新的特性 https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container 来做

文章的实现不一样，但是想解决的问题是一样的。K8s 只是把新启动的容器和待 debug 的容器启动在了相同的 namespace 下，相互可以看到，但是 CNTR 不太一样。

CNTR 是把两个容器通过 FUSE 和 nested namespace 把他们的文件系统挂在了一起

The key idea behind our approach is to create a new nested namespace inside the application container (i.e., “slim container”), which provides access to the resources in the “fat” container, or the host, through a FUSE filesystem interface. CNTR uses the FUSE system to combine the filesystems of two images without any modification to the application, the container implementation, or the operating system. CNTR selectively redirects the filesystem requests between the mount namespace of the container (i.e., what applications within the container observe and access) and the “fat” container image or the host, based on the filesystem request path. Importantly, CNTR supports the full Linux filesystem API and all container implementations (i.e., Docker, rkt, LXC, systemd-nspawn)

[gaocegege]

[gaocegege]

可以理解为 CNTR 实现 on-the-fly 地 mount 一个文件系统到容器里的能力

[gaocegege]

CNTR server 通过内核的 FUSE Driver 来跟一个 mount namespace 里的进程交互的， CNTR 相当于是代理，把来自 Slim container 的访问请求代理到另外一个 mount namespace 的 FS 上去。

相当于做了一个代理，联通了两个 mount namespace 下的 FS