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

(资料图)

这里的主要原因是 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 打破