为什么 kubelet 不使用容器化部署？

每日一问系列

为什么 kubelet 不使用容器化部署？

通过脚本（shell/ansible 等）在节点上部署 kubelet 服务时，涉及 kubelet 进程 service 启动配置、证书等，为什么不使用容器化部署 kubelet 呢？直接 docker run ... 一键部署多简单？

这里的主要原因是 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 做的挂载操作，不能被“传播”到宿主机上

正常情况容器数据卷的挂载流程

kubelet 直接运行在宿主机时容器数据卷的挂载流程是怎么样的呢？例如将宿主机的 /home 目录挂载到容器的 /test 目录

准备容器的 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 打破