作者[JavaEdge]
Linux容器中拿来实现“隔离”的技术手段:Namespace。Namespace实际上更改了应用进程看待整个计算机“视图”,即它的“视线”被操作系统做了限制,只能“看到”某些指定的内容。对于宿主机来说,那些被“隔离”了的进程跟其他进程并没有区别。
在之前虚拟机与容器技术的对比图里,不应当把DockerEngine或则任何容器管理工具放到跟Hypervisor相同的位置,由于它们并不像Hypervisor那样对应用进程的隔离环境负责,也不会创建任何实体的“容器”,真正对隔离环境负责的是宿主机操作系统本身:
在这个对比图里,应当把Docker画在跟应用同级别但是靠边的位置。用户运行在容器里的应用进程,跟宿主机上的其他进程一样,都由宿主机操作系统统一管理,只不过那些被隔离的进程拥有额外设置过的Namespace参数Docker在这儿更多的是辅助和管理工作。
这样的构架也解释了为何Docker项目比虚拟机更受欢迎的诱因。
使用虚拟化技术作为应用沙盒,就必需要由Hypervisor来负责创建虚拟机,这个虚拟机是真实存在的,它上面必须运行一个完整的GuestOS能够执行用户的应用进程。这就不可防止地带来了额外的资源消耗和占用。
按照实验,一个运行着CentOS的KVM虚拟机启动后,在不做优化的情况下,虚拟机自己就须要占用100~200MB显存。据悉,用户应用运行在虚拟机上面,它对宿主机操作系统的调用就不可防止地要经过虚拟化软件的拦截和处理,这本身又是一层性能耗损,尤其对估算资源、网络和c盘I/O的耗损十分大。
而容器化后的用户应用,仍然还是宿主机上的一个普通进程,这就意味着那些由于虚拟化而带来的性能耗损都是不存在的使用Namespace作为隔离手段的容器并不须要单独的GuestOS,这就促使容器额外的资源占用几乎可以忽视不计。
“敏捷”和“高性能”是容器相较于虚拟机最大的优势
不过,有利就有弊,基于LinuxNamespace的隔离机制相比于虚拟化技术也有好多不足之处,其中最主要的问题就是:
1隔离得不彻底1.1多个容器之间使用的还是同一宿主机的操作系统内核
虽然可以在容器里通过MountNamespace单独挂载其他不同版本的操作系统文件,例如CentOS或则Ubuntu,但这并不能改变共享宿主机内核的事实!这代表假如要在Windows宿主机上运行Linux容器,或则在低版本的Linux宿主机上运列宽版本的Linux容器,都是impossible!
相比之下,拥有硬件虚拟化技术和独立GuestOS的虚拟机就要便捷最极端的事例是,Microsoft的云估算平台Azure,实际上就是运行在Windows服务器集群上的,但这并不阻碍你在它前面创建各类Linux虚拟机
1.2Linux内核中好多资源和对象是不能被Namespace化的
最典型的事例:时间
假如你的容器中的程序使用settimeofday(2)系统调用更改了时间,整个宿主机的时间就会被急剧更改,这或许不符合用户的预期相比于在虚拟机上面可以随意折腾,在容器里布署应用的时侯,“什么能做,哪些不能做”,都是用户必须考虑的问题。
据悉centos查看cpu使用率,因为上述问题,尤其是共享宿主机内核的事实
1.3容器给应用曝露下来的功击面是相当大的
应用“越狱”的难度自然也比虚拟机低得多。
虽然可以使用Seccomp等技术,过滤和甄别容器内部发起的所有系统调用来进行安全加固,但这就多了一层对系统调用的过滤,一定会连累容器的性能。即便,默认情况下,谁也不晓得究竟该开启什么系统调用,严禁什么系统调用。
所以,在生产环境中,没有人敢把运行在化学机上的Linux容器直接曝露到网段上。
基于虚拟化或则独立内核技术的容器实现,则可以比较好地在隔离与性能之间作出平衡。
2限制容器
LinuxNamespace创建了一个“容器”,为何还要对容器做“限制”呢?
以PIDNamespace为例
尽管容器内的第1号进程在“障眼法”的干扰下只能看见容器里的情况,而且宿主机上,它作为第100号进程与其他所有进程之间仍然是平等的竞争关系。这就意味着,尽管第100号进程表面上被隔离了上去,而且它所才能使用到的资源(例如CPU、内存),却可随时被宿主机上其他进程(或容器)占用的。其实,这个100号进程自己也可能把所有资源吃光。这种情况,其实都不是一个“沙盒”应该表现下来的合理行为。
LinuxCgroups就是Linux内核中拿来为进程设置资源限制的一个重要功能。
Google的工程师在2006年发起这项特点的时侯,曾将它命名为“进程容器”(processcontainer)。实际上,在Google内部,“容器”这个术语常年以来都被用于形容被Cgroups限制过的进程组。后来Google的工程师们说,她们的KVM虚拟机也运行在Borg所管理的“容器”里,似乎也是运行在Cgroups“容器”当中。这和我们明天说的Docker容器差距很大。
LinuxCgroups的全称是LinuxControlGroup。它最主要的作用,就是限制一个进程组才能使用的资源上限,包括CPU、内存、磁盘、网络带宽等等。据悉,Cgroups还能否对进程进行优先级设置、审计,以及将进程挂起和恢复等操作。只阐述它与容器关系最紧密的“限制”能力,并通过一组实践来认识一下Cgroups。
在Linux中,Cgroups给用户曝露下来的操作插口是文件系统,即它以文件和目录的形式组织在操作系统的/sys/fs/cgroup路径下
在/sys/fs/cgroup下边有好多例如cpuset、cpu、memory这样的子目录,也叫子系统这种都是我这台机器当前可以被Cgroups进行限制的资源种类。
而在子系统对应的资源种类下,你就可以看见该类资源具体可以被限制的方式。
这样的配置文件怎样使用呢?
须要在对应的子系统下边创建一个目录例如,我们如今步入/sys/fs/cgroup/cpu目录下:
这个目录就称为一个“控制组”。OS会在你新创建的container目录下,手动生成该子系统对应的资源限制文件!
如今,我们在后台执行这样一条脚本:
其实,它执行了一个死循环,可以把计算机的CPU吃到100%,依据它的输出,我们可以看见这个脚本在后台运行的进程号(PID)
于是,可以用top指令来确认一下CPU有没有被打满:
在输出里可以看见,CPU的使用率已然100%了(%Cpu0:100.0us)。
而此时,我们可以通过查看container目录下的文件,见到container控制组里的CPUquota还没有任何限制(即:-1),CPUperiod则是默认的100ms(100000us):
接出来,我们可以通过更改那些文件的内容来设置限制。
例如,向container组里的cfs_quota文件写入20ms(20000us):
结合上面的介绍linux串口驱动,你应当能明白这个操作的含意,它意味着在每100ms的时间里,被该控制组限制的进程只能使用20ms的CPU时间,也就是说这个进程只能使用到20%的CPU带宽。
接出来,我们把被限制的进程的PID写入container组里的tasks文件,里面的设置都会对该进程生效了:
我们可以用top指令查看一下:
可以看见,计算机的CPU使用率立即降到了20%
除CPU子系统外,Cgroups的每一项子系统都有其独有的资源限制能力,例如:
LinuxCgroups就是一个子系统目录加上一组资源限制文件的组合而对于Docker等Linux容器项目来说,只需在每位子系统下边,为每位容器创建一个控制组(即创建一个新目录),之后在启动容器进程以后,把这个进程的PID填写到对应控制组的tasks文件中!
而至于在这种控制组下边的资源文件里填上哪些值,就靠用户执行dockerrun时的参数指定了,例如这样一条命令:
#d:0:b:2:8:a:6命令:1:3:b:e:f:e:5:3:7:2:7:4:2:d:e:0:0:9:b:7:2:8#
在启动这个容器后,我们可以通过查看Cgroups文件系统下,CPU子系统中,“docker”这个控制组里的资源限制文件的内容来确认:
$ cat /sys/fs/cgroup/cpu/docker/5d5c9f67d/cpu.cfs_period_us
100000
$ cat /sys/fs/cgroup/cpu/docker/5d5c9f67d/cpu.cfs_quota_us
20000
这就意味着这个Docker容器,只能使用到20%的CPU带宽。
3总结
首先介绍了容器使用LinuxNamespace作为隔离手段的优势和劣势,对比了Linux容器跟虚拟机技术的不同,进一步明晰了“容器只是一种特殊的进程”这个推论。
不仅创建Namespace之外,在后续都会介绍一些其他Namespace的操作,例如看不见摸不着的LinuxNamespace在计算机中究竟怎样表示、一个进程怎样“加入”到其他进程的Namespace当中,等等。
紧接着详尽介绍了容器在做好了隔离工作以后,又怎样通过LinuxCgroups实现资源的限制,并通过一系列简单的实验,模拟了Docker项目创建容器限制的过程。
如今应当才能理解linux版qq,一个正在运行的Docker容器,虽然就是一个启用了多个LinuxNamespace的应用进程,而这个进程才能使用的资源量,则受Cgroups配置的限制。
这也是容器技术中一个十分重要的概念,即:容器是一个“单进程”模型
因为一个容器的本质就是一个进程,用户的应用进程实际上就是容器里PID=1的进程,也是其他后续创建的所有进程的父进程。这就意味着,在一个容器中,你没办法同时运行两个不同的应用,除非你能事先找到一个公共的PID=1的程序来充当两个不同应用的父进程,这也是为何好多人还会用systemd或则supervisord这样的软件来取代应用本身作为容器的启动进程。
然而,在前面分享容器设计模式时,我都会推荐其他更好的解决办法。这是由于容器本身的设计,就是希望容器和应用能否同生命周期,这个概念对后续的容器编排十分重要。否则,一旦出现类似于“容器是正常运行的,并且上面的应用早早已挂了”的情况,编排系统处理上去就十分麻烦了。
另外,跟Namespace的情况类似,Cgroups对资源的限制能力也有好多不健全的地方,被提到最多的自然是/proc文件系统的问题。Linux下的/proc目录储存的是记录当前内核运行状态的一系列特殊文件,用户可以通过访问那些文件,查看系统以及当前正在运行的进程的信息,例如CPU使用情况、内存占用率等,这种文件也是top指令查看系统信息的主要数据来源。
然而若果在容器里执行top指令,都会发觉,它显示的信息竟然是宿主机的CPU和显存数据,而不是当前容器的数据。导致这个问题的诱因就是,/proc文件系统并不晓得用户通过Cgroups给这个容器做了哪些样的资源限制,即:/proc文件系统不了解Cgroups限制的存在。
在生产环境中,这个问题必须进行修正centos查看cpu使用率,否则应用程序在容器里读取到的CPU核数、可用显存等信息都是宿主机上的数据,这会给应用的运行带来特别大的苦恼和风险。这也是在企业中,容器化应用遇到的一个常见问题,也是容器相较于虚拟机另一个不尽如人意的地方
参考