容器技术系列研究成果

Posted 2021-05-02 穿过丛林

容器私有资源视图

容器技术已经广泛应用于云计算环境下的软件交付、分发、部署。与虚拟机的硬件虚拟化不同，容器提供操作系统级的虚拟化。由于容器缺乏硬件抽象层且共享主机操作系统内核，隔离性不足成为制约容器技术发展和应用的关键瓶颈问题。针对容器在系统资源视图隔离能力上的不足，实验室容器研究小组详细分析了容器中应用面临的系统资源总量与系统资源限制之间的语义鸿沟，分析了其对容器中应用性能的严重影响，设计实现了容器私有资源视图，将系统实际分配的资源信息传递给容器中的应用；通过JVM和OpenMP两个案例，提出和验证了如何利用不断更新的CPU和内存资源视图来提高应用性能。

该成果“Adaptive Resource Views for Containers”发表于HPDC 2019 (The 28th ACM International Symposium on High-Performance Parallel and Distributed Computing)，是实验室吴松教授带领的容器研究小组与美国德克萨斯大学阿灵顿分校饶嘉博士的合作研究成果，也是我们在容器技术领域的系列研究成果之一。HPDC是由美国计算机学会组织的并行与分布式计算领域重要学术会议，今年共收到长文投稿106篇，录用22篇，录取率约为20%。论文原文: https://dl.acm.org/citation.cfm?id=3325403

摘要

随着操作系统级虚拟化的高速发展，容器已经广泛应用于云环境下的软件交付、分发、部署中，成为了虚拟机的可行替代品。在传统的虚拟机中，客户机操作系统必须运行在虚拟硬件上，且每个客户机都有自己的操作系统及内核。但是在容器中，应用可以直接访问主机的物理资源，并且多个容器间共享一个主机内核。相较于虚拟机，容器不需要额外的虚拟硬件层，这避免了不必要的虚拟化开销，但也带来了隔离性不足的问题。当前，隔离性问题给容器资源管理带来巨大的挑战。缺乏硬件抽象层，主机系统总是将物理资源总量暴露给每个容器，而实际上每个容器只能使用有限的系统资源，这使得基于系统资源视图来进行资源管理的运行时（OpenMp等）以及编程语言（Java等）受到严重影响。

在本文中，作者设计实现了容器私有资源视图，其核心设计是为每个容器创建新的sys_namespace，动态实时地计算每个容器有效的CPU资源和内存资源，并创建虚拟的sysfs，将用户态应用与sys_namespace 关联。同时作者通过JVM和OpenMP两个案例，介绍了如何构建弹性应用以使用动态的CPU和内存资源视图。实验表明该系统能够显著提升容器中应用的性能。

图1. 容器VS 虚拟机

图2. 容器底层实现

背景与动机

虚拟机与容器的底层实现原理如图1所示，主要有两点不同：1）容器比虚拟机更轻量级，容器只包含应用可执行文件以及相应的依赖库，但是虚拟机包含一个完整的操作系统；2）虚拟机必须通过Hypervisor（虚拟机管理器）将虚拟机指令转换成可以在主机上执行的指令，但是容器应用指令不需要转换即可在主机执行。由于容器运行在主机操作系统上，容器虚拟化开销更小。

但是由于容器间共享主机系统内核，所以容器需要基于主机操作系统实现隔离。如图2所示，在Linux系统下，容器主要基于Namespaces与 Cgroups实现隔离。Namespaces为容器提供某些资源的视图，以将容器彼此隔离。当前主要有 PID，User，Mount，UTS，Network Namespace。比如PID（进程id）Namespace就允许容器中的进程可以拥有内部的虚拟PID，而主机操作系统会将虚拟PID映射到真实的PID。Cgroups控制容器的资源使用，比如CPU，Memory，Disk，Network等资源，同一个容器的进程拥有相同的资源限制。

我们的工作主要关注CPU与Memory资源。Cgroups主要使用3个参数来管理CPU资源：1）Mask，它限制了容器只能在特定的CPU上运行；2）Limit，它限制了容器最多可以使用的CPU资源量；3）Share，它定义了在竞争CPU资源时不同的容器间的相对的权重。Cgroups对Memory有两种限制：1）Hard limit，它设置了容器可以使用的内存量的上限，当容器使用的内存超过这个值的时候，这个容器会被kill或者做Swapping；2）Soft limit，它为容器可以使用的内存量设置了一个软限制，当系统有空闲内存时，容器可以使用超过软限制的内存，但是当系统内存紧张时，系统会优先回收内存使用量超过软限制的容器内存。

虽然这些隔离技术辅助实现了容器间的隔离，但也带来了资源可用量与资源限制之间的语义鸿沟。一方面，系统管理员只分配部分的主机资源给单个容器，容器只能访问分配给它的有限资源；但另一方面，由于缺乏硬件抽象层，容器却能观察到主机的总资源量。这个语义鸿沟导致许多应用在容器中的运行异常。通过对Dockerhub (Docker官方镜像仓库)的Top 100镜像进行分析，作者发现有超过60%的应用镜像都受到了这个语义鸿沟的影响，它使得应用性能大幅下降，甚至可能会导致程序崩溃。

设计与实现

图3. 系统架构

本工作的设计目标是消除容器中应用观察到的资源可用量与实际资源可用量间的语义鸿沟，并且构建弹性应用去适应动态变化的资源可用量。主要贡献包括以下四点。

首先，为了处理容器中的语义鸿沟，作者设计实现了容器间相互隔离的实时资源视图，该资源视图不断更新以实时反映容器的有效资源。如图3所示，系统主要包含3个部分：1）sys_namespace，维护容器的有效资源量（CPU和内存）；2）虚拟sysfs，提供连接sys_namespace和应用程序的接口；3）Ns_Monitor，追踪Cgroups的改变并更新相对应的sys_namespace。

其次，设计了容器有效CPU资源的计算方法和动态调整机制。已有研究表明，相比于大量线程在许多CPU上相互竞争，让这些线程分别在少量专用CPU上执行更加高效，这也是为每个容器提供“有效”CPU资源量的意义所在。有效的CPU资源而不是大量竞争中的CPU资源可以让应用高效调整其并行度。

第三，设计了容器有效内存资源的计算方法和动态调整机制。一个容器的有效内存总是在Hard limit与Soft limit之间。作者采取启发式的算法，通过预测增加容器有效内存后对主机系统内存的影响，来逐步地增加容器的有效内存。当监控到主机系统内存紧张，全局内存回收启动后，容器的有效内存则会降低到Soft limit，防止过多的swapping影响应用性能。

第四，设计并验证了容器中弹性应用的构建方法。通过JVM和OpenMP两个案例，作者说明了如何在容器中构建弹性应用，通过容器私有资源视图提供的有效CPU和内存资源信息来动态调整应用配置，从而在资源动态竞争的容器环境下保持和提高应用性能。