CGroups 以及在 K8s 中的应用 - 内存

c group s（ control groups ， 控制组群 ） 是 Linux 内核的一个功能，用来限制、控制与分离一个进程组的资源（如CPU、内存、磁盘输入输出等）。它是由 Google 的两位工程师进行开发的，自 2008 年 1 月正式发布的 Linux 内核 v2.6.24 开始提供此能力。 cgroup s到目前为止，有两个大版本， 即 v1 和 v2 。

cgroups 可以限制、记录、隔离进程组所使用的物理资源（包括： CPU 、 memory 、 IO 等），为容器实现虚拟化提供了基本保证，是构建 docker 、 containerd 、 ku bernetes 等一系列容器服务的基石。

上一节中，我们对一些基本概念进行了介绍，本节我们针对 cgroups 对内存资源的限制进行简单的测试。

作者：董卫国，中国移动云能力中心软件研发工程师，专注于云原生领域。

cgroups  v1 版本测试

我们当前的测试环境为 centos 7.9  ，内核为  5.4 版本，如下所示：

cgoups资源限制测试

创建一个名为 test 01 的 cgroups 组，并对内存进行资源限制，如下所示

现在我们对当前会话限制了 1 00 M 的内存，然后我们 在网上找到了 一个 c 函数 ， 用来测试 内存 申请的效果 ，如下所示

编译执行，测试如下：

可以看到申请超过甚至接近 1 00 M 内存的时候，都容易 发生 OOM ，说明 cgroups 起到了限制内存使用的作用，查看 /var /log/message 中可以看到对应的日志信息，如下所示：

我们申请了 1 00 M 内存，为什么只能用到不到 9 8 M 呢，我们查看内存统计值

查看统计值发现 cache和rss仅使用了9 7 M 多一点，这基本符合我们的预期，但是剩下的内存去哪儿了？进一步查阅文献我们知道，还有一部分内存使用统计在 memory.kmem.usage_in_bytes（显示当前内核内存用量） ，而没有统计到 memory.stat ，查看结果，如下所示：

可以看到除了 9 7 M 程序运行使用的内存，还有 2M 内核多内核使用的内存，怪不得使用 9 8 M 内存时会触发 OOM 。这样一来，事情就基本符合我们的预期了。

K u bernets 中的资源限制

我们尝试 在 Kubernetes 中启动一个 deploy ment ， 启动后登录到节点上查看 pod 的内存资源是如何被限制的 。

下面 的测试是使用 sealos 部署的 v1.25.9 版本的 Kubernetes 进行的。

P od 变为 Running 状态后，登录到 Pod 所在节点执行如下 shell 命令查看容器 cgroupstest 的内存限制

容器的资源限制如下所示

下面我们进一步查看限制效果，查看容器 cgroupstest 的内存限制

可以看到结果如下

可以看到当前容器 cgroupstest 的内存限制为 1 28 M 。

cgroups  v 2 版本测试

简单 测试使用 c groups v2

创建一个名为 test 01 的 cgroup s 组，并对内存进行资源限制，如下所示

上面的 shell 命令，我们对这个 shell 限制了 1 00 M 的内存。

使用前面测试 v 1 版本的 cg roups 时候引入 c 函数申请内存，编译执行，测试如下：

可以看到当前申请 9 7 M 内存时，就会触发 oom ， cgroups   v2 版本可以通过查看  memory.current  文件统计当前的内存使用。

kubernetes中 基于 cgroups   v2 的 Me mory Qos

K ub ernetes提供QoS（Quality of Service，服务质量）服务质量管理，基于每个 Pod 中容器的资源请求和限制为 Pod 设置 QoS 类 ，并依赖 QoS 类来决定从遇到 节点压力 的 Node 中驱逐哪些 Pod。可选的 QoS 类有 Guaranteed、Burstable 和 BestEffort。 当一个 Node 耗尽资源时，Kubernetes 将首先驱逐在该 Node 上运行的 BestEffort Pod， 然后是 Burstable Pod，最后是 Guaranteed Pod。当这种驱逐是由于资源压力时， 只有超出资源请求的 Pod 才是被驱逐的候选对象。

下面对各级别分别进行相应说明：

Guaranteed ：pod中的所有容器都必须对cpu和memory同时设置limits，如果有一个容器要设置requests，那么所有容器都要设置，并设置参数同limits一致，那么这个pod的QoS就是Guaranteed级别。注：如果一个容器只指明limit而未设定request，则request的值等于limit值。

Burstable : pod中只要有一个容器的requests和limits的设置不相同，该pod的QoS即为Burstable。

BestEffort ：如果对于全部的resources来说requests与limits均未设置，该pod的QoS即为BestEffort。

Memory QoS 是 Kubernetes 在新版本里基于 cgroup v2 实现的新特性，这个特性始于 1 .22 版本，至今仍属于 Alpha 版本。该特性本质上还是封装 cgroup v2 的能力，来提供更加弹性的内存管理。 cgroups v1 实现 了  CPU 和 Memory 隔离 ， CPU 属于可压缩资源，在节点 CPU 紧张时，任务只会 受到限制（ throttl e ） ，不至于被 kill。但 Memory  属于 不可压缩资源，在节点内存不足时会触发 OOM ，导致容器重启，可是 这对部分 Burstable Pod 是不可接受的。而且某些内存消耗型 Pod 在创建和运行中会短时申请大量内存，导致节点内存瞬间飙升 ， 节点内存紧张可能会导致内存高敏 Pod 在申请内存时 存在问题 ，从而影响服务质量。cgroups v1 无法解决此类 Memory QoS 问题。但幸运的是，cgroups v2  的 memory controller 为我们提供了参数 减缓此问题 。

我们 回顾 下 cgroup v2 中内存 限制 的配置项， cgroups  v2 一共有如下四种内存分配和保护实现（即 4 个可修改的文件）：

Ø memory.min ：内存的硬保护机制，这是当前 cgroups 必须保留的最小内存分配，在任何情况下都不会回收这块内存。如果满足不了 memory.min 的内存分配，系统会触发 OOM 。

Ø memory.low ：是一种 BestEffort 的内存保护机制，是一种软保护实现，也即不能保证这块内存一定不被回收。当无法从其他未受保护的 cgroups 中回收内存时，会回收这块的内存。

Ø memory.high ：内存使用的瓶颈限制，系统会尝试将 cgroups 内存使用率控制在此阈值之下，而并不是直接 OOM Kill 。这样的设计就非常适合一些 Memory Burst 的场景，可以像 CPU 一样做一定程度的资源压缩。

Ø memory.max ：内存使用的最大限制，如果 cgroups 内存使用达到这个值，会触发 OOM 。

可以看到通过设置 memory.high   的值，我们可以环节一些特殊场景下的节点内存压力， 我们需要在kubelet中加入如下启动参数，才可以启用 Memory QoS 的机制：

--feature-gates=MemoryQoS=true  

在这里多提一下，我们上面的测试中一直使用centos7升级内核和systemd的方式使其支持cgroups v2，但是这里开启此特性后，测试后pod无法启动，报错如下

同样的 ku bernets 和容器运行时版本，更换 ubuntu  22  和  rockylinux8 测试，都能正常启动服务进行测试，前面我们将 systemd 升级到了 2 34 版本，但还不够高， docker 的官方文档中推荐使用 2 47 版本以上，也许 是 systemd 或者其他软件包版本的影响，笔者这里没有在 centos 7 上进一步的尝试，此处的测试使用 rockylinux8 （内核版本 4 .18 ）。

我们启动一个 deploy ment ，配置资源申请如下所示：

登录到 pod 所在节点查看该 pod 包含的容器内存限制如下所示：

可以看到，此处容器的内存最大值 memory.max 为 1 28 M ，即内存的 limit 值，最小值 memory.min 为 60 M ，即内存的 request 值。

me mory . hgih 的计算公式如下：

如 limit 没有设置，则按照如下公式得出

此时配置的 memory . high 为 102 M ，是内存 limit 的 0 .8 ，符合预期。上面的 memory thrittling factor 值通过 kube let config 中的 memoryThrottlingFactor 参数配置。

总结

本文对 cgroups   v1 和 v2 版本 对内存资源的限制 进行了介绍和基础功能的验证，并对其在 Kubernetes 中的使用进行了一些初步的调研。

对于 Kubernetes 中的 QoS 设计，本文也未能进一步的进行了解和学习， Kubernetes 根据服务或者说 pod 的资源请求进行调度，使用 cgroups 进行 pod 占用资源的约束，根据 QoS 等级提供服务质量保障。在笔者的理解里， Qo S 是目标， cgroups 只是其中的一种工具。

最后，由于笔者能力和时间所限，难免存在一些错漏，也缺乏对一些功能的源码级分析，对于不同系统和内核版本在不同硬件和参数配置下对不同资源类型的测试也存在不充分的地方，还请谅解。

参考

1) 一篇搞懂容器技术的基石： cgroup , https://zhuanlan.zhihu.com/p/434731896

2) Linux cgroups ：深入理解 cgroups v1 版本 ,  https://www.testerfans.com/archives/linux-cgroups-learn-more

3) Linux CFS and task group ,  https://mechpen.github.io/posts/2020-04-27-cfs-group/index.html

4) 深入理解 Kubernetes 资源限制：CPU ,  https://icloudnative.io/posts/understanding-resource-limits-in-kubernetes-cpu-time/

5) CFS Bandwidth Control ， https://www.kernel.org/doc/html/v5.4/scheduler/sched-bwc.html?highlight=cpu%20cfs_quota_us

6) Cgroup 详解 ， https://juejin.cn/post/6921299245685276686

7) Cgroup 限制内存与节点的删除 ， https://chaochaogege.com/2019/09/11/6/

8) 容器内存分析 ， https://blog.csdn.net/u012986012/article/details/105291831

9) 控制组详解 ， https://blog.gmem.cc/cgroup-illustrated

10) Cgroup V2 and writeback support ， http://hustcat.github.io/cgroup-v2-and-writeback-support/

11) Linux CGroup  基础 ， https://wudaijun.com/2018/10/linux-cgroup/

12) 详解 Cgroup V2 ， https://zorrozou.github.io/docs/%E8%AF%A6%E8%A7%A3Cgroup%20V2.html

13) centos 7  升级  systemd ， https://lqingcloud.cn/post/systemd-01/

14) 容器 -cgroup-blkio-cgroup ， http://119.23.219.145/posts/%E5%AE%B9%E5%99%A8-cgroup-blkio-cgroup/

15) 打通 IO 栈：一次编译服务器性能优化实战 , https://mp.weixin.qq.com/s?__biz=Mzg2OTc0ODAzMw==&mid=2247502495&idx=1&sn=26950b22cba383b14052b441cd356516&source=41#wechat_redirect

16) pod 资源限制和 QoS 探索 ,  https://www.zerchin.xyz/2021/01/31/pod%E8%B5%84%E6%BA%90%E9%99%90%E5%88%B6%E5%92%8CQoS%E6%8E%A2%E7%B4%A2/

点击【阅读原文】到达  Kubernetes  网站。