每日一问系列
为什么 kubelet 不使用容器化部署？
这里的主要原因是 kubelet 除了需要调用容器运行时，还需要直接操作宿主机以配置目标业务容器的网络、数据卷等
假设 kubelet 在容器中运行
容器运行时如 docker 可以通过挂载 docker sock 实现
网络问题可以通过共享宿主机 net namespace 实现，如 docker 的 --net host
对于目标业务容器的卷挂载问题就会比较麻烦，kubelet 隔着容器的 Mount Namespace 和文件系统不能直接操作宿主机的文件系统
比如，如果用户想要使用 NFS 做容器的持久化数据卷，那么 kubelet 就需要在容器进行绑定挂载前，在宿主机的指定目录上，先挂载 NFS 的远程目录
可是，这时候问题来了。由于现在 kubelet 是运行在容器里的，mount namespace 是直接开启的，这就意味着它要做的这个“mount -t nfs”命令，被隔离在了一个单独的 mount namespace 中，即 kubelet 做的挂载操作，不能被“传播”到宿主机上
正常情况容器数据卷的挂载流程
准备容器的 rootfs：kubelet 通过容器运行时下载镜像并通过指定的 storage driver 在宿主机上联合挂载出 rootfs，如 overlay2 的 MergedDir /var/lib/docker/overlay2/{id}/merged
创建 init 进程：kubelet 通过容器运行时创建出一个 init 进程，如 dockerinit 并为 init 进程开启 cgroup 和 namespace，此时 mount namespace 开启了，但是默认继承了宿主句的 mount namespace 视图，所以 init 进程可以看到上述宿主机准备的 rootfs 和在宿主机上要被挂载到容器的目录
执行 bind 挂载操作：bind 挂载即绑定挂载，可以将一个目录或者文件挂载到另一个目录。由于此时的 init 进程可以看到宿主机文件系统，所以 bind 挂载的 src 就是宿主机目录 /home，dst 就是 /var/lib/docker/overlay2/[可读写层 ID]/test
挂载 rootfs：在容器的 mount namespace 视图下，执行 chroot 或者 pivot_root，这样 init 进程看到的 rootfs 就切换成了前面准备好的 rootfs
启动业务进程：init 进程使用 execv 系统调用将用户定义的 ENTRYPOOINT+CMD 取代自己为 1 号进程
值得注意的是：执行 bind 挂载动作在容器 mount namespace 视图下执行，因此宿主机看不到挂载信息，保证容器的隔离性不会被 Volume 打破