导读:OpenCloudOS 社区是由操作系统、软硬件厂商与个人共同倡议发起的操作系统社区项目,提供自主可控、绿色节能、安全可靠、高性能的下一代云原生操作系统,与生态伙伴一起打造中立的操作系统开源生态。 作为社区重要的技术方向,OpenCloudOS 社区的云原生操作系统自研了一系列的云原生特性,本文主要介绍 CgroupFS 和 SLI。
容器的隔离主要是依赖 Linux 操作系统的 Namespace 和 Cgroup,与依赖硬件辅助虚拟化的虚拟机隔离不同,前者存在不少隔离漏洞。随着云原生场景的大规模使用,大量应用的容器化暴露出了容器隔离性问题。
特别是 /proc、/sys 文件系统中的一些资源统计信息,还没有完全的容器化,导致在物理机/虚拟机中的一些常用命令(比如 free/top)在容器中运行时,不能准确展示容器视角的信息,而是展示系统级别的全局信息。对于依赖这些系统信息运行的容器化应用,可能导致错误的运行结果甚至无法运行。
业界目前普遍采用 lxcfs 的方案解决容器隔离漏洞问题。但是 lxcfs 方案有其固有的缺陷:
1)需要依赖额外的组件 lxcfs;
2)lxcfs 在用户态基于 FUSE 实现,开销相比内核更大;
3)lxcfs 稳定性比较差,可能在容器的生命周期状态切换时触发 hang、信息获取不到等问题。
为缓减全局影响,高稳场景会设置每pod对应一个 lxcfs 服务进程
CgroupFS 方案基于内核态实现,其核心设计为,设计一个新的虚拟文件系统,其中包含需要实现的容器视角的 /proc、/sys 等 fs,其目录结构保持与全局 procfs 和 sysfs 一致,以保证对于用户工具的兼容性。实际读取相关文件时,通过 CgroupFS 的读者进程的上下文来动态生成对应的容器信息视图。
以下内容基于 OpenCloudOS LTS 分支:
https://github.com/OpenCloudOS/OpenCloudOS-Kernel/commits/lts/5.4.119-20.0009
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 总数信息
在云原生场景大量应用运行都在容器化。但在高资源利用率场景下,容器也会存在问题。例如:容器间的互相干扰,容器资源限制引起的性能抖动等问题。目前 Linux 的系统性能指标,要么是基于进程级别的统计数据,要么就是基于全局的统计数据,这些都无法直观、有效的反应容器级别的性能问题。
OpenCloudOS 社区中的容器级别的性能跟踪机制——SLI,从容器的角度对 CPU、内存资源的竞争情况进行跟踪、观测,从而为容器性能问题的定位、分析提供可靠的指标。
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,确保循环使用而不会溢出。
SLI 特性 | 特性描述 |
---|---|
用户态周期性采集 | SLI 通过 Cgroup 接口提供容器的性能数据,用户态可以通过这些数据对容器性能进行监控。 |
mbuf 问题定位 | SLI 可以将问题发生时的内核栈信息打印到 mbuf 内存里,从而帮助用户定位性能问题的原因。 |
方案监控指标
监控指标 | 指标描述 | 指标意义 |
---|---|---|
容器内负载情况监控 | 容器内处于 R/D 态的进程平均数量(分别是 1min、5min、15min 的容器平均负载) | R 进程数量指标:评估容器内进程数量是否 overloadD进程数量指标:D状态进程的数量可以反馈IO等待以及锁竞争等的情况 |
进程在内核态执行时间 | 监控容器进程在内核态的执行时间。 | 内核态时间可能是因为系统调用、中断或者缺页异常等原因引起的。内核态的执行时间过长,会导致用户业务有较大延迟,从而引起性能抖动问题。 |
调度延迟 | 监控容器进程的调度延迟信息(容器进程在调度队列上的等待时间) | 反馈容器的 CPU 竞争情况,过大的调度延迟会导致业务出现性能抖动。 |
iowait 延迟 | 监控容器进程的 IO 等待延迟信息(进程 IO 完成而引起的延迟时间) | 反馈容器进程的 IO 性能问题,过大的 IO 延迟会让业务文件访问产生性能问题 |
内存延迟 | 监控容器进程的内存申请延迟信息 | 反馈容器的内存申请性能情况,过大的内存申请延迟会导致业务出现性能抖动。 |
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 社区感兴趣,欢迎关注“OpenCloudOS”公众号,了解最新动态。