07 | 白话容器基础(三):深入理解容器镜像
张磊

该思维导图由 AI 生成,仅供参考
你好,我是张磊。我在今天这篇文章的最后,放置了一张 Kubernetes 的技能图谱,希望对你有帮助。
在前两次的分享中,我讲解了 Linux 容器最基础的两种技术:Namespace 和 Cgroups。希望此时,你已经彻底理解了“容器的本质是一种特殊的进程”这个最重要的概念。
而正如我前面所说的,Namespace 的作用是“隔离”,它让应用进程只能看到该 Namespace 内的“世界”;而 Cgroups 的作用是“限制”,它给这个“世界”围上了一圈看不见的墙。这么一折腾,进程就真的被“装”在了一个与世隔绝的房间里,而这些房间就是 PaaS 项目赖以生存的应用“沙盒”。
可是,还有一个问题不知道你有没有仔细思考过:这个房间四周虽然有了墙,但是如果容器进程低头一看地面,又是怎样一副景象呢?
换句话说,容器里的进程看到的文件系统又是什么样子的呢?
可能你立刻就能想到,这一定是一个关于 Mount Namespace 的问题:容器里的应用进程,理应看到一份完全独立的文件系统。这样,它就可以在自己的容器目录(比如 /tmp)下进行操作,而完全不会受宿主机以及其他容器的影响。
那么,真实情况是这样吗?
公开
同步至部落
取消
完成
0/2000
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结

本文深入探讨了Linux容器文件系统的实现方式,重点关注了Mount Namespace对容器进程文件系统视图的影响。通过详细的代码示例和解释,阐述了即使开启了Mount Namespace,容器进程看到的文件系统仍然与宿主机相同的问题,并提出了重新挂载目录的解决办法。作者强调了重新挂载操作只在容器进程的Mount Namespace中有效,并对读者进行了实际操作演示和结果验证。文章还介绍了rootfs的概念,以及容器镜像的重要性和一致性。此外,还探讨了Docker镜像中引入的层概念和联合文件系统的应用。通过实际案例和技术原理,本文深入浅出地介绍了Linux容器文件系统的实现方式,对于想深入了解该领域的读者具有很高的参考价值。文章还提出了思考题,引发读者对容器技术的进一步思考和探索。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》,新⼈⾸单¥68
《深入剖析 Kubernetes》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(176)
- 最新
- 精选
- 张磊 Kubernetes置顶有读者反映,咱们重新挂载/tmp目录的实验执行完成后,在宿主机上居然可以看到这个挂载信息。。这是怎么回事呢?实际上,大家自己装的虚拟机,或者云上的虚拟机的根目录,很多都是以share方式的挂载的。这时候,你在容器里做mount也会继承share方式。这样就会把容器内挂载传播到宿主机上。解决这个问题,你可以在重新挂载/tmp之前,在容器内先执行一句:mount(“”, “/“, NULL, MS_PRIVATE, “”) 这样,容器内的根目录就是private挂载的了。2018-09-084235
- Linux云计算网络1. 上面的读写层通常也称为容器层,下面的只读层称为镜像层,所有的增删查改操作都只会作用在容器层,相同的文件上层会覆盖掉下层。知道这一点,就不难理解镜像文件的修改,比如修改一个文件的时候,首先会从上到下查找有没有这个文件,找到,就复制到容器层中,修改,修改的结果就会作用到下层的文件,这种方式也被称为copy-on-write。 2. 查了一下,包括但不限于以下这几种:aufs, device mapper, btrfs, overlayfs, vfs, zfs。aufs是ubuntu 常用的,device mapper 是 centos,btrfs 是 SUSE,overlayfs ubuntu 和 centos 都会使用,现在最新的 docker 版本中默认两个系统都是使用的 overlayfs,vfs 和 zfs 常用在 solaris 系统。 欢迎补充和指正。
作者回复: 课代表又出现啦
2018-09-077543 - Jeff.W继Namespace构建了四周的围墙(进程隔离),Cgroups构建了受控的天空优先使用阳光雨露(资源限制),Mount namespace与rootfs构建了脚下的大地,这片土地是你熟悉和喜欢的,不管你走到哪里,都可以带着它,就好像你从未离开过家乡,没有丝毫的陌生感(容器的一致性)~
作者回复: 于是,你就做了一句诗
2018-09-1315371 - asdf100目录联合挂载时,如果A和B目录里的x文件内容不一样,这时如何处理?
作者回复: 好问题。aufs是一层一层往上盖的,所以我给的例子里,A里面的x会覆盖B里面的x。
2018-09-0710121 - oddrock请问老师,听了您今天的课,认识到容器使用的内核是和宿主机内核一致的,但如果容器需要不同的内核怎么办?
作者回复: 没!办!法!所以我去年一直在搞katacontainers,这种基于虚拟化的容器是有独立内核的。
2018-09-075106 - 汤尼房老师你好,很好奇dockerhub上关于系统镜像的制作过程,比如对于centos7.4的镜像,首先能想到的是应该依据centos官方发布的centos7.4的系统镜像,然后将此镜像中的内核给去掉,仅保留剩下的文件、配置和目录或者是保留必要的文件、配置和目录;但通过查看centos7.4的Dockerfile之后发现其依赖的base image是scratch,然后在scratch的基础上添加centos-7.4.1708-docker.tar.xz,后来查看ubuntu镜像发现其base image也是scratch,老师能简单说下scratch基础镜像吗(镜像文件的制作过程等),猜想scratch应该是包含了多个系统之间共同的东西,否则为啥多个版本的系统镜像以及不同版本的系统镜像的基础镜像都用的是scratch,所以对scratch基础镜像很好奇,望老师指点一下
作者回复: 很简单啊,因为scratch本身就是个空镜像。你想想,假如你是centos公司,你在发布centos镜像的时候总得FROM吧?所以docker公司就给你做了个scratch:万能的base镜像。
2018-09-10892 - ╯梦深处゛喜欢这种从出现到发展、由浅入深、由一小段代码讲述某种实现的讲述,既容易理解,也深入了解了原理。娓娓道来,很有条理,就像身临当时docker的实现场景!
作者回复: 我一向反对源码分析。那是偷懒的态度。
2018-09-27280 - vx:jiancheng_goon女朋友1 3 5追电视剧,我1 3 5追k8s。
作者回复: 女朋友应该很开心😃
2018-09-07657 - Vinsecdocker run -ti ubuntu /bin/bash 此时会有一个隐式的chroot过程 请问这个chroot的过程是将/bin/bash进程的Home目录切换成了/var/lib/docker/aufs/mnt/[id]了么?
作者回复: 是
2018-10-281241 - 吕请教一个低级的问题,我现在用docker部署,在多次部署以后,会导致磁盘占用空间急剧的增大,老是需要扩容,虽然对不使用的镜像定时做了删除,但还是会出现这样的问题,产生的文件也不敢在生产环境随便进行删除,只能清理镜像和容器。
作者回复: 用kubernetes ,打开GC功能,定时清理
2018-09-07535
收起评论