谢仲天-TencentOS Server云原生技术实践v2-p

1 .TencentOS Server云原生技术实践 2022.7.15 腾讯云OS团队 

2 . 1. 腾讯OS技术积累 2. TencentOS云原生网络实践 目录 3. TencentOS RUE(如意) 4. TencentOS 悟净 5. 其他云原生特性 6. 下一代云原生操作系统(全栈国产化) 

3 .01 腾讯OS技术积累 12年磨一剑 

4 .TencentOS Server简介：十年积累，千万节点 TencentOS Server自2010年研发，历经10+年技术积累，自研内核核心技术，系统全面优化，支持国产主流硬件平台；商用节 点数达1000万级，支撑12大行业客户核心系统，经历海量场景考验 2010年 开始研发，10+年积累 1000万 规模超千万，行业领先 99.999% 可用性5个9，满足企业级要求 自主研发时代 创新研发时代 自主研发运营、持续打磨 向外生长、社区生态、技术引领 2010年 2011年 2016年 2019年 2020年 2021年 2022年 开始自主研发 发布第一个版本TS1 发布TS2 发布TS3 私有化场景拓展 OpenCloudOS社区成立 规模1000万 代替外购SUSE 精简内核 自研覆盖99% 输出到公有云客户：80% TS3，5.4内核打磨成熟 打造生态、引领核心技术 稳定性/性能提升 支撑微信、QQ、 覆盖率 实现开源和商业的闭环 新硬件支持 游戏等核心业务 对外开源 新技术引进 功能定制 持续运营打磨 

5 . Tencent Server云原生能力总览 统一资源隔离(RUE) CPU隔离、内存隔离、IO隔离、网络隔离 解决不同优先级容器之前的隔离性问题，保障 稳定性/性能/降本增效 高优先级容器的服务质量 Ebpf/Cilium全面支持 容器网络跟踪系统 性能、灵活性、安全性 可维护性 Cillium是新一代的K8s网络插件，依赖内核ebpf。内核关 复杂云原生网络架构下，网络包的全生命周期跟踪、诊断工具 键特性ebpf全量支持，全面支持cilium新特性 容器可视化能力增强(云原生SLI) qGPU(GPU隔离和共享) 可维护性 云原生内核(基于5.4) 降本增效(GPU) 通过OS层的黑科技，分时复用GPU资源(GPU和显存)， 容器级别的专业监控指标；黑匣子常态化 运行，捕捉随机异常抖动业界难题；异常 云原生服务能力行业领先 提升GPU资源利用率 主动上报，提供毫秒级响应 CPU弹性调度 内存分级卸载(悟净) 降本增效 降本增效 通过对业务压力自适应画像，对内存做动态的冷热分级 解决突发流量导致资源浪费问题，降低容器的 回收利用，在保证业务服务质量的情况下，降低整机的 CPU资源申请，降低成本 内存消耗 容器资源视图隔离 高可用云原生网络 可用性 可靠性 容器化全局资源，解决富容器场景下的业务可 MPTCP (mutipath tcp) 链路故障failover - 多路径TCP 用性问题 & 交换机ECMP算法 

6 .02 云原生网络实践 • Cillium支持/Ebpf支持 • 网络包全链路跟踪和诊断工具集 • 安全容器网络和优化 • 高稳网络 

7 .Cilium 重要feature支持，重要落地项目 EBPF方案典型产品，客户案例 cilium v0.11及之前 tc-bpf 功能集支持 某教育客户(EKS 基于ipvlan/tc-bpf端口复 用） cilium v1.5 socket map/redirect 功能集支持 某游戏客户(XDP 用户态协议 - Service Mesh 栈） cilium v1.8 某游戏客户(XDP 网关) - socket level EBPF 功能集支持 - XDP Load Balancing - XDP 功能集支持 腾讯云TCM(服务网格) - socket based load balance - namespace cookies功能支持 - sesson affinity 腾讯云TKE(cilium整体解决方案, cilium v1.9 服务于多个重点客户) - neigh redirection 功能集支持 - iptables by pass 6 

8 . 特性名称 描述 该特性可以使得eBPF程序经过一次编译后，可以运行在所有支持CO-RE CO-RE机制 模式的内核中，无需重复编译eBPF字节码。 TRACING类型的eBPF用于内核函数、ftrace的跟踪，与KPROBE和 Cillium支持：代码分析 TRACEPOINT类型的eBPF类似，但功能更为强大、效率更高。同时，其 TRACING类型 支持直接内存访问，可以在函数退出时获取到函数的入参、能够修改某 类被trace函数的返回值等。 bpf-trampoline机制 用于支持TRACING类型的eBPF程序attach到其他的eBPF程序上 新增STRUCT_OPS类型的eBPF程序，可以实现替换内核中的一些函数。 STRUCT_OPS类型 该特性基于该类型的eBPF实现了tcp拥塞算法的eBPF支持，可以使用 eBPF程序来实现tcp拥塞算法。 动态eBPF程序扩展，可以用现有的eBPF动态替换原有的eBPF程序中的 EXT类型 某个函数。 optimize-bpf_tail_call机制 使得单个eBPF程序可以bpf_tail_call多个eBPF程序（之前只能单次调用） 一、ebpf移植整体情况： bpf-dispatcher 优化某些eBPF程序（如XDP程序）的执行速度，用于将间接调用（如 bpf_prog_run_xdp）转换为直接调用 增加套接口类型的MAP对TCP处于listen状态的套接口和UDP套接口提 移植的补丁数量约350个，移植的特性（功能）数量约20个 sock_map TCP listen and UDP support 供支持 为TRACING类型的eBPF新增BPF_MODIFY_RETURN的attach类型，可 bpf_modify_ret 以通过eBPF程序终止原来的被插桩的函数的执行，并修改其返回值。该 特性在LSM中得到了使用。 bpf-lsm类型 LSM模块提供的对eBPF的支持 bpf_link抽象的实现。该特性将attach进行了抽象，在eBPF和被attach 二、与5.10特性对比 的实例之间抽象了一层link，使得attach动作变得统一，且TRACING类 bpf-link机制 型的eBPF也可以被pin了（之前基于kporbe的eBPF在用户态程序退出后， 会被直接detach，然后释放） bpf-netns类型 支持将eBPF程序attach到网络命名空间上 新增helper函数bpf_sk_assign，用于在收包的时候直接指定报文的收 bpf_sk_assign函数 包套接口 条目 TencentOS server upstream kernel cilium相关缺失 SK_LOOKUP类型 实现SK_LOOKUP类型eBPF，该程序会在套接口查找的时候被调用，从 而直接影响报文被投递到的套接口 5.10 迭代器类型的eBPF程序类型支持。该特性提供的是一个机制，可以将 eBPF程序作为一个文件（如pin文件）暴露给用户，用户在读取文件的 bpf-iterator机制 时候触发eBPF程序遍历某种数据。根据实现的不同，能做到的功能也不 bpf 类型 30 30 0 bpf: Support access to bpf map fields机制 同。比如已经实现了的套接口迭代器、进程迭代器、map迭代器等。 可以在eBPF程序里访问map的元素属性，包括map长度等 该特性提供了编译时BTF ID解析的功能。在以往，内核中想要获取到某 个结构体对应的BTF的ID，需要主动调用函数接口从BTF数据中进行符号 bpf map类型 28 28 0 resolve_btfids机制 查找，效率比较低。该特性在内核编译期间就能找到对应的BTF ID，并 将其填充到对应的全局变量中（变量处于特定的数据段中） 从bpf_sk_storage类型的MAP进行抽象，创建了通用的local_storage 机制，可用于将数据存储到特定的实例上。同时，实现了 bpf_local_storage(MAP) bpf helpers 函数 149 155 0 BPF_MAP_TYPE_INODE_STORAGE类型的MAP，可以将数据存储到特 定的inode上，即所谓的本地存储。 ring buffer类型的eBPF map的实现，用于取代之前的PERF_EVENT类 bpf-ring-buffer(MAP) 型的MAP。可用于用户态和eBPF程序之间的数据传输，且支持更复杂的 操作。 通过传递给helper函数bpf_for_each_map_elem一个回调函数，可以遍 bpf_for_each_map_elem函数 历map 中的数据，每个数据都会传递给回调函数。 bpf_timer eBPF程序中使用timer定时器 三、cillium支持 https://docs.cilium.io/en/stable/operations/system_requirements/ 官方列举的features和内核选项，在Tk4(5.4)中都支持 7 

9 .nettrace – 网络包全生命周期跟踪、网络诊断和监控工具集 云原生场景下，网络环境部署越来越复杂，报文在节点上的处理路径也越来越长。当发生 网络故障时，传统的网络定位工具（tcpdump、dropwatch等）存在一定的短板，无法深 入内核进行分析，使得问题定位困难、周期长。 nettrace：基于eBPF实现的用于云原生场景的网络定位、诊断和监控工具： ✓ 报文生命周期跟踪，快速定位问题 ✓ 主动故障诊断，一键解决网络故障 ✓ 常态化网络异常监控，实时发现网络问题 ✓ 集群报文染色，解决容器集群范围网络包跟踪难题 ✓ 新增丢包原因Feature，在Kernel社区提交近100个patch，上了lwn新闻 Better visibility into packet-dropping decisions https://lwn.net/Articles/885729/ 

10 .Nettrace-监控模式(常态化部署/系统级监控) 适用场景： • 轻量级，可常态化部署到生产环境中，实时监控整个系 统上所有的网络丢包等网络问题 • 事件触发，几乎无开销 监控命令：droptrace –p tcp 监控结果：监控系统中所有的TCP丢包事件及其原因。 

11 .Nettrace-诊断模式(场景化专业分析) 适用场景：出现网络故障时，启动命令跟踪特定 现象：节点ping不通 流（报文），进行诊断分析 诊断命令：nettrace –p icmp -–saddr 192.168.122.8 –intel 诊断结果：iptables在filter表INPUT链中的防火墙规则导致 普通用户、专家都适用 

12 .EKS(安全容器)网络方案 EKS: • 腾讯Severless安全容器方案，虚拟化轻量隔离 网络方案： • 主/从IP模式，控制面和数据面分离 • 节点使用从（slave）IP，POD使用主 （master）IP。对外通信时，均使用主IP来 进行，POD对整个过程不感知。 eBPF程序： 1. 基于TC在对外的网口上进行报文转发，转发 控制面和数据面数据，通过端口隔离 2. 基于套接口监控节点与POD上的连接，并在 系统调用阶段进行端口冲突检查和反馈 内核： 新增两种eBPF类型，用于跟踪套接口状态变化 

13 . 基于eBPF的DNS缓存 问题： • 节点需要独立的dns pod，开销大，性能差 • Pod级别dns缓存缺失，导致需要大量dns 查找，性能差，上游dns服务压力大 • 相关问题难查，运维成本高 基于eBPF，在节点/POD上实现DNS缓存机制： • 高性能：相比于用户程序缓存的方式，查找 性能提高一倍 • 低开销：节点无需额外部署dns pod或者 systemd-resolved，节省资源 • 免运维：节点级别缓存，对用户透明 

14 . 高稳网络：基于多路径TCP的网络可靠性增强 问题： 单点交换机故障引起服务故障-交换机假死 CUF CUF CUF CUF CUF CUF CUF CUF CUF CUF CUF CUF CUF CUF CUF CUF 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 LC0 LC1 LC2 LC3 LC4 LC5 LC6 LC7 核心层交换机 接入层交换机 LA0 LA1 LA0 LA1 eth0 eth1 eth0 eth1 bond1 bond1 host host 案例统计： 说明：某一个LC或者LA出现假死；即：LACP协议探测上下行交换机正常，但是实际交换机已经 影响时长 次数 百分比 不转发流量, 会导致故障交换机成为“网络黑洞”,影响所有流经对应交换机的流量通信。 20s以内 80 78.6% 业务诉求:基于TC在对外的网口上进行报文转发 20s-60s 16 16.5% 1） 减少或避免业务对网络中单点交换机故障的感知度 60s-180s 2 2% 2） 尽量不对现有业务代码做改动 180s以上 3 2.9 

15 .方案: MPTCP (mutipath tcp) 链路故障failover - 多路径TCP & 交换机ECMP算法 tcp tcp socket0(sip1,sport1) socket0(dip1,dport1) client(sip1,spor mptcp …… …… mptcp server t1) socket(sip1,sport1) socket(dip1,dport1) tcp tcp socketN(sipN,sportN) socketN(dip1,dport1) 图(1): user / kernel space sock视图 ECMP LC client LA LA Server LC 图(2): MPTCP + ECMP链路failover 原理： - MPTCP保持了和传统TCP相同的语义(socket系统调用扩展了prot参数: IPPROT_MPTCP) - <sip1,sport1,dip1,dport1> 之间链接会被kernel扩展为<sip1,sport1,dip1,dport1>,<sipN,sportN,dip1,dport1> 多条链接 - 交换机用ECMP协议根据5元组选择转发出向端口，预期将不同tcp子流从不同的端口转发出去,从而被转发到不同的下行交换机 增强：(除backport MPTCP外) 1、client不支持单ip多port创建子流(支持多ip方式来创建子流), 容器通常只有一个IP。开发支持单ip多port模式。 2、ingress场景下需要用到iptables来负载均衡，Netfilter子系统支持MPTCP。 3、扩展到云原生(容器)场景，打造云原生高稳网络方案 14 

16 .03 TencentOS RUE(如意) 内核统一资源隔离解决方案，降本增效利器 

17 . 基于RUE的全场景混部：基于内核隔能力，打造全场景混部系统，提升资源利用率 在离线业务混部背景 全场景混部技术(容器+物理机) IDC整体自研利用率低，CPU利用率: <15% Caelus 在线 容器调度 应用画像 配置接口 调度 系统 离线 干扰检测 冲突处理 系统监控 TCS 容器 基础容器服务 服务器A在线业务 服务器B离线业务 服务器C混部 平台 在线业务：常规业务 离线业务：TDW大数据(压缩和常规)、AI训练、广告转码 TencentOS CPU 网络 IO 内存 Server 关键问题 如意(RUE) 服务质量监控系统 统一资源隔离 配置工具 QoS指标 异常记录 统计信息 原生内核隔离性差，混部后毛刺增加, 在线业务受严重干扰 100 80 CPU使用率 60 整体方案：底层资源隔离(RUE)+上层容器编排 40 • 上限高，适用性广，不挑业务 20 0 • OS内核层自动的容器隔离，冲突处理 • 相比社区，内核隔离能力全面增强 在线单独 离线单独 混部后 

18 .全场景混部系统如意(RUE)：定位为全场景混部系统底座，为混部底层提供资源隔离解决方案 17 

19 .如意CPU QoS：绝对抢占(BT调度器) 离线任务 在线任务 独立的调度类 场景 ① 是绝对抢占、低延迟的保障 2 在线离线同时存在 2 在线始终优于离线 实际验证干扰率1%以内 1 4 1 3 CPU pick_next_task 3 5 1 1 1 2 3 选出任务 1 2 3 4 5 跳过离线 运行在线 场景 ② 在线任务 离线任务 在线为空 只存在离线 选择离线 N 2 CPU 离线得到运行机会 pick_next_task NULL 1 3 1 NULL 1 2 3 运行离线 场景 ③ 在线任务 在线任务 在线 CPU 在线唤醒抢占离线 入队 NULL 1 wake_up_process 1 need_resched 1 运行在线 18 

20 . 云原生核心能力(如意)效果：完美底层隔离，资源利用率翻倍，成本降低50% 混部关键指标 奖项 • 混部大盘CPU利用率:<15%->30%，成本降低50% 2021年7月15日，开源TencentOS系列产品亮相央视 《经济半小时》 • 干扰率：离线对在线的影响小，干扰率<1% 腾讯开源TencentOS系列项目亮相央视 • 抖动：在线业务的io、网络带宽稳定，波动率<5% 2021年9月17日，TencentOS荣获中国信通院授予的“2021年 • 覆盖规模超2000万核，供应离线600w核 OSCAR尖峰开源项目及开源社区”奖项。 • 样板集群CPU占用率:65%，行业标杆 腾讯TencentOS荣获“OSCAR尖峰奖”，创新突破节省上亿度电 资源 CPU隔离效果对比 基于RUE的CPU隔离 基于社区内核的隔离 纯在线业务 

21 .典型案例：基于如意(RUE)的全场景混部系统 作业帮 成本降低43% 稳定性提升至99.995% 接口响应提升10% “在多重举措的合力推动下，作业帮容器化的收益显著，同样业务迁移前后，使用了 HPA 和在离线混合部署后，成本下降 43%，稳定性提升到99.995%，接口响应提升10%。由此，有效支持了作业帮业务的快速迭代，秒级急速扩缩容，服务运 行态规范落地和统一的运维环境，多云的环境统一，提升服务可用性。” 最佳实践 | 作业帮云原生成本优化实践 某头部互联网厂商 资源利用率提升100% 规模10万核+ 成本节省数百万/年 基于RUE和Crane(腾讯云推出的国内首个云原生成本优化开源项目)，整体基于OS内核提供的强隔离、性能主动告警、云原 生SLI等高级能力，通过预测，推荐资源和智能弹性配置，提升业务整体的资源利用率，遵循 FinOps 标准，为云原生用户 提供云成本优化一站式解决方案。 20 

22 .04 TencentOS悟净 内存分级卸载，提升内存利用率 

23 .内存分级卸载-悟净-架构 悟净基于内核内存管理系统 LRU 页面回收 机制，对其核心路径做了大幅调优与改造， 并引入以下几大独立自研模块： •UMRD (Userspace Memory Reclaim Daemon)：用户态主动式异步回收进程，根据 压力信息平衡回收策略。 •DAMON 核心子模块：主动探测内存热度，提 供分级回收数据源。 •SWAP hinting 框架：在页换出时根据页面热 度进行多级回写平衡。 •SWAP balancer 模块：异步平衡多级 SWAP 设备，精准冷内存沉降。 •CXL 支持：利用内核 Promote / Demote 框 架避免 Page Fault 与 IO，提高性能。 •核心性能优化：针对内核内存管理核心代码、 Cgroup V1 PSI、SWAP 路径、Working Set 统计等，进行了大量优化，部分已经upstream 22 

24 .内存分级卸载-悟净-效果 内存节省30+% 23 

25 .05 其他云原生特性 云原生SLI/Ebpf-based云原生监控 

26 .云原生SLI-Sevice Level Indicator 背景： 目标： • 容器隔离性差，干扰严重 • 容器级别、专业、专用 • 提升密度，资源限制引发抖动 • 常态化部署(低开销) • 业务随机抖动，业界难题 • 主动监控异常、主动记录 • 现有指标：进程级别、全局统计，难用！ • 毫秒级响应 方案对比： SLI方案选择 优点 缺点 内核原生实现 1. 在内核里实现，跟踪开销最小，性能最优 1. 扩展性较差 2. 可以调用内核所有接口，功能开发不被制约 2. 开发、更新慢 3. 开发难度相对较高 eBPF 1. 扩展性较好，可以按需动态修改 1. Ebpf代码有较多安全检查，引入较大开销 2. 开发、部署周期短，开发难度相对低 2. Ebpf对调用接口有严格的限制，功能有限 基础能力：选用内核原生方案 25 

27 . SLI指标 分类 说明 云原生SLI-方案 Load.r CPU 容器内处于R态的进程平均数量，判断 overload Load.d CPU 容器内处于R态的进程平均数量，判断锁 应用监控框架（如K8s） 竞争或IO阻塞 longsys CPU 内核态长延迟。系统调用、缺页、中断等 主动上报 原因可能导致 云原生SLI rundelay CPU 调度延迟。判断CPU争抢 Load.d Block D 全局匿名内存换出 irqtime CPU 中断延迟。判断中断带来的影响 Load.r IO Block 容器匿名内存换出 Block D CPU D状态阻塞延迟。判断锁竞争或IO阻塞 Longsys Sleep S 全局匿名内存换入 IO Block IO IO阻塞延迟。判断IO问题 rundelay 全局内存直接回收 容器匿名内存换入 内存系列 内存 内存关键延迟。判断各种细致的内存问题 Irqtime(中断延迟) 容器内存直接回收 全局内存压缩 指标 实时捕获 Mbuf（黑匣子，实时捕获异常） 特性 ● 常态化部署，低开销，专业级云原生指标 ● 主动性能异常上报，毫秒级相应 ● MBUF问题定位(黑匣子)，捕捉每一次抖动 26 

28 .云原生SLI-案例 现象描述： 典型的业务随机抖动问题 • 容器内日志打印5-8s内日志无输出，业务莫名卡顿 行业难题！ • 随机出现，无复现规律，持续时间短(秒级) • 资源无瓶颈，cpu/内存/io/网络 都正常 效果： • 监控无异常，秒级监控也束手无策 • 抓到关键第一现场，定位问题，优化内核后解决 方案： • SLI+Mbuf，常态化部署，捕获随机抖动 27 

29 .Ebpf-based云原生监控 tcptrace tcpconnect biocgpatter biocgsnoo offwaketim throttlesnoo …… User space n p e p Libbpf BCC Kernel space Runtime NET IO CPU Event Targets Verifier 报文跟踪 时延监控 总延迟 队列延迟 阻塞延迟 sockets 连接监控 丢包监控 合并数 IO模型 阻塞原因 kprobes BPF uprobes RTT分布 存活时间 IO地址 IO大小 限流监控 tracepoints BPF actions 容器级别 CGroup CGroup CGroup 基于 Libbpf 和 BCC，实现 per-cgroup 级别的监控工具 28