深入剖析 Kubernetes
张磊
Kubernetes 社区资深成员与项目维护者
116705 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 57 讲
再谈开源与社区 (1讲)
结束语 (1讲)
深入剖析 Kubernetes
15
15
1.0x
00:00/00:00
登录|注册

13 | 为什么我们需要Pod?

启动一个sidecar容器,不断地从Volume中读取日志文件,转发到存储中
使用共享的Volume
Tomcat容器启动,共享Volume中存在WAR包
WAR包容器先启动,拷贝WAR包到共享Volume
使用Init Container类型的容器
通过Join Network Namespace与Infra容器关联
容器A共享容器B的网络和Volume
Hold住Network Namespace
使用特殊的镜像:k8s.gcr.io/pause
永远是第一个被创建的容器
共享其他Namespace的应用场景
除了Network Namespace外,还可以共享其他Namespace
例子:容器的日志收集
例子:WAR包与Web服务器
在一个Pod中启动一个辅助容器,完成独立于主进程之外的工作
共享Volume
Infra容器
具体应用场景
Pod里的容器可以共享的Namespace
sidecar模式
Pod的实现原理
可声明共享同一个Volume
共享Network Namespace
一组共享了某些资源的容器
逻辑概念,不是实际的隔离环境
原子调度单位
Kubernetes项目中最小的API对象
思考题
容器设计模式
Pod
我们为什么需要Pod?

该思维导图由 AI 生成,仅供参考

你好,我是张磊。今天我和你分享的主题是:为什么我们需要 Pod。
在前面的文章中,我详细介绍了在 Kubernetes 里部署一个应用的过程。在这些讲解中,我提到了这样一个知识点:Pod,是 Kubernetes 项目中最小的 API 对象。如果换一个更专业的说法,我们可以这样描述:Pod,是 Kubernetes 项目的原子调度单位。
不过,我相信你在学习和使用 Kubernetes 项目的过程中,已经不止一次地想要问这样一个问题:为什么我们会需要 Pod?
是啊,我们在前面已经花了很多精力去解读 Linux 容器的原理、分析了 Docker 容器的本质,终于,“Namespace 做隔离,Cgroups 做限制,rootfs 做文件系统”这样的“三句箴言”可以朗朗上口了,为什么 Kubernetes 项目又突然搞出一个 Pod 来呢?
要回答这个问题,我们还是要一起回忆一下我曾经反复强调的一个问题:容器的本质到底是什么?
你现在应该可以不假思索地回答出来:容器的本质是进程。
没错。容器,就是未来云计算系统中的进程;容器镜像就是这个系统里的“.exe”安装包。那么 Kubernetes 呢?
你应该也能立刻回答上来:Kubernetes 就是操作系统!
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了Kubernetes中Pod的实现原理及其重要性。文章首先强调了容器本质是进程,Kubernetes则是操作系统,并解释了为何需要Pod以及其作为原子调度单位的重要性。通过分析Linux系统中的进程组,阐述了Kubernetes将“进程组”概念映射到容器技术的原因。此外,文章还讨论了容器间的紧密协作关系,以及Pod作为Kubernetes中的原子调度单位的重要性。文章详细介绍了Pod的实现原理,包括Infra容器、共享Volume等概念,并探讨了容器设计模式中的sidecar模式及在日志收集方面的应用。总体而言,本文深入浅出地解释了Pod的重要性和技术特点,对于想要深入了解Kubernetes中的Pod概念和实现原理的读者来说,是一篇值得阅读的文章。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入剖析 Kubernetes》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(201)

  • 最新
  • 精选
  • 段帅民
    这文章读起来像吃脆苹果,爽,这是我订阅专栏中写的最好的,没有之一

    作者回复: 这是我见过最形象的评论……

    2018-09-21
    14
    411
  • 北卡
    看得太爽了。请教一个问题: war和tamcat这种情况。 如果把war独立出来做一个镜像的话,应该用什么做基础镜像呢? 我现在做镜像的时候通常都是用debian做基础镜像,但如果只是为了复制这个.war包的话,用debian感觉蛮浪费的。应该怎样做到最小呢,而且要支持cp命令。

    作者回复: 市面上的小镜像多的很啊,busybox,alpine

    2018-09-24
    13
    59
  • songyy
    为什么说“Docker in Docker”这种方式在生产环境后患无穷呀?

    作者回复: 因为是坑的二次方

    2018-10-16
    3
    41
  • kindnull
    从事Linux运维工作多年,有一点一直有点不明白,这里到底谁挂载到谁上面: volumeMounts: -mountpath: /app name: app-volume 文中有有这句话说"而后这个 /app 目录,就挂载了一个名叫 app-volume的Volume" 这里是说将app-volume挂载到/app上,但是app是个目录,那我想问的是app-volume是个目录还是设备? 同样下面: volumeMounts: -mountpath:/root/apache-tomcat-7.0.42-v2/webapps name:app-volume ---Tomecat容器同样声明了挂载app-volume到自己的webapps目录下 这里又说把app-volume挂载到webapps下,webapps明显是个目录,那app-volume是个目录吗? 但是我清楚记得在Linux下。如果要挂载一个分区设备到一个目录或者一个目录到另外一个主机目录下应该是: mount -t xxfs src_dir dest_dir 比如: mount -t xfs /dev/sda /opt/app mount -t nfs /share/data 192.168.0.100:/data 上面的挂载的app-volume到底是设备还是文件,或者是去的一个别名?

    作者回复: volume的挂载是bind mount,不是设备,它的功能就是把文件或目录绑定挂载在一起,所以你这里的纠结谁在谁上面是没有意义的……唯一需要明确的是,bind mount的挂载点,是容器volume在宿主机上的目录。这一块在容器基础部分有详细的解释。

    2018-09-22
    6
    31
  • fldhmily63319
    重问: 关于升级war和tomcat那块,也是先修改yml?然后kubenertes执行升级命令,pod会重新启动,生产也是按照这种方式吗? 所以这种情况下面,如果只是升级个war包,或者加一个新的war包,tomcat也要重新启动?这就不是完全松耦合了?

    作者回复: kubernetes的更新是patch方式的,可以关注后续声明式api的内容。

    2018-09-21
    2
    17
  • 骨汤鸡蛋面
    张老师,我们公司一直有一个问题: 我们用docker 管理测试环境,对于springboot 项目,一向是java -jar xx.jar 的方式启动,但因为是测试环境,经常代码本身有问题导致java(也就是容器主进程)启动不起来,进而触发健康检查重新调度该服务,然后开发总是抱怨看不到事故现场。我打算自己实现一个程序(我们称为nile),容器启动时先启动nile确保容器可以启动起来,再由nile启动java进程。这时还可以让nile 读取用户配置 自定义设置jvm 参数、nile向zk汇报一些应用情况等。这个做法呢,nile可以算是java 的sidecar,按您文章的说法,nile和java 是拓扑关系而不是对等关系,这个时候我一个pod里分别是nile和java容器是否可能呢?

    作者回复: 如果nile不负责管理java进程的话当然可以。否则的话就是同一个容器。

    2018-11-04
    2
    16
  • 姜子牙
    容器的“单进程模型”,并不是指容器里只能运行“... 这一段里说容器的单进程模型。我在跑一个web后端服务,springboot实现。 entrypoint 是java -jar xxxx.jar .这条命令产生的进程就是PID=1的吗? 容器只能管理PID=1的。我理解的就是这个进程执行不成功,容器户退出。但是如果我的springboot程序有问题,没跑成功,容器依然跑着呢,为啥?

    作者回复: 因为有JVM

    2019-02-22
    14
  • 巩夫建
    非常棒,释义了pod的理念。有个小问题,像我之前一个docker中跑tomcat和nginx两个进程,共用同一个文件,如果拆成三部分,第一init container 文件镜像,第二 tomcat镜像,第三 nginx镜像,如何保证init container 启动后启动tomcat,最后启动nginx,还有这种优点有什么?目前只想到镜像高复用,谢谢作者。

    作者回复: nginx容器启动前做检查即可。主要好处就是解偶。

    2018-09-21
    8
    14
  • Pixar
    war包的例子并没有解决频发打包的问题吧? wa包变动后, geektime/sample:v2包仍然需要重新打吧. 这和东西一股脑装在tomcat中后, 重新打tomcat 并没有差太多吧?

    作者回复: 你忽略了Tomcat的镜像也是会变更的啊。另外,我只提供了一个最佳实践的思路给你,具体的方案应该你自己根据需求自己设计。比如,如果你的tomcat镜像从来就几乎没更新过,那干脆拿它做基础镜像都行。

    2018-10-05
    4
    10
  • extraterrestrial!!
    容器不能管理多进程那块,能不能每个容器都默认搬一套系统的init过去,而不要让普通应用进程做进程1,这样是不是就可以支持容器里面管理多进程了?

    作者回复: 对。不过我们现在讲的古典互联网技术不太建议这么做,这是原始互联网时代的思路。

    2018-09-21
    2
    10
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部