目录
1.先回顾一下容器的基本概念
容器的本质是什么?
容器是一个视图被隔离的资源受限制的进程,容器中PID=1的进程就是应用本身.
管理虚拟机=管理基础设施
管理容器=直接管理应用本身
那么Kubenetes的本质是什么呢?
Kubenetes就是云时代的操作系统.
以此类推,容器镜像其实就是这个操作系统的软件安装包.
2.看一个真实操作系统中的例子
假设这个例子中有一个程序是helloworld程序,这个程序是由几个进程组成的(这里所说的进程是对标
linux中的线程,linux的实现中线程是轻量级的进程).
这就是操作系统中进程组或者线程组的一个概念.课程中给出的其实是线程组的示例.
3.如何管理进程组及灵感来源
3.1如何管理进程组
Kubenetes=操作系统(比如linux)
容器=进程(linux线程)
Pod=进程组(linux线程组)
问题:老师这里说的一个“进程”挂了,其他“进程”成为孤儿“进程”,就相当于linux中一个进程中的一个线程挂
了,这样其他线程不就自动也挂了吗?还要管理啥?
容器是“单进程”模型,除非应用进程本身具备“进程管理”的能力,这意味着helloworld程序本身需要具备
systemd的能力,这会导致管理容器=管理systemd,但是不等于直接管理应用本身,会导致管理很复杂.
于是pod的观念出现了,它就相当于Linux中的“进程组”(其实是线程组)的概念.
在Kubenetes中,它会把一个一个线程放到一个一个容器中,然后这些线程定义在一个pod中,这时候,
当Kubenetes把helloworld拉起来的时候实际上会看到4个容器,它们共享了一些资源,这些资源都属于
pod,所以pod在K8S中只是逻辑单位逻辑概念,没有一个真实的东西对应这样一个pod,
3.2灵感来源
4.为什么Pod必须是原子调度单位?
Mesos的处理机制很悲观,Google Omega的处理极致很乐观.
就像乐观锁比悲观锁的实现机制复杂一样,Google Omega的处理更复杂一些.
图中所描述的问题在K8S中用Pod来解决了.
亲密关系&超亲密关系
5.Pod的实现机制
1.怎么去描述超亲密关系;
2.如何对超亲密关系的容器和业务做统一调度.
Pod要解决的问题:
如何让一个Pod连的多个容器之间高效地共享某些资源和数据?
容器之间原本是被Linux Namespace和cgroups隔离开的.
Pod的需要解决的核心问题就是如何打破Linux Namespace和cgroups所形成的的隔离.
5.1共享网路
在K8S中允许单独更新pod里面某一个镜像,整个Pod不会重建.
5.2共享存储
6.详解容器设计模式
6.1举例
容器是可迁移的,它的状态是不保持的.
这样就必须维护一套分布式存储系统,使得不管在A上还是B上都可以找到这个数据.
这样的复杂程度是比较高的,并且容器本身必须依赖于持久化的存储.
所以有更通用的方法呢?
哪怕在local的存储上,没有分布式存储的情况下,也能用,也能玩,也能发布.
实际上InitContainer可以做到.
6.2更通用的InitContainer方法
在YAML文件中首先定义了一个initContainer中,只做了一件事,就是把war包从一个镜像里拷贝
到一个volume中,干完这个事情之后就退出了.initContainer会比用户容器先启动,并且严格按照
定义顺序来依次执行.在文件中的那个/app目录实际上是一个volume,一个Pod里面的多个容器实际上
是可以共享volume的,所以现在tomcat容器只打包了tomcat镜像,但是在启动的时候申明要使用app
目录作为我的volume并且把它们挂载webapp目录下,由于前面已经执行了initContainer,已经执行
完拷贝操作了,所以volume已经存在了应用的war包,之后再执行启动一定可以找到sample.war了.
经过上面的描述我们可以发现,我们这个POD就是自包含的,在全世界的任何地方都可以运行它,也不需要
分布式存储,也不需要volume是否持久化,这个就是通过组合两个不同角色的容器来并且按照一定的编排
方式去统一的打包这样一个应用,用pod去做的一个非常典型的例子.
这样的一个概念就是K8S中非常经典的设计模式,Sidecar.
6.3容器设计模式Sidecar
6.3.1 Sidecar的第一个应用场景
6.3.2 Sidecar的第二个应用场景
6.3.3 Sidecar的第三个应用场景
7.本章小结