Linux控制组以及进程隔离 - 编程语言应用

TUhjnbcbe - 2021/4/9 7:25:00

　　　　　　　　　　作者｜ERICBROWN　　　　　　译者丨薛命灯　　

Fuchsia是谷歌开发的一个操作系统，这是一个差不多从头研发的新系统。年8月，Fuchsia的开发新闻在技术新闻网站上引发了轰动，不过很多细节依旧成谜。

Fuchsia是一个开源项目，无论开发工作还是相关的文档都还在持续完善中，除了该项目为开源之外，谷歌并未透露更多信息，包括其真正用途。根据零散分布在网上的文档、源码等信息，我们可以推测：Fuchsia是一个专为PC、平板电脑及高端手机所开发的一套完整的操作系统。

近日，FuchsiaOS增加了一个用于运行DebianLinux应用程序的模拟器。与即将推出的适用于ChromeOS的Linux模拟器一样，相比传统的模拟器，Fuchsia的“Guest”App与宿主操作系统集成得更加紧密。

谷歌已经为开源的FuchsiaOS添加了一个GuestApp，让Linux应用程序可以在Fuchsia中作为虚拟机（VM）运行。这个GuestApp使用了一个叫作Machina的库，相比传统的模拟器，GuestApp与宿主操作系统的集成更加紧密。

上个月，谷歌宣布推出Crostini，让Chromebook用户更容易在ChromeOS虚拟机中运行主流的Linux应用程序。本周，宏碁宣布ChromebookFlipC将在今年晚些时候提供Linux支持，是少数支持Linux应用程序的Chromebook之一。

除了支持Android，ChromeOS很快也将支持Linux应用程序，尽管这有点让人喜出望外，但却算不上大惊喜。毕竟，Android和ChromeOS都是基于Linux的。而在年推出Fuchsia时，谷歌就首先强调，Fuchsia不是基于Linux内核的。

对于有些人来说，Linux不仅是Android和ChromeOS的基础，也是谷歌企业平台的基础，所以Fuchsia似乎是一种“背叛”。这就好比说，当几乎每个人都在共享一个通用的Linux基础时，为什么要添加另一个Windows或iOS？

毫无疑问，谷歌有一些非常好的理由要避免使用Linux。一个原因可能是Linux“年纪太大”，太复杂了。如果从头开始做一个东西，谷歌就可以避开这些问题，使用更优雅的代码，给黑客留下最少的可乘之机。谷歌还将安全更新深植到操作系统中，通过隔离应用程序让它们无法直接访问系统内核，这一点与Linux是不一样的。

早在年，我们认为谷歌可能会将Fuchsia作为一个私有操作系统，就像苹果公司将iOS的一切牢牢控制在手中一样。尽管不排除这个可能性，但至少现在Fuchsia仍然是一个开源项目。

有些人还推测，谷歌因为无法在微处理器（MCU）领域扩大规模而绕过了Linux。然而，基于MCU的物联网似乎并不是目前Fuchisa

TUhjnbcbe - 2021/4/9 7:25:00

这是关于Linux容器介绍的第一篇，主要介绍了Linux控制组：controlgroups，也叫做CGroups，以及进程隔离。通过一个简单的例子让你很快学习到Linux控制组是如何工作的。以及哪些库可以让你方便快捷的使用控制组。每个人都听说过容器，那么容器到底是什么呢？软件的发展使这项技术以多种方式得以实现，而Docker则是最流行的一种。因为容器的可移植性以及它隔离工作环境的特点可以限制它对底层计算的影响以及影响范围，越来越多数据中心开始采用这项技术。为了全面了解这项技术，你首先需要了解是哪些技术实现了容器。附注：人们总喜欢问容器和虚拟机的区别。它们都有各自特定的目的，并没有太多相似的地方。并且一个并不会淘汰掉另一个。一个容器指的是一个轻量级的环境，在这个环境中你可以启动一个或者多个应用，它们都与外界隔离，并且这个环境的性能与裸机相当。但如果你需要运行一整个操作系统或者生态系统，又或者你需要运行与底层环境不兼容的应用程序，那么你需要选择虚拟机。Linux控制组说实话，一些未知的软件应用可能需要被控制或限制——至少是为了稳定性或者某种程度上的安全性。很多时候，一个bug或者仅仅只是烂代码就有可能破坏掉整个机器甚至可能削弱整个生态。幸运的是，有一种方式可以控制相同的应用程序，Linux控制组（cgroups）是一个内核功能，用于限制，记录和隔离一个或多个进程对CPU，内存，磁盘I/O，以及网络的使用量及访问。控制组技术最初是由谷歌开发的，最终在2.6.24版本（年1月）中并入Linux内核主线。这项技术被部分重新设计，添加了kernfs（用于分割一些sysfs逻辑），这些改变被合并到3.15和3.16版本的内核中。控制组主要为了提供统一接口来管理进程或者整个操作系统级别的虚拟化，包括Linux容器，或者LXC（将在之后的文章中详细介绍这项技术）。控制组框架提供了以下功能：

资源限制：一个控制组可以配置成不能超过指定的内存限制或是不能使用超过一定数量的处理器或限制使用特定的外围设备。

优先级：一个或者多个控制组可以配置成使用更少或者更多的CPU或者磁盘I/O吞吐量。

记录：一个控制组的资源使用情况会被监督以及测量。

控制：进程组可以被冻结，暂停或者重启。

一个控制组可以包含一个或者多个进程，这些进程将全部绑定于同一组限制。控制组也可以继承，这意味着一个子组可以继承其父组限制。Linux内核为控制组技术的一系列控制器以及子系统提供了访问。控制器将负责将特定类型的系统资源分配给一个控制组（包含一个或者多个进程）。例如，内存控制器会限制内存使用而cpuacct控制器会监控CPU的使用情况。你可以直接或者间接（通过LXC，libvirt或者Docker）访问及管理控制组，这里我首先介绍使用sysfs以及libgroups库。接下来的示例需要你预先安装一个必须的包。在RedHatEnterpriseLinux或者CentOS里面，在命令行输入以下命令：

$sudoyuminstalllibcgrouplibcgroup-tools

如果是Ubuntu或者Debian，输入：

$sudoapt-getinstalllibcgroup1cgroup-tools

我将使用一个简单的shell脚本文件test.sh作为示例应用程序，它将会在无限while循环中运行以下两个命令。

$cattest.sh

#!/bin/sh

while[1];do

echo"helloworld"

sleep60

done

手动方法安装必要的包后，你可以直接通过sysfs的目录结构来配置你的控制组，例如，要在内存子系统中创建一个叫做foo的控制组，只需要在/sys/fs/cgroup/memory底下新建一个叫做foo的目录：

$sudomkdir/sys/fs/cgroup/memory/foo

默认情况下，每个新建的控制组将会继承对系统整个内存池的访问权限。但对于某些应用程序，这些程序拒绝释放已分配的内存并继续分配更多内存，这种默认继承方式显然不是个好主意。要使程序的内存限制变得更为合理，你需要更新文件memory.limit_in_bytes。限制控制组foo下运行的任何应用的内存上限为50MB：

$echo

sudotee

?/sys/fs/cgroup/memory/foo/memory.limit_in_bytes}}}

验证设置：

{{{$sudocatmemory.limit_in_bytes

请注意，回读的值始终是内核页面大小的倍数（即字节或4KB）。这个值是内存的最小可分配大小。启动应用程序test.sh：

$sh~/test.sh

使用进程ID（PID），将应用程序移动到内存控制器底下的控制组foo：

$echo/sys/fs/cgroup/memory/foo/cgroup.procs

使用相同的PID，列出正在运行的进程并验证它是否在正确的控制组下运行：

$ps-ocgroup

CGROUP

8:memory:/foo,1:name=systemd:/user.slice/user-0.slice/

?session-4.scope

你还可以通过读取文件来监控控制组正在使用的资源。在这种情况下，你可以查看你的进程（以及生成的子进程）被分配的内存大小。

$cat/sys/fs/cgroup/memory/foo/memory.usage_in_bytes

当进程“迷路”时现在让我们重新创建相同的场景，但这次我们将控制组foo的内存限制从50MB改为bytes：

$echo

sudotee/sys/fs/cgroup/memory/foo/

?memory.limit_in_bytes

注意：如果任务超出其定义的限制，内核将进行干预，并在某些情况下终止该任务。同样，当您重新读取值时，它将始终是内核页面大小的倍数。因此，虽然您将其设置为字节，但它实际上被设置为4KB：

$cat/sys/fs/cgroup/memory/foo/memory.limit_in_bytes

启动应用程序test.sh，将其移动到控制组下并监视系统日志：

$sudotail-f/var/log/messages

Oct:22:40localhostkernel:shinvokedoom-killer:

?gfp_mask=0xd0,order=0,oom_score_adj=0

Oct:22:40localhostkernel:shcpuset=/mems_allowed=0

Oct:22:40localhostkernel:CPU:0PID:Comm:

?shTainted:G

OE------------3.10.0-.36.3.el7.x86_64#1

Oct:22:40localhostkernel:Hardwarename:innotekGmbH

VirtualBox/VirtualBox,BIOSVirtualBox12/01/

Oct:22:40localhostkernel:ffffea5c00

?ffffbcd0ffffffff

Oct:22:40localhostkernel:ffffbd60

?ffffffffcc00d0ffffbd68

Oct:22:40localhostkernel:ffffffffbc35e

?fffeefffffffea

Oct:22:40localhostkernel:CallTrace:

Oct:22:40localhostkernel:[ffffffff]

?dump_stack+0x19/0x1b

Oct:22:40localhostkernel:[ffffffffcc]

?dump_header+0x8e/0x

Oct:22:40localhostkernel:[ffffffffd21e]

?oom_kill_process+0x24e/0x3b0

Oct:22:40localhostkernel:[ffffffffe4e]?

?has_capability_noaudit+0x1e/0x30

Oct:22:40localhostkernel:[ffffffffd]

?mem_cgroup_oom_synchronize+0x/0x5a0

Oct:22:40localhostkernel:[ffffffffd]?

?mem_cgroup_charge_