蒋彪，腾讯云高级工程师，10+ 年专一于操作系统相干技术，Linux 内核资深发烧友。目前负责腾讯云原生 OS 的研发，以及 OS/ 虚拟化的性能优化工作。
导语
TencentOS Server (又名 Tencent Linux 简称 Tlinux) 是腾讯针对云的场景研发的 Linux 操作系统，提供了专门的性能个性和性能优化，为云服务器实例中的应用程序提供高性能，且更加安全可靠的运行环境。Tencent Linux 应用收费，在 CentOS（及兼容发行版）上开发的应用程序可间接在 Tencent Linux 上运行，用户还可继续取得腾讯云的更新保护和技术支持。
TencentOS 在腾讯外部曾经经验了超过 10 年的迭代和演进，承载撑持了腾讯所有业务，商用部署节点超 300w，禁受住了海量简单业务模型在极其场景中的极限考验。
通用 OS 架构
传统 OS 的定义(盗用经典教科书内容)：
操作系统是控制应用程序执行的程序，是应用程序和计算机 (硬件) 间的接口。
操作系统有 3 个指标：
- 不便：让计算机更易于应用
- 无效：容许以更无效的形式应用计算机资源
- 扩大：容许在不影响服务的前提下，无效的开发、测试和引入新的零碎性能
传统通用 OS(Linux) 的典型架构设计如上，操作系统中蕴含了为实现上述 3 个指标而提供的各种功能模块和接口，总体上，分为两大部分：
- 内核：提供底层硬件 (计算机) 的根本形象，不同的内核模块提供不同的硬件治理或相干的辅助性能，通过零碎调用向下层利用提供服务。
- 根底库和相干服务组件(用户态)：为实在业务运行提供根底运行环境
IaaS 场景中的 OS
IaaS 场景中，OS 次要用于为云主机 (虚拟机) 提供运行环境，在 IaaS 场景中，OS 中运行的工作类型和数量可控，场景绝对通用场景简略很多。工作类型根本就只有如下几类：
- VM 相干线程(通常为 Qemu + Vcpu 线程)
- 各种管制面的治理 Agents
- OS 本身必须的一些控制线程(比方 Per-cpu Workers)
IaaS 场景中，为使虚拟机性能有限靠近 (甚至超过) 物理机，通常会思考做减法，通过有限缩小虚拟化、OS 层面的开销来晋升性能，罕用的一些典型伎俩如：
- CPU 层面的绑核
- 内存层面的预调配
- IO 层面的各种 Bypass Kernel 技术
对于 OS 来说，最终的后果是：
OS 越来越薄，最终可能会隐没
换个角度看 OS (云原生角度)
当云原生浪潮袭来，换个角度 (云原生角度) 再去扫视 OS 时，看到的又是不一样的视图。云原生场景对 OS 提出了新的挑战，也为 OS 相干技术的进一步倒退和演进注入了新的能源。
云原生场景中，OS 为不同类型的利用(Apps，Containers，Functions，Sandboxes)，提供底层撑持和服务。此时，相比 IaaS 场景，最显著的差异在于：
利用和零碎的边界大幅上移，利用之下皆为 OS
对于 OS 来说，最终的后果是：
OS 越来越厚(孕育有限可能)，与 IaaS 场景造成鲜明对比
TencentOS For 云原生
在云原生浪潮席卷的行业大背景下，随同着腾讯本身的各种业务架构的疾速转身，业务的容器化、微服务化、Serverless 化，对底层的基础设施 (包含外围的 OS) 提出了新的挑战和要求，TencentOS 也随之迅速转型，针对腾讯本身的云原生场景和需要，进行了深度的重构和从新设计，全面拥抱云原生，向云原生 OS 的指标一步步迈进。
总体架构
TencentOS (以后)次要实现 (Kernel 层) 了如下云原生 Features (后文开展)
- 云原生调度器 – Tencent Could Native Scheduler(TCNS)
- 云原生资源 QoS – RUE
- Quality Monitor
- 云原生 SLI
- Cgroupfs
云原生调度器 – Tencent Could Native Scheduler(TCNS)
TCNS 是 TencentOS 针对云原生场景，提供的内核调度器整体解决方案，能够笼罩容器、平安容器和通用场景，对于多优先级业务混部中对 CPU 隔离的需要，以及对实时性 / 稳定性有极致要求的业务场景，有奇效。无关混部场景中对于 CPU 隔离性的需要和可能的解决方案，本篇 《混部之殇 - 论云原生资源隔离技术之 CPU 隔离(一)》 有具体讲解，无关内核调度器的实时性保障的相干技术探讨，在后续的 os 系列文章中会再讲到，请陆续关注。
TCNS 次要包含 3 个模块：
- BT Scheduler
- VMF Scheduler
- ECFS
BT Scheduler
BT Scheduler 是 TencentOS 针对 (容器) 混部场景的 CPU 隔离设计的新的调度类，地位如下图所示：
其外围设计为：全新设计新的调度类，优先级比默认的 CFS 低，仅当没有其余更高优先级的工作运行时能力运行，专用于运行离线工作(在线工作应用 CFS 类)。
如此设计的外围收益为：可实现在线业务对离线业务的相对抢占，在混部场景中能够失去近乎完满的 CPU 隔离成果。
BT 调度类自身还是一个性能残缺的新调度类，在 BT 调度类内能够提供相似 CFS 的性能选集。
除此之外，BT 调度类还实现了如下诸多个性：
无关 BT 的其余信息，能够戳如下链接理解：
【https://cloud.tencent.com/dev…】
注：内容尽管有些老，新版本曾经迭代了几轮，供参考。无关 BT 的最新介绍，也会在后续陆续推出相应文章，敬请期待。
VMF Scheduler
VMF (VM First) 调度器，是 TencentOS 针对平安容器场景 (和虚拟机场景) 专门设计的内核调度器解决方案(从新实现了一个全新的内核调度器)。
重写调度器的次要背景是：现有的 CFS 调度器基于“齐全偏心”的准则，无奈保障虚拟机 (平安容器) 线程调度的实时性。
VMF 的外围设计包含：
- 不偏心的调度器，通过将 CPU 资源向虚拟机过程歪斜，从而保障虚拟机 (平安容器) 线程能优先失去调度
- 基于工作类型进行调度，而没有细粒度的优先级。相比之下，咱们认为，CFS 的优先级并不能精确的形容不同过程的运行特色，典型的就是内核线程，这类过程的特色很显著，首先他很重要，其次他的单次执行工夫很短，但却很难定义他们的优先级，高下都不适合，仅仅通过优先级并不能精确形容他们运行行为。在 VMF 中，咱们通过对不同过程的特色进行画像和建模，将所有过程进行分类，并对不同类型过程设计精密的调度策略，能够满足云原生场景下，对实时性的极致需要。
- 单向激进抢占，即 VM 过程能够在任何状况下尽快抢占其余工作，而反过来则不行，这样能够在不侵害调度器的吞吐性能的状况下，最大水平保障 VM 过程的实时性。
另外，咱们还针对其余的场景和需要设计了许多其余的个性，篇幅无限，无奈开展详述，打算后续另起话题独自介绍。
整体来看，通过自研的 VMF 调度器，咱们能够取得几个要害收益：
- 极致调度提早指标(实时性好)，极其状况下的最大提早都在奥妙级
- 新调度器相比 CFS，要轻量许多，整体代码量不到 CFS 的 1/3
- 在存在局部烦扰的状况下，保障虚拟机 (平安容器) 线程的实时性
- 基于 VMF 的分类设计，能够实现对不同类型过程提供不同级别的 CPU QoS 保障
- 通过齐全自研的调度器，能够做很多很炫的、平时不敢设想的定制。如果大家有优化 CFS 的教训，应该都能领会，要在 CFS 上做定制能有多好受。
无关 VMF 的阐明，也打算另文探讨，也请期待。另 OS2ATC 2020 大会中的虚拟化专场，主题：《Tianus Hypervisor –“零损耗”的腾讯云轻量级虚拟化技术》中也有局部阐明
https://www.bilibili.com/vide…
< 注：1:24:00 开始 >
ECFS Scheduler
ECFS 是针对通用场景 (Upstream 路线)，基于社区支流的 CFS 调度器做优化，外围的优化(设计) 点：
- 引入新的任务调度类型，用于辨别在线和离线工作。
- 优化抢占逻辑，保障在线对离线的抢占。防止离线对在线的不必要抢占
- 相对抢占设计
- 超线程烦扰隔离
具体原理暂不开展，请期待后续的 os 系列文章中再阐明。
云原生资源 QoS – RUE
RUE (Resource Utilization Enhancement)，中文品牌”如意“，是 TencentOS 产品矩阵中一款专为云原生场景下服务器资源 QoS 设计，晋升资源利用率，升高经营老本的产品。如意是对立调度调配云上机器的 CPU、IO、网络、内存等资源，相比传统的服务器资源管理计划，如意更实用于云场景，可能显著晋升云上机器的资源应用效率，升高云上客户的经营老本，为私有云、混合云、公有云等客户提供资源增值服务。如意的核心技术能做到不同优先级的业务之间不相互烦扰，实现资源利用率、资源隔离性能、资源服务质量的高效对立。
架构
RUE 包含如下次要模块：
Cgroup Priority
在内核中引入全局对立的 Pod 优先级概念，同时贯通于 CPU、Memory、IO、Net 所有资源的解决栈，提供对立的优先级管制。
CPU QoS
基于上一节提及的 TCNS 实现，能实现 CPU 层面的相对抢占和完满隔离。
Memory QoS
通过在调配和回收门路上的优先级感知，为不同优先级的容器提供不同级别的内存调配 QoS 保障(就义低优容器的内存可用性，以保障高优容器的内存 QoS)。其中实现了多个原创个性，整体上能最大水平保障高优容器的内存调配提早，而这也是 Upstream Kernel 不足的要害能力之一。
IO QoS
容许用户将容器从 IO 角度划分成不同优先级，依据优先级调配 IO 资源，保障低优先级容器不会对高优先级容器造成烦扰，同时容许低优先级容器应用闲暇 IO 资源，从而晋升资源利用率。IO 资源 QoS 蕴含三个方面：带宽 QoS，提早 QoS 以及回写 QoS。另外，还提供最低带宽保障性能，避免低优饥饿导致可能的优先级反转。
Net QoS
容许用户将服务器上网卡的带宽依照优先级调配给不同的容器，容许低优先级容器应用闲暇的带宽资源，同时不会对高优先级容器的网络带宽造成烦扰。另外，还提供最低带宽保障性能，避免低优饥饿导致可能的优先级反转。
RUE 的整体构造比较复杂，对 Upstream Kernel 进行了大量的改变和优化，相干个性波及内容较多而宽泛，本文无奈一一开展，后续会专文开展逐个探讨，敬请期待。
总体成果
- 引入全局对立的 Pod 优先级概念，提供对立的优先级管制
- 实用于多优先级容器 (Pod/ 工作) 混合部署，可极大晋升资源利用率
Quality Monitor
混部场景中，为晋升整机资源利用，偏向于最大化 Overcommit。在底层的隔离技术 (资源 QoS) 保障的前提下，能肯定水平保障烦扰隔离。但仍面临两个次要挑战：
- 如何评估 QoS 成果和感知“烦扰”？
- 呈现“烦扰”后，如何无效排查？
另一方面，下层调度 (K8s) 也须要基于底层 (内核) 能提供更有意义的指标(服务质量评估及更粗疏指标)，进行精细化经营，晋升混部集群的整体体现，晋升混部技术计划的整体竞争力。
现有零碎中存在一些扩散的、不同维度的统计数据，但：
- 不够“敌对”，对于下层调度 (K8s) 来说，不能了解，须要一些更有意义的形象数据，作为“根底”的调度根据。
- 不够“业余”，对于混部场景，还须要一些针对性的监控数据，K8s 能够基于这些数据做更“精密”的经营。
另一方面，现有零碎不足常态运行的调测伎俩，能在呈现“烦扰”(或者高优容器抖动)时，第一工夫抓到现场，无效剖析定位的伎俩。现有伎俩的有余：
- 多需预先部署(Ftrace/Kprobe 等)，但业务抖动可能难以复现，或者刹时偶现，难以捕获。
- 开销大，难以常态化部署。
随 Cgroup V2 一起呈现的 PSI 是一种十分好的尝试，肯定水平上反馈了零碎的 Health 状态，但如用于混部场景的 QoS 成果评估，还略显薄弱。
TencentOS 设计了 Quality Monitor，专用于评估容器各方面的服务质量 (QoS)，并提供常态化、低开销、事件触发的监控机制，在呈现服务质量降落(不达标) 时，能够及时、无效的捕捉异样上下文。
Quality Monitor 次要蕴含两个模块：
Score
服务质量评分，具体定义为：
Per-Prio score = 100 – 因其余优先级 (Cgroup) 过程烦扰 (资源抢占) 而 Stall 的工夫占比
Per-Cg score = 100 – 因其余 Cgroup 过程烦扰 (资源抢占) 而 Stall 的工夫占比
注：这里的烦扰包含软件和硬件层面的烦扰
Monitor Buffer
常态监控烦扰和抖动的内存区，当要害指标 (依赖于云原生 SLI) 不合乎预期 (超限) 时，自动记录相干上下文信息。
总体成果：
- 提供优先级和 Pod 两个维度的服务质量评分，用于评估容器的服务质量(QoS)
- 当呈现服务质量降落 (烦扰) 时，能够通过 Monitor Buffer 捕捉到异样上下文
云原生 SLI
定义
SLI (Service Level Indicator) 是用于观测 Service level 的指标，比方 Latency、吞吐、错误率等；
SLO 是基于 SLI 指定的指标；
从云原生的角度看，云原生 SLI 能够 (广义的) 了解为针对容器的可用于观测 Service level 的指标，即容器视角的的一些要害指标，这也是定义容器 SLO 的根底。
另一方面，现有 Upstream Kernel 在 Cgroup 根本的统计和监控还比拟原始和毛糙，仅有一些根本的统计信息，比方 Memory/Cpu 的 Usage 信息，不足可用的、容器视角的 SLI 数据采集和形象。
TencentOS 设计了云原生 SLI，通过在内核中实时的收集和计算 (低开销形式)，提供充沛的、业余的、不同维度的 SLI 指标，供下层(K8s) 应用，用户可基于此定个相应的 SLO。
云原生 SLI 包含如下模块：
CPU SLI
收集并计算 CPU 维度的 SLI，具体包含调度提早、内核态阻塞提早、Load、Context-switch 频率等。
Memory SLI
收集并计算 Memory 维度的 SLI，具体包含内存调配提早、内存调配速度、间接回收提早、内存 Compaction 提早、内存回收提早、内存调配失败率等。
IO SLI
收集并计算 IO 维度的 SLI，具体包含 IO 提早、IO 吞吐、IO 错误率等。
NET SLI
收集并计算网络维度的 SLI，具体包含网络提早、网络吞吐、IO 错误率等。
总体成果
- 提供容器级别级别的细粒度的 SLI 指标
- K8s 或其余模块 (如 Quality Monitor) 能够基于相干指标做精细化经营
Cgroupfs
云原生场景中，基于 Namespace、Cgroup 等底层资源隔离技术，做了资源的根底隔离 (容器视角)，但容器的整体隔离性还十分不残缺，其中，/proc、/sys 文件系统中的一些资源统计信息，还没有残缺的容器化(或者说 Namespace 化)，导致在物理机 / 虚拟机中的一些常用命令(比方 free / top) 在容器中运行时，不能精确展现容器视角的信息 (默认展现零碎级别的全局信息，比方零碎总内存和 free 内存)，这也是云原生(容器) 场景中始终存在的一类顽疾。
间接起因是因为相干信息尚未容器化，实质起因还是因为容器的隔离性还存在有余。
针对 /proc 文件系统中要害信息没有容器化的问题，社区举荐的解决方案是：
lxcfs
lxcfs 是针对上述场景而量身定制的一个虚构文件系统，其底层基于 FUSE 实现了一个用户态的文件系统，提供容器化视角的 /proc 文件系统中的统计信息，还包含一点点 /sys 文件系统的个别信息，实现比较简单间接。
lxcfs 根本解决了在容器中应用罕用根底命令 (free / top / vmstat 等) 的困扰，但仍存如下有余：
- 须要依赖额定的组件 lxcfs，难与容器深度交融，不可控。
- 用户态基于 FUSE 实现。开销相比内核更大，信息准确度不如内核。
- lxcfs 稳定性比拟差(据用户反馈)，常常出问题：卡死(开销大)、信息获取不到等。
- 定制能力差，以后的实现齐全基于用户态可见的一些根本信息(以后信息还比拟无限)，如果须要更深层次的定制(基于用户需要)，就会遇到能力瓶颈(受限于用户态实现)。
TencentOS 在内核态提供了相应的解决方案，取名为：_Cgroupfs_
其外围设计为：设计一个新的虚构文件系统(搁置于根文件系统中)，其中蕴含咱们须要实现的容器视角的 /proc、/sys 等 fs，其目录构造放弃与全局 procfs 和 sysfs 保持一致，以保障对于用户工具的兼容性。理论读取相干文件时，通过 cgroupfs 的读者过程的上下文来动静生成对应的容器信息视图。
目录构造如下所示：
总体成果
- 内核态容器视角的虚拟机文件系统(/proc，/sys)，隔离全局信息，反对惯例命令(top，free，iotop，vmstat 等)
- 面向 Cgroup V2 设计，对立层次结构
- 可依据需要做深层次的定制和扩大
TencentOS For Kubernetes
在云原生浪潮下，Kubernetes 作为行业事实标准首当其冲。随着云原生进入深水区，业务也更关注上云后的理论增益，资源利用率与老本也日益被器重。在原有 Kubernetes 体系中，通过 Service QoS Class 和 Priority 可将不同优先级 workload 混部在同一集群中，以减少资源利用率，缩小资源经营老本。但这种“用户态”行为受限于 Linux kernel cgroups 设计，天生隔离粒度有余。业务会因混部后资源争抢受损，有时往往得失相当。
在这种背景下，TencentOS 面向云原生与 Prioirty 的设计，能完满解决这个问题。咱们通过将 Kubernetes Service QoS Class 与 TencentOS Priority 一一对应，在内核层原生感知优先级，在底层提供强隔离机制，最大水平保障混部后业务的服务质量。而且这种优先级机制是贯通在整个 cgroups 子系统中。
腾讯云容器团队已在内部开源了TKE 发行版，该 Feature 会在下个版本反对，用户可继续关注社区动静。
More
除关注云原生之外，TencentOS Server 自身为一款通用服务器 OS，在 10 余年保持专一内核的过程中，也开发 / 定制过很多或大或小的 Features，无关 TencentOS 其余阐明、以及代码，如有趣味，欢送持续戳如下链接理解：
【https://github.com/Tencent/Te…】
结语
TencentOS 始终在思考、摸索本人的云原生之路，旅程已开始，但远未完结！