个人中心
gpt4 book ai didi

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

转载 作者：我是一只小鸟 更新时间：2023-07-12 14:31:13 31 4
gpt4 key购买 nike

每日一问系列

为什么 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 打破 。

最后此篇关于为什么kubelet不使用容器化部署？的文章就讲到这里了,如果你想了解更多关于为什么kubelet不使用容器化部署？的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。

31 4 0
文章推荐： 封装图片处理工具类，实现图片的裁剪、压缩、图片水印、文字水印、多行文字水印等功能
文章推荐： 基于JavaFX的扫雷游戏实现（五）——设置和自定义控件
文章推荐： 高通个别驱动创建Buffer耗时高问题的解决
文章推荐： 掌握这些写简历投简历的“黑魔法”，告别简历已读不回！
我是一只小鸟
个人简介

我是一名优秀的程序员,十分优秀！

滴滴打车优惠券免费领取
滴滴打车优惠券
全站热门文章
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com