云原生场景下，如何缓减容器隔离漏洞，监控内核关键路径？

导读：OpenCloudOS 社区是由操作系统、软硬件厂商与个人共同倡议发起的操作系统社区项目，提供自主可控、绿色节能、安全可靠、高性能的下一代云原生操作系统，与生态伙伴一起打造中立的操作系统开源生态。作为社区重要的技术方向，OpenCloudOS 社区的云原生操作系统自研了一系列的云原生特性，本文主要介绍 CgroupFS 和 SLI。

一、CgroupFS 特性

1、方案背景

容器的隔离主要是依赖 Linux 操作系统的 Namespace 和 Cgroup，与依赖硬件辅助虚拟化的虚拟机隔离不同，前者存在不少隔离漏洞。随着云原生场景的大规模使用，大量应用的容器化暴露出了容器隔离性问题。

特别是 /proc、/sys 文件系统中的一些资源统计信息，还没有完全的容器化，导致在物理机/虚拟机中的一些常用命令（比如 free/top）在容器中运行时，不能准确展示容器视角的信息，而是展示系统级别的全局信息。对于依赖这些系统信息运行的容器化应用，可能导致错误的运行结果甚至无法运行。

2、方案探索

业界目前普遍采用 lxcfs 的方案解决容器隔离漏洞问题。但是 lxcfs 方案有其固有的缺陷：

1）需要依赖额外的组件 lxcfs；

2）lxcfs 在用户态基于 FUSE 实现，开销相比内核更大；

3）lxcfs 稳定性比较差，可能在容器的生命周期状态切换时触发 hang、信息获取不到等问题。

每个 container 都需要对应一个 lxcfs 服务进程

3、方案实现

CgroupFS 方案基于内核态实现，其核心设计为，设计一个新的虚拟文件系统，其中包含需要实现的容器视角的 /proc、/sys 等 fs，其目录结构保持与全局 procfs 和 sysfs 一致，以保证对于用户工具的兼容性。实际读取相关文件时，通过 CgroupFS 的读者进程的上下文来动态生成对应的容器信息视图。以下内容基于 OpenCloudOS LTS 分支：

https://github.com/OpenCloudOS/OpenCloudOS-Kernel/commits/lts/5.4.119-20.0009

4、方案实现效果

1）创建挂载点目录 /cgroupfs挂载 cgroupfs：

mount -t cgroupfs cgroupfs /cgroupfs/

2）容器启动命令如下：

docker run -itd --cpus 2 --cpuset-cpus 2,4 --memory="512m" --memory-swap="1g" 
-v /cgroupfs/sys/devices/system/cpu/:/sys/devices/system/cpu 
-v /cgroupfs/proc/cpuinfo:/proc/cpuinfo 
-v /cgroupfs/proc/stat:/proc/stat 
-v /cgroupfs/proc/meminfo:/proc/meminfo 
image-id /bin/bash

容器启动后，会将 cgroupfs 下的文件 bind mount 到容器中对应位置。

3）运行实例

开启 CgroupFS 后，在容器中执行常用命令的效果：（容器规格：2 CPU，限定可用内存 512M，可用内存和可用 swap 总计 1G）容器内 proc 文件系统下显示 CPU 信息：

容器内 free 命令显示内存信息：

容器内 top 命令显示 CPU 个数信息：：

容器内 nproc 显示 CPU 总数信息

二、SLI 特性

1、方案背景

在云原生场景大量应用运行都在容器化。但在高资源利用率场景下，容器也会存在问题。例如：容器间的互相干扰，容器资源限制引起的性能抖动等问题。目前 Linux 的系统性能指标，要么是基于进程级别的统计数据，要么就是基于全局的统计数据，这些都无法直观、有效的反应容器级别的性能问题。

OpenCloudOS 社区中的容器级别的性能跟踪机制——SLI，从容器的角度对 CPU、内存资源的竞争情况进行跟踪、观测，从而为容器性能问题的定位、分析提供可靠的指标。

2、方案探索

SLI 方案选择	优点	缺点
内核原生实现	1、在内核里实现，跟踪开销最小，性能最优。2、可以调用内核所有接口，功能开发不会被制约。	1、扩展性较差。2、开发、部署周期较长（涉及到内核升级或者热补丁替换）
eBPF	1、扩展性较好，可以根据需要动态的修改 eBPF 代码。2、开发、部署周期短，开发难度相对简单	1、eBPF 代码有较多安全检查，这会引入较大的开销，从而导致跟踪性能开销较大。2、eBPF 对调用接口有严格的限制，导致很多内核接口函数无法调用，会严重制约功能开发。

SLI 是一个常态化性能跟踪机制，需要对很多内核热点函数进行跟踪，这就要求 SLI 的实现必须是低开销的。此外，SLI 会使用很多内核核心函数，这些函数都无法被 eBPF 调用到。所以经过权衡，我们决定在内核里实现 SLI 机制，从而实现跟踪性能开销的最小化。

mbuf 特性

容器场景下，各个容器是相互独立的应用程序。由于不同容器在运行过程中，各自的资源使用情况、运行情况都不同，需要有一个独立的地方记录不同容器内核层面的异常日志信息，上层应用可以根据日志信息，直接定位到对应容器，从而进行合理的调度等操作；mbuf 就应运而生。事实上，mbuf 不仅仅可以应用在容器环境里，内核其他模块也可以根据自己的需求按照 mbuf 规范进行使用；

mbuf 的实现

1）内核启动时申请预留一段内存，该内存在伙伴系统之外。

2）设置支持最大的 items 数量；每个 item 是 mbuf 的使用单位，其本身会维护一个 ring 作为 ring buffer，确保循环使用而不会溢出。

3、方案实现

SLI 特性	特性描述
用户态周期性采集	SLI 通过 Cgroup 接口提供容器的性能数据，用户态可以通过这些数据对容器性能进行监控。
mbuf 问题定位	SLI 可以将问题发生时的内核栈信息打印到 mbuf 内存里，从而帮助用户定位性能问题的原因。

方案监控指标

监控指标	指标描述	指标意义
容器内负载情况监控	容器内处于 R/D 态的进程平均数量（分别是 1min、5min、15min 的容器平均负载）	R 进程数量指标：评估容器内进程数量是否 overloadD进程数量指标：D状态进程的数量可以反馈IO等待以及锁竞争等的情况
进程在内核态执行时间	监控容器进程在内核态的执行时间。	内核态时间可能是因为系统调用、中断或者缺页异常等原因引起的。内核态的执行时间过长，会导致用户业务有较大延迟，从而引起性能抖动问题。
调度延迟	监控容器进程的调度延迟信息（容器进程在调度队列上的等待时间）	反馈容器的 CPU 竞争情况，过大的调度延迟会导致业务出现性能抖动。
iowait 延迟	监控容器进程的 IO 等待延迟信息（进程 IO 完成而引起的延迟时间）	反馈容器进程的 IO 性能问题，过大的 IO 延迟会让业务文件访问产生性能问题
内存延迟	监控容器进程的内存申请延迟信息	反馈容器的内存申请性能情况，过大的内存申请延迟会导致业务出现性能抖动。

4、方案效果

1）开启 SLI 的方式：

echo 1> /proc/sli/sli_enabled

2）用户态周期性采集使用方式

监控指标	访问方式
容器内负载情况监控	/sys/fs/cgroup/cpuset/<Pod A>/cpuset.loadavg
进程在内核态执行时间	/sys/fs/cgroup/cpuacct/<Pod A>/cpuacct.sli对应其中的 schedlat_longsys 项
调度延迟	/sys/fs/cgroup/cpuacct/<Pod A>/cpuacct.sli对应其中的schedlat_rundelay项
iowait延迟	/sys/fs/cgroup/cpuacct/<Pod A>/cpuacct.sli对应其中的schedlat_ioblock项
内存延迟	/sys/fs/cgroup/memory/<Pod A>/memory.sli

3）mbuf 问题定位数据采集方式

需要首先使能 mbuf：

echo 1 > /proc/sys/kernel/qos_mbuf_enable

触发堆栈保存到 mbuf 的阈值设置

监控指标	阈值设置
进程在内核态执行时间	延迟阈值设置文件：/proc/sli/sched_latency_threshold例如：echo "schedlat_longsys_thr=4" > /proc/sli/sched_latency_threshold
调度延迟	延迟阈值设置文件：/proc/sli/sched_latency_threshold例如：echo "schedlat_rundelay_thr=24" > /proc/sli/sched_latency_threshold
iowait延迟	延迟阈值设置文件：/proc/sli/sched_latency_threshold例如：echo "schedlat_ioblock_thr=16" > /proc/sli/sched_latency_threshold
内存延迟	内存延迟阈值设置文件：/proc/sli/memory_latency_threshold例如：echo "page_alloc_threshold=24" > /proc/sli/memory_latency_threshold

获取 mbuf 中的堆栈信息：

cat /sys/fs/cgroup/cpuacct/<Pod A>/cpuacct.mbuf

4）SLI 应用实例

下图是使用 SLI 监控 redis 容器内存干扰采集的数据。

从测试数据来看，每次直接回收的延时，都会对应一次 redis 的抖动。

三、小结

通过 OpenCloudOS 容器引擎内核支撑技术的全景图，可以看到 CgroupFS 和 SLI 都是重要的模块。

欢迎扫描下方二维码，加入社区用户群，了解 OpenCloudOS 最新动态，获取技术相关的支持，分享交流使用体验。