动态容器达米恩·卡佛引用此版本：达米恩·卡佛动态容器的高级整合。操作系统[cs.OS]。索邦大学，2019年。英语NNT：2019SORUS513。电话：02393773v3HAL Id：tel-02393773https://theses.hal.science/tel-02393773v32021年2月12日提交HAL是一个多学科的开放获取档案馆，用于存放和传播科学研究文件，无论它们是否已这些文件可能来自法国或国外的教学和研究机构，或来自公共或私人研究中心。L’archive ouverte pluridisciplinaireDECTORALEEDITEDEPARIS（ED 130）信息，联系我们电子科技圣奥博内医生与尼维尔西特医生的关系SPÉCIALITORY：INGENIERIE/ SYSTELUMESINFORMATIQUESPRÉSENTÉE PAR：DAMIENCARVERPOUR OBTENIR LE GRADE DE：DOCTEUR DE SORBONNEU NIVERSITTHEYSUJET DE LA THYLESE：D型动力容器的一种离散C型2019年17月17日星期四晚陪审团名单：报告员：欧贝尔·埃维耶Bordeaux University波尔多大学GILLES GRIMAUDUniversité de Lille 1审查员：吉尔斯·穆勒因里亚医生ALain TChanaNice Université de NiceBÉATRICE BÉRARD索邦大学JEAN-PIERRE LOZIOracle实验室技术人员主要成员Encadrants：SÉBASTIEN MONNET萨瓦勃朗峰大学JULIEN SOPENA索邦大学硕士DIMITRI REFAUVELET首席技术官梅扎尼察2太感谢你了，没有你这是不可能的C内容内容31引言72资源虚拟化112.1虚拟机：硬件级虚拟化. . . . . . . . . . . . . . . . .112.1.1机器虚拟化的。. . . . . . . . . . . . . . . . . . . . . .122.1.2在完全虚拟化环境中提高利用率。. . . . . . . . .132.1.3提高半虚拟化环境中的利用率。. . . . . . . . .132.2容器：操作系统级虚拟化。. . . . . . . . . . . . . . .132.2.1使用cgroups隔离物理资源。. . . . . . . . . . . . . . . .142.2.2使用命名空间隔离资源可见性。. . . . . . . . . . . . .172.2.3用安全特性抑制攻击面。. . . . . . . . . . .202.3容器和虚拟机比较。. . . . . . . . . . . . . . . . . . . . . . . . .222.3.1比较独立管理费用。. . . . . . . . . . . . . . . . . . .232.3.2性能隔离和过度承诺的。. . . . . .232.3.3虚拟机应该模仿容器吗？. . . . . . . . . . . . . . . . . . . . . .242.4巩固和孤立，两全其美。. . . . . . . . . . . . . .252.4.1资源整合。. . . . . . . . . . . . . . . . . . . . . . . . . .262.4.2性能隔离。. . . . . . . . . . . . . . . . . . . . . . . . . . .262.4.3使用CPU cgroups说明整合和隔离。. . .262.4.4块I/O，类似于CPU的基于时间的资源。. . . . . . . . . . . .292.5记忆是一种空间资源，而不是时间资源。. . . . . . . . . . . . . . . . .312.5.1结论。. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333内存和cgroup353.1在主存储器中存储数据。. . . . . . . . . . . . . . . . . . . . . . . . . . .353.1.1内存层次结构。. . . . . . . . . . . . . . . . . . . . . . . . . . . . .353.1.2空间复用。. . . . . . . . . . . . . . . . . . . . . . . . . . . .363.1.3时间复用。. . . . . . . . . . . . . . . . . . . . . . . . . . .363.1.4需要内存cgroup。. . . . . . . . . . . . . . . . . . . . . . .373.2使用cgroup计算和限制内存。. . . . . . . . . . . . . . . . .373.2.1事件、统计和页面计数器。. . . . . . . . . . . . . . . . . . . . . . .383.2.2最小、最大、软限值和硬限值。. . . . . . . . . . . . . . . . . . . . . .4034目录3.3隔离cgroup内存回收413.3.1Linux内存池413.3.2拆分内存池423.4调整动态内存池的大小443.4.1调整匿名和文件内存池的大小443.4.2调整cgroup内存池的大小463.5结论.504合并时的隔离缺陷514.1建模整合514.1.1模型假设514.1.2反措施. 534.1.3在Madagency54的工业应用4.2整合：曾经是解决方案，现在是问题544.2.1与集装箱合并544.2.2不使用集装箱的合并4.2.3衡量合并误差564.3学到的教训595捕捉活动变化615.1旋转比：一个lru依赖的度量615.1.1使用RR62检测浪费内存的I/O模式5.1.2使用RR64平衡匿名和文件内存5.1.3RR可能产生假阴性645.1.4额外的force_ scan会消耗CPU时间并影响隔离645.1.5结论675.2怠速比：一个lru独立度量675.2.1IR精确地监视空闲页68的集合5.2.2CPU时间成本和IR准确性之间的权衡5.2.3结论705.3结论706C组的持续隔离716.1使用force_ scan71刷新lrus6.1.1结论736.2Buildingopt：a relaxed optimal solution建筑选择：一个宽松的最佳解决方案736.2.1在层次结构的所有级别应用soft_ limits746.2.2使用reclaim_ order75按活动级别对cgroups进行排序6.2.3堆叠一般政策766.3活动水平786.3.1AMetric-driven approach to predict activities. 786.3.2对活动变化作出反应的事件驱动方法806.4结论82目录.57对衡量标准和事件驱动方法的评估837.1实验装置837.1.1网络7.1.2活动转移和资源配置时间表857.1.3Blkio cgroup85的节流问题7.1.4实验配置867.2业绩分析7.2.1控制实验897.2.2基于事件的解决方案897.2.3基于公制的解决方案907.3页面传输分析907.3.1旋转比率解决方案927.3.2怠速比解决方案927.3.3基于事件的解决方案927.4结论.938结论和未来工作958.1短期挑战8.1.1在最不活跃的集装箱上展开争夺978.1.2确保所有容器都处于活动状态时的属性978.2长期前景8.2.1确保集群规模的隔离和整合988.2.2利用有限的内存实现全局性能化99参考书目101学术参考文献101技术参考107索引1151一、生产云计算现在是数字产业的核心[6]。 它通过向任何人提供远程产品来清除拥有和操作物理硬件的需求：从Web服务提供商到HPC科学家，从智能手机用户到视频游戏玩家[5 3，68，69，7 9]。这种从购买模式向租赁模式的转变主要是通过资源虚拟化实现的。有很多原因导致客户端欣赏虚拟资源超过物理资源。客户端可以按需租用虚拟资源，有或没有时间承诺，他们可以根据负载自动调整租用的虚拟实例的数量[78，57]。 一旦购买，虚拟资源就可以立即访问，不需要发送. 借助代理缓存或预定义的磁盘映像，可在云中优化新虚拟资源上的通用软件部署。虚拟资源的启动时间也很快，因为生产中的机器很少关闭。此外，可以迁移虚拟资源，以便在硬件故障或维护时保持可用，并在新硬件可用时保持最新状态Devops工程师G.Klok建模，在Amazon Web Service上租用100个m4.2xlarge实例比在运营商酒店中构建一个等效集群更便宜[143]。云计算提供商也远没有后悔“裸机”硬件是唯一可以租用的产品的日子实际上，一旦物理资源被分配给客户端，就几乎不可能将该资源用于其他目的。 虚拟资源更灵活，并且它们实现了这种资源复用。这一特性导致了云计算中一个有争议的做法：出售比物理可用资源更多的虚拟资源即使超额预订没有被广泛建议，它也已经成为云计算的必要条件 在其他行业，这是一种常见的做法，用于避免浪费。 当买家预计将部分消耗其应得的资源时，超额销售确保所有可用资源将被使用[76]。云计算提供商在这个事实上赌博因此，他们需要工具来检测和7CH A P T E R8第1章介绍在保证的隔离级别范围内整合资源例如，Amazon Web Service提供现货实例，而GoogleCloud Platform提供可抢占实例。这些产品应该出售未售出的资源，但没有任何东西禁止云提供商出售未使用的资源。传统的基于管理程序的虚拟化技术能够有效地整合vC-PU，但它们仍然难以在虚拟机之间快速转移未使用的内存问题的核心是两个实体之间缺乏合作已经提出了一些整合内存的技术（自动化[84]，自动化[30]），但它们很难实现，并且通常是侵入性的（客户操作系统的修改），缓慢（虚拟机之间需要同步）和手动（自动化程序仍然是原型）。最近，轻量级的基于容器的虚拟化解决方案已经开始出现，许多人现在想知道容器是否正在取代虚拟机[120]。 即使虚拟机比容器更不容易受到安全攻击，但后者在提供性能隔离和整合方面表现出色，因为它们共享相同的内核。简而言之，性能隔离是客户所关心的：他们希望虚拟资源的性能与专用的裸金属资源一样。整合是提供商所关心的：他们希望虚拟资源自动转移到真正使用它们的客户端。我的博士这篇论文由Magagency [73]和ANRT [56]赞助，研究了Linux容器之间的安全整合和性能隔离的全部范围 尽管容器具有创新性的承诺，但当他们试图使用容器来提高资源利用率时，他们面临着一个问题。他们最活跃的应用程序遇到了短暂的减速，因为它们耗尽了内存。然而，由于分配给其他不活动的应用程序，大部分数据库都没有使用。简而言之，我们发现Linux容器无法将内存从未使用的位置转移到需要的位置实际上，内存管理结构内部对隔离的需求剥夺了Linux内核正确识别机器上最未使用内存的能力。这位博士所面临的挑战论文是双重的。 首先，它必须让内核意识到，有些容器使用很少的内存，有些容器需要更多的内存。另一方面，它还必须给予内核正确识别上述容器的能力。如果能够应对这一挑战，内核就能够真正提供整合和性能隔离。这项研究的贡献是：• 一个简单的实验，强调了Google Perfkit [66]（MySQL [75]和Cassandra [58]）使用的实际应用程序可能在生产环境中出现的问题• 对Linux内核的仔细代码分析的综合，抓住了内存管理结构内部存在的问题的根源9• 设计并实现了两种内核级方法，用于检测哪些容器内存过多，哪些容器内存过少。这两种方法都知道容器的内存需求必须是有序的，但是第一种方法依赖于度量来进行区分，而另一种方法依赖于内核事件。• 在两种活动模型下使用两种类型的工作负载（Sysbench [144]和Memtier [74]）进行全面评估，将两种方法推向极限。本文档的组织如下：第2章介绍了两种虚拟化资源的技术，第3章介绍了理解Linux在容器之间正确传输内存时所需的技术背景，第4章通过一个可能发生在生产中的简单实验演示了这个问题，第5章研究了两个可以检测内存何时未使用的内核指标，第6章提出了在整合期间保持隔离的内核修改，第7章评估了我们的解决方案，第8章总结并介绍了未来的工作。具体而言，各章如下：资源虚拟化是云计算的基石，但第2章建议出于效率原因，部署在虚拟机中的一些工作负载应该转移到容器中。第一部分赞扬了虚拟机的特性，这些特性催生了云计算。 然而，硬件级虚拟化在设计上引入了额外的成本，限制了云的效率。在第二部分中，第2章揭开了容器 第三部分介绍了比较容器和虚拟机的文献工作，并得出结论，前者比后者更有效。 第四部分介绍了本文的两个核心概念：性能隔离和性能整合，并通过具体的实验加以说明。虽然这两个属性在CPU和磁盘带宽的情况下都可以确保，但本章的最后一部分表明，在内存的情况下，这些属性更难确保为了充分理解本论文中提出的问题，第3章深入探讨了Linux内核中内存和cgroup的一些第一部分将存储器作为一种资源，以页面为单位进行管理，并且可以在空间和时间上进行多路复用。第二部分详细介绍了如何在Linux内核中占用内存以及如何限制内存第三部分解释了Linux如何将页面存储在池中以订购其实用程序，然后解释了为什么它们不能存储在单个池中。最后一部分解释了如何动态调整同一容器的内存池的大小，但正如相关工作所承认的那样，相同的原则不能应用于不同容器的内存池上述问题一般来说很难解决，但第4章建议可以防止合并时的一些 第一部分提出了一个特定的记忆活动模型，其中应该保持隔离，以及这个模型是如何受到Magency应用程序的启发。 第二部分用一个简单的实验再现了在美国旅行社遇到的问题。此外，它通过一个微基准测试表明10第1章介绍在没有容器的情况下部署，但在容器中部署时错误地合并。最后，最后一部分应用第3章中获得的知识来解释这些实验中观察到的解决这个问题的第一步是用记忆相关的指标来捕捉活动的变化第五章研究了两个度量指标：转速比和怠速比。它们的成本和准确性的测量是在活动发生变化但没有巩固记忆的意图第6章介绍了我们在内核中开发的修改，以在整合期间保持cgroups的隔离开发的第一种机制允许用户控制旋转比率的新鲜度。在第二部分中，描述了一系列的机制它们使得能够表达通用的存储器回收策略，并且特别地，它们使得能够表达相对最优的解决方案 在最后一部分中，提出了两类解决方案。他们的目标是尽可能准确地猜测活动级别，以获得最佳解决方案：一个类基于第5章中介绍的度量，另一个类基于内核事件，即“页面需求”和“页面激活”。第7章对这些解决方案进行了评估。第一部分介绍了我们的实验设置的方法学，它使用两种工作负载类型和两种不活动模式。 这些实验比第4章中介绍的实验更难巩固。其余部分报告解决方案相对于性能最差的容器的性能和整合错误。 评估突出了不同解决方案的优点和缺点，并显示了与完全了解活动水平的最佳解决方案相比的局限性。第8章总结并提出了未来的工作和展望。它总结了所做的工作，并强调了我们能够实现的一些实验结果在短期内，我们预计随着容器数量的增加，我们的原型会出现争议然后，我们提供了一些关于如何将我们的工作扩展到过度承诺的上下文中的线索，当所有容器都变得活跃时。最后，我们建议在这篇论文中研究的指标和事件也应该在集群的规模上进行研究，以解决节点平衡，启动和关闭的挑战。2RESOURCE V虚拟化在本章中，我们将介绍云中采用的虚拟化技术，以及如何使用它们来提高机器的产量硬件级虚拟化引入了催生云的关键属性，但最近，操作系统级虚拟化已经开始成为一种提供类似属性的轻量级替代方案2.1虚拟机：硬件级虚拟化硬件级虚拟化基本上是通过引入hypervisor来实现的：hypervisor是客户操作系统和托管硬件之间的一个新的软件层为.Tanen-baum解释说，有两种类型的虚拟机管理程序[45]：图2.1：Hypervisor类型。11CH A P T E R12第2章.资源虚拟化metal和类型2管理程序利用底层操作系统（OS）提供的抽象（参见图2）。①的人。无论哪种方式，虚拟机管理程序的目标都是在一台计算机上托管多个虚拟机（VM）虚拟机是真实机器的准确，隔离和有效的副本[38]。 使用VM时出现了几个有趣的特性：1. 仿真：虚拟机管理程序创建虚拟机负责硬件的假象这种单独托管任何操作系统的能力导致许多应用程序，从运行遗留软件到运行操作系统专用软件，从调试内核开发到调试多操作系统软件开发。2. 安全性：虚拟机管理程序比操作系统更不容易出现错误，因为它们只做一件事：模拟裸金属的多个副本。 错误和故障不太可能从VM传播到VM或虚拟机管理程序。3. 安全性：虚拟机管理程序通常不允许多个虚拟机同时访问给定的物理资源与进程级相比，VM级攻击面较小。不幸的是，这两个表面都对硬件设计敏感[28，26]。4. 经济性：虚拟机管理程序节省了数据中心的硬件、电力和机架空间方面的资金，因为当单个机器被多路复用到多个虚拟机中时，需要的物理机器更少。专门从事数据中心管理并配备该领域专家的公司利用了这些属性;并通过允许客户通过虚拟化远程访问其物理资源而诞生了云。云 中 的虚拟机对客户端具有不可否认的吸引力，因为与物理机相比，它们是可调整大小的，已经由提供商供电，冷却，维护和升级。一方面，通过在同一台机器上部署多个客户端来实现规模经济，但另一方面，他们的隐私和服务质量面临风险。2.1.1机器虚拟化的成本为了尽可能地提高机器虚拟化的效率，已经做了大量的努力。 在硬件辅助虚拟化之前，用于防止VM执行敏感指令的陷阱和模拟技术是不够的，并且管理程序必须动态地转换这些指令。如今，得益于硬件辅助功能（Intel VT-x、AMD-V），机器虚拟化的成本现在可以接受：i）CPU方面，包含额外的指令以满足Popek和Goldberg [38]的正式要求1。ii）存储器方面，加入了额外的寄存器，让MMU访问双地址转换所需的嵌套页表（Adams和Agesen[1]）。iii）IO-wise，IOMMU的添加可以提供设备隔离[9]，以及1所有敏感指令（可能影响hypervisor）必须是特权指令（可能被hypervisor捕获2.2. 容器：操作系统级虚拟化13SR-IOV设备现在可以显示为多个单独的设备[15]。不幸的是，据报道，尽管在具有少数核心的机器上很小，但在大型NUMA机器上开销变得不可接受[48]。此外，VM不能最大化资源利用率，必须设想无数专用方案来解决这一限制。2.1.2在完全虚拟化环境中提高利用率很少有方案尊重全虚拟化范例，其中VM是不能修改的非合作黑盒最常见的方案针对的是部署同一客户操作系统的多个实例所导致的相同数据的重复。 由于Linux KSM [5]等工作，虚拟机管理程序努力消除重复数据以节省数据。VSwapper[3]是另一种尊重完全虚拟化并试图解决双分页异常的方案[20]。当虚拟机管理程序和虚拟机都运行驱逐策略时，就会发生这种异常，而这些策略最终会自相矛盾。 Goldberg表明，虚拟机内存大小的增加而实际内存大小没有相应的增加，可能会导致页面错误数量的显着增加。管理程序的内存热插拔仿真也被建议作为在VM之间动态平衡内存的一种方法[127]。2.1.3提高半虚拟化环境中的利用率剩下的大多数方案都属于半虚拟化领域，因为VM和hypervisor之间缺乏协作会产生太多的复杂性。半虚拟化的最极端形式要求客户操作系统显式地移植，以便通过使用hypercall与hypervisor通信 在半虚拟化的另一端，一些侵入性较低的方案利用客户操作系统中的现有接口来插入额外的通信逻辑。虚拟化[46，8 4]使用Linux virtio驱动程序[41]，并允许hypervisor请求客户机释放其内存。 Linux [ 90]使用Cleancache API，并允许VM将其未使用的内存借给另一个远程VM。总之，机器虚拟化最终增加了执行时间和内存空间，并加重了软件和硬件开发的负担。幸运的是，容器不太受这些缺点的影响，并为更高效的云打开了大门。2.2容器：操作系统级虚拟化lambda用户最需要的虚拟化属性是能够封装和运行整个环境的任何地方，包括软件依赖项，库，运行时代码和数据。 Singularity是唯一专注于这个想法的容器引擎之一[27]，但大多数容器引擎都利用了所有可用的内核功能来强制隔离。没有容器内核对象[104]。因此，可以将容器定义为内核隔离特性的集合。例如，Docker14第2章.资源虚拟化Cgroup资源CPUCPU时间中央处理机CPU核心和内存节点存储器ram使用布尔基奥块输入输出冰柜暂停/取消暂停设备在设备文件PIDs数量的过程hugetlbnet_ prionet_ cls穿孔事件巨大的页面（2 MB，1 GB）网络数据包排队规则的优先级过滤和分类网络数据包。聚合性能实用程序事件。表2.1：Cgroup类型和相关资源。将其容器引擎作为“在任何地方构建、发布和运行任何应用程序”的解决方案2.2.1使用cgroups隔离物理资源在cgroups出现之 前，诸如 nice、ionice 、mlock、madvise、 fadvise、taskset、numactl、trickle[16]和setrlimit等实用程序可以用来控制单个进程，但不存在这样的东西来控制一组进程。Cgroup是“control group”的缩写它是Linux内核的一个特性，可以分层地对进程进行分组，并以受控和可配置的方式沿层次结构分配系统资源[147，125]。 容器使用cgroups来限制、说明和隔离物理资源的使用。作为N.Brown解释说[82]，在将这种过程分组视为组织层次或分类层次方面存在一些分歧，但两种观点都是正确的。 在分类层次结构中，所有成员不能位于内部节点中，但在组织层次结构中，负责管理其他成员的成员位于内部节点中。当前的cgroupsAPI版本非常混乱，并且在资源之间不一致，但这些问题将在版本2中得到修复[126，15 0]。cgroupAPI 被 公 开 为 一 个 虚 拟 文 件 系 统 ， 安 装 在 /sys/fs/cgroup 中 ， 进 程 可 以 在/proc/PID/cgroup中查找它们的成员关系。本小节的其余部分详细介绍了表2.1中列出的cgroup子系统。 由于cgroups仍在开发中，因此将添加额外的cgroup子系统，例如rdma cgroup [1 49]以及内存库和CPU缓存cgroup [51]。可以设想更多的cgroup子系统;例如，实现一个控制内存带宽的cgroup可能是明智的[11]。2.2. 容器：操作系统级虚拟化15CPUCgroupcpucgroup有两个主要特性。第一个特性静态地限制任务。 它可以被视为CPU配额或CPU带宽。 它有两个参数：一个定义任务可以在CPU上运行多少时间，另一个定义更新以前的运行配额所需的时间。 第二个特性在没有空闲CPU时间时动态地限制任务。它有一个共享参数，保证任务至少能够获得与参数2成比例的CPU时间。这两个特点是相辅相成的。 第一个有助于避免CPU短缺，而另一个则规定了完全公平竞争（CFS）在处理CPU短缺时的指导方针。cpusetcgroupcpuset特性早于通用的cgroup实现，并且是第一个被添加的 它限制进程在CPU的子集上运行，并强制它们在内存节点的子集上分配内存。cpusetcgroup提供了更多的功能[108]：核心和节点可以成为独占的，内存压力可以监控，内存分配可以分散在所有节点上，而不是优先分配的节点负载平衡可以划分为域，等等。内存cgroup内存cgroup子系统是本论文的核心，在第3章中有详细的介绍。简而言之，当任务试图超过其cgroup的内存限制时，它会限制任务。事实上，当它们达到极限时，任务被迫运行页帧回收算法，该算法会回收它们现有的一些内存。内存cgroup还控制内核对象、交换和TCP缓冲区的内存消耗blkiocgroupblkiocgroup类似于cpucgroup。它可以以每秒字节数或每秒操作数为单位，对每个设备的读写进行静态节流。它还具有每个设备的权重参数，这些参数在设备饱和时动态指导完全公平冗余（CFQ）I/O开销3。冷冻柜cgroup冻结功能最初是为休眠而开发的，比SIGSTOP/SIGCONT机制更强大，因为它不能被进程捕获freezercgroup可用于从用户空间调度批处理作业[109，65，157]，但也可用于CRIU的检查点设置和迁移[62]。当用户冻结一个cgroup时，一个虚假的信号被发送到它的所有进程，同时也发送到它的子进程。当它收到一个2共享参数不适用于实时同步（R-T）。3前提是设备（/sys/block/device/queue/scheduler）启用了CFQ16第2章.资源虚拟化信号4，如果其cgroup状态为冻结，则处理将转到冰箱5此外，新创建的进程不能逃脱冻结机制，因为冻结器cgroup在进程分叉时得到通知当用户解冻cgroup时，进程被唤醒并离开冰箱。设备cgroup设备cgroup为块和字符设备文件提供强制访问控制（MAC）。 它考虑到了层次结构：子节点没有比父节点更多的权限。当用户更新cgroup6的权限时，i）新的限制总是被传播到它的孩子，以及ii）新的授权被请求到它的父母，父母可以拒绝它们。因此，权限检查比它们的更新相对更快，因为不必遍历层次结构当进程调用open和mknod时，通过两个新的内核函数7检查每个cgroup的读、写和创建权限。pidscgrouppids cgroup控制fork系统调用，并在cgroup的进程数超过其最大限制时阻止创建新进程。由于记帐是分层的，当子cgroup或其任何父cgroup达到其限制时，fork系统调用将通过返回 乍一看，进程可以被看作是内存中的内核结构，因此，限制属于cgroup的内核对象的内存消耗在理论上应该防止进程标识符（pid）被释放。但实际上，系统中的PID总数当前被限制为8到10。222 因此，如果没有pidscgroup，一个fork bomb可以很容易地耗尽pid表，用-内核对象内存限制。hugetlbcgroup巨大的页面用于最小化在页表中查找的条目，从而最小化TLB未命中（翻译后备缓冲器）。 一旦分配给全局池（最好是在引导时），巨大的页面就不能再用于其他目的，也不能换出。hugetlbcgroup控制允许cgroup分配的巨大页面的数量net_ cls和net_ prio组网络cgroups（net_ cls和net_ prio）提供了识别数据包所有权的方法和覆盖数据包优先级的方法，但它们没有利用层次结构4函数get_ signal在处理挂起信号之前调用try_ to_ freeze5冰箱是一个循环的时间表。6函数devcgroup_ update_ access修改MAC。7调用函数devcgroup_ inode_ permission和devcgroup_ inode_ mknod来实施MAC。8参见/proc/sys/kernel/pid_ max。2.2. 容器：操作系统级虚拟化17命名空间分离株分层用户用户和组id是的PID进程id是的山文件系统装载点传播规则网络网络插座、设备、表等没有IPCSystem V IPC，POSIX消息队列没有CgroupCgroup路径名，根cgroup没有UTS主机名和NIS域名没有表2.2：空间类型和孤立资源。并且还没有直接提供限制、计费和隔离特征[102]。网络cgroups扩展了以下内核对象：i）网络设备对象现在为每个cgroup9都有一个优先级，ii）套接字对象现在有两个额外的字段，称为classid和prioidx。当一个进程创建一个新的套接字时，classid和prioidx字段被初始化为它所属的cgroup的值prioidx对应于priority数组中的cgroup索引，而classid是从用户空间设置的然后，CLASSID可以与iptables一起使用，以选择性地过滤分组（防火墙规则），但是也可以与TC（流量控制）一起使用，以在网络调度期间对分组进行分类。同 时，优先级值可用于覆盖分组传递和延迟排队规则使用的SO_PRIORITY选项[61，60]。perf_ eventcgroupperf_ eventcgroup是最基本的cgroup。它允许Linux的性能分析工具perf [1 22]收集和聚合属于cgroup的进程的性能数据。perf_ eventcgroup使用层次结构，因此来自属于被监视cgroup的子进程的度量也被收集10。结论Cgroups是Linux内核的一个集成良好的独立特性默认情况下，有一个根cgroup，进程在其中产生，但容器引擎甚至常见的Linux发行版都会创建额外的cgroup来隔离资源利用率。然而，正如我们将在第4章中看到的那样，大多数用户都没有意识到创建多个cgroup会导致不必要的陷阱[52]。2.2.2使用命名空间隔离资源可见性在命名空间出现之前，chroot或pivot_root等实用程序可以用于在本地重塑文件系统的视图，但没有通用API来实例化任何给定资源的并发视图9优先级存储在netprio_ map数组中，可以从用户空间配置10perf18第2章.资源虚拟化作为M. Kerrisk解释说[1 35]，命名空间是Linux内核的一个特性，它为进程创建系统资源的私有本地视图，并给它们一种错觉，即它们是控制资源的唯一一组进程。 容器使用命名空间来禁止进程之间不需要的操作系统级交互。 与cgroups相反，只有两种类型的名称空间是纯层次的：User和PID。尽管如此，由于父进程可以访问其子进程的/proc/PID/ns/文件，因此仍然可以以分层方式配置其余的命名空间类型。命名空间只能通过系统调用来创建;如果命名空间中没有剩余的进程，并且没有更多对其proc文件的引用，则它们将被销毁。给定适当的选项，四个系统调用操纵命名空间[136，70]：• clone将在新创建的命名空间中创建新进程• setns允许进程加入先前创建的其他命名空间• unshare创建新的命名空间并使调用进程加入它们。• ioctl_ ns通过/proc/PID/ns/文件公开名称空间成员和层次关系。E. Biederman最初确定了十个名称空间[10]，本小节的其余部分详细介绍了其中最成熟的名称空间（如表2所示）。2）。还有更多的命名空间要实现（例如syslog [132]，device [112，4，146，59]，sysfs [88]，安全模块[148，85，128]，keyring [121]和time [121]），但它们不能引入新的漏洞（例如以前报告的漏洞[100，97，96，134]）。此外，当前的命名空间仍然存在一些未解决的问题，例如非特权文件系统安装[98]，文件功能[105]和文件系统中存储的uid [117，119]。用户命名空间User命名空间[139，140，133]将真实用户（UID）和组（group）标识符重新映射到任何自定义虚拟号码。 由于这些标识符可以重新映射到超级用户的标识符，因此用户名称空间还提供了进程获得完全特权能力的假象。但实际上，并不存在特权升级，因为这些功能仅对在用户名称空间内创建的对象上的操作有效对于在外部创建的对象，功能仅限于已授予的功能允许非特权进程创建用户命名空间，而其他类型的命名空间（PID、Mount、Network、IPC、UTS、Cgroup）被认为是由创建它们的用户命名空间所拥有的。结果，只有当进程在用户中具有正确的能力14时，诸如改变文件系统的根12、设置主机名、安装虚拟文件系统13和绑定预留套接字端口的操作才被授权11proc文件既未打开也未挂载绑定。12chroot/proc，/sys，tmpfs.14CAP_ BIND_ CHROOT、CAP_ BIND_ ADMIN、CAP_ NET_ BIND_ SERVICE。2.2. 容器：操作系统级虚拟化19命名空间，它拥有相应的非用户命名空间。 由于用户命名空间是嵌套的，父命名空间中的进程仍然可以控制子用户命名空间中的资源。PID命名空间PID命名空间[137，138]是嵌套的，并且进程在层次结构的每个级别具有不同的标识符（PID）从一个名称空间的角度来看，进程有一个给定的PID，但从更高的名称空间的角度来看，它的PID是不同的。 由于PID命名空间的层次特性，一个进程只能访问属于它的命名空间或属于它的命名空间的后代的其他进程，因此，例如，只能发送信号。 PID命名空间简化了迁移，因为进程可以将其PID保留在新主机上，即使它们已经归属于祖先或兄弟命名空间中的其他进程。填充名称空间的第一个进程（init）与引导时生成的第一个进程（真正的计算机范围的init）一样重要在其命名空间中，init的PID为1。 作为“所有进程的祖先”，init负责初始化、获取已终止的孤立进程以及优雅地终止整个命名空间15。Init是如此重要，以至于在它死亡时，内核将SIGKILL发送给剩余的进程，并拒绝16新进程的创建，使名称空间无法使用17。因此，如果没有声明相应的处理程序，发送到init的信号将被忽略;但是来自父命名空间的进程仍然可以发送SIGKILL或SIGSTOP信号。Mount命名空间Mount命名空间[141，142]提供了文件系统树的私有视图，并允许进程独立地重塑它们的视图。当创建新的挂载命名空间时，它会复制文件系统的当前视图之后，由于每个名称空间都有自己的挂载点列表，因此一个名称空间中的mount和umount操作的结果对其他名称空间不可见。还可以使用其他选项来挑选挂载点修改并将它们从一个命名空间传播到另一个命名空间。网络命名空间Network命名空间[114，87]可以用来在一台机器上配置任何复杂的虚拟网络。 这些网络可以允许或拒绝名称空间之间或与Internet的传入或传出连接。每个名称空间都有自己的网络相关资源，如套接字、地址、接口、路由表、防火墙规则等。 当创建新的网络命名空间时，它只有一个网络设备。由于网络接口只能属于一个名称空间，系统将耗尽物理接口。因此，可以创建虚拟接口对，并在名称空间之间移动，15docker stop在SIGKILL之前将SIGTERM发送到容器的init进程16fork，在一些setns或创建命名空间的unshare之后调用，返回ENOMEM。17进程不能加入另一个PID命名空间，它们的成员资格在创建时定义
我的内容管理
展开
