腾讯TencentOS 十年云原生的迭代演进之路
蔣彪，騰訊云高級工程師，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/developer/article/1519558】
注：內容雖然有些老，新版本已經迭代了幾輪，供參考。有關 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/video/BV1Ky4y1m7yr/?spm_id_from=333.788.recommend_more_video.1】
< 注：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/任務)混合部署，可極大提升資源利用率
Qcon 北京2021-全球軟件開發者大會，有相應的 Topic 《騰訊 Kubernetes 大規模離在線混部與內核隔離實踐》分享，歡迎圍觀：【https://qcon.infoq.cn/2021/beijing/presentation/3253】
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/TencentOS-kernel】
結語
TencentOS 一直在思考、探索自己的云原生之路，旅程已開始，但遠未結束！
- END -
看完一鍵三連在看，轉發，點贊
是對文章最大的贊賞，極客重生感謝你
推薦閱讀
圖解Linux 內核TCP/IP 協議棧實現|Linux網絡硬核系列
Linux調度系統全景指南(上篇)
一個奇葩的網絡問題，把技術磚家"搞蒙了"
總結
以上是生活随笔為你收集整理的腾讯TencentOS 十年云原生的迭代演进之路的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一文带你理解云原生|云原生全景指南
- 下一篇： 深入理解RCU|核心原理