第2篇：容器占用宿主机的资源的决定因素

容器占用宿主机的资源的决定因素

问题一：容器 等于做了NameSpace的特殊进程 ，NameSpace已经做出了进程的隔离 为什么还要对进程做限制呢？

从容器的角度看容器：容器内的1号进程在“障眼法”的干扰下只能看到容器里的情况
从宿主机的角度看容器 ： 在宿主机上，这个容器的1号进程是作为第1xx号进程和其他的进程之间依然是平等的竞争关系
得出：虽然1xx进程表面上被隔离了起来，但是它能够使用的资源 (cpu/内存)，是可以随时被宿主机上其他的容器占用的
这个1xx进程也有可能把所有的资源全部吃光
这样是不合理的

问题二：从linux内核来看怎样对进程做资源的限制？

linux中Cgroups是linux内核中用来为进程设置资源限制的一个方法
Cgroups 限制一个进程组能够使用的资源的上限 ：包括 CPU、内存、磁盘、网络带宽
Cgroups 能够对进程进行优先级设置 、审计、进程挂起、进程恢复
总结来说：linux的Cgroups就是一个子系统目录加上一组资源限制文件的总和

引申问题：Cgroups是怎样在linux中起作用的？原理是什么？后续文章解答

****从Docker来看****其实就是在子系统目录下面，为每个容器创建一个控制组（子系统目录下再新建一个目录） 启动容器进程之后，把进程的PID填写到对应控制组的tasks文件中

栗子：在Docker的控制组下面的资源文件中增加值，是在docker run的时候指定的 
docker run -it --cpu-period=10000 --cpu-quota=20000 wanglili /bin/bash 
启动这个容器之后，可以通过查看Cgroups文件系统下，cpu子系统中的"docker"控制组里面的资源限制文件来进行确认

通过查看Cgroups文件系统下，cpu子系统中的"docker"控制组里面的资源限制文件来进行确认

总结归纳：

（1）容器是 “单进程” 模型，是一个增加NameSpace手段的特殊进程
从容器角度来看世界，有一种” 坐井观天 ”的感觉，单纯的认为“ 唯我独大 ”

（2）一个正在运行的Docker容器，其实就是启用了多个Linux NameSpace的应用进程，这个进程的使用的资源量，受Cgroups配置限制

（3） 于此同时也解释了：linux以systemd来作为容器的启动进程的原因
一个容器的本质就是一个进程，用户的应用进程就是容器里面pid=1的进程，也是后续创建的所有进程的父进程
延伸1：在一个容器当中，是不能同时运行两个应用的
延伸2：如果想同时运行两个应用我要怎么办，如果能事先找到一个公共的PID=1的程序来充当两个不同应用的父进程，就可以实现同时运行两个应用，所以很多人用systemd和supervisod这样的软件代替应用本身作为容器的启动进程

疑问：
（1） 为什么对容器做“限制”,这种限制是针对的什么？本博客已经解决
（2）linux内核是怎样对进程做资源的限制的呢？ 本博客已经解决
（3）Docker相当于一个进程，这个进程怎么进行自我的资源限制的呢？ 本博客已经解决

（4）NameSpace怎样来创建呢?
（5）NameSpace在计算机中如果表示？
（6）一个进程如何“加入”到其他进程中的NameSpace中？
（7） 为什么很多人用systemd和supervisod来作为容器的启动进程？ 本博客已经解决

（8）容器还有一点很重要，就是容器和应用的同周期性，怎么能应用挂掉的同时，容器也宕掉？
容器和应用的同周期性不稳定，对容器的编排有怎样的影响？
（9） Cgroups对资源的限制也不是完美的 ，最大的问题是/proc文件系统的问题
linux下proc目录存储的是当前内核运行状态的一系列的特殊文件，
用户通过访问这些文件，查看系统以及当前正在运行的进程的信息：cpu的使用情况、内存的占用率
同时proc这些文件也是top指令查看系统信息的主要的来源
但是，对于容器来说，运行top命令的时候，显示的是宿主机的cpu和内存数据，不是容器的内存和数据
也就是说proc文件系统并不知道Cgroups对容器做了什么？

linux的cgroups详解请详细查看：
https://blog.csdn.net/f80407515/article/details/118554991

博客为学习记录，如有侵权，请联系博主