一款跑在雲上的定製容器專屬 OS 來了——LifseaOS | 龍蜥技術
簡介：如果可以把運維 API 化，那我們是不是可以把 OS 也作為一個 K8S 可以管理的資源，讓 K8S 像管理容器一樣管理OS？
引言
在 2021 年 10 月的雲棲大會上，
不久前，LifseaOS 核心程式碼正式在龍蜥社群開源，使用者可以基於 LifseaOS 開原始碼構建、定製一個屬於自己的容器專屬 OS。
WHY LifseaOS？
說到 LifseaOS，不得不提到其主要面向的場景：容器。
從最早的 UNIX chroot，到 Linux 的 LXC，早期以 cgroup、namespace 為基礎的容器執行時技術一直在持續演進，但並沒有出現階段性的突破。直到 2013 年，docker 的出現直接推進了容器的快速普及，經過短短几年的發展，容器已經成為了主流的 IT基礎設施技術被廣泛地應用。容器的快速發展 docker 功不可沒，而我們回顧當時 docker 最初的工作，可以發現其並沒有進行顛覆性的技術變革，其核心創新主要包括以下兩個部分：
- 定義了容器分層映象標準以及映象倉庫：容器映象將應用執行環境，包括程式碼、依賴庫、工具、資原始檔和元資訊等，打包成一種作業系統發行版無關的不可變更軟體包
- 定義了覆蓋容器全生命週期 restful API：restful API 的將整個容器的建立、監控、銷燬過程標準化，部署、運維人員可以在一個叢集內對大量的容器進行統一化的管理
伴隨著容器一起發展的是以容器為基礎衍生而出的容器編排、容器儲存、容器網路等領域，這些領域緊密結合形成了“雲原生”生態，並且在 2015 年開始，圍繞著 K8S 逐步形成了一套完整的“雲原生作業系統”。通過 K8S，使用者可以在一個分散式叢集內快速、高效地部署容器，無需再去關注複雜的叢集資源分配、容器排程等工作。為了完整地支援 K8S，雲廠商也進行了大量的 K8S 的支撐對接，紛紛提供適配自身 I 層基礎設施的 CNI（Container Network Interface）、CSI（Container Storage Interface）以及相對應的 cluster-autoscaler 等元件，讓 K8S 可以完美的管理自己的儲存、網路、計算資源。
- 體積臃腫：傳統的作業系統為了相容不同的使用場景，包含了各種各樣的硬體驅動、軟體包、系統庫、系統服務等，作業系統後臺服務繁多，體積也顯得龐大。在雲原生容器場景下，必要的服務大都已經被容器化，以容器的方式被部署到節點上，通過容器的方式來實現版本、配置的管理，逐步取代了傳統 OS 上的系統服務；同時，雲上硬體資源通過雲廠商的虛擬化抽象往往更加地簡化，並不需要去支援各種硬體。而容器映象本身就有執行時自包含的能力，因此很多傳統 OS 上的能力會顯得厚重而冗餘，這些厚重的元件還會使整個 OS 啟動變慢並佔用相當的系統資源（CPU、記憶體等）。
- 版本零散：為了能夠支援不同的訴求，作業系統提供了各種各樣不同的軟體，並以軟體包為粒度進行版本管理，每個軟體包有自己獨立的功能以及程式碼、版本號，由使用者根據自身的需求進行軟體包的增、刪。這樣每臺宿主機上的 OS 狀態是由大量不同軟體包版本號組成的，而在日常運維時一般是針對某一個軟體包進行管理。在雲原生的場景下，叢集計算節點日趨增多，生產過程中由於 bugfix、問題定位等可能在某一節點上針對某個包進行管理（升級、配置修改等），如果沒有一套完整的叢集 OS 運維機制，極容易出現叢集內 OS 狀態不統一的情況，如果在灰度的過程中出現依賴元件版本不一，可能會導致整個釋出流程受阻，給運維人員帶來極大的困難。
- 安全風險：一方面，傳統作業系統包含了大量雲原生場景下不需要的軟體包和系統服務，帶來更大的攻擊面。另一方面，傳統作業系統的運維人員大多通過 ssh 登入進系統進行黑屏的運維操作，過程難以追溯，誤操作極易帶來災難性的後果。
以上的問題主要還是體現在運維上，這時我們回頭看下，在 docker 出現之前，應用的運維人員也有類似的問題：如何保障應用在不同條件下執行環境的匹配一致、如何便捷快速地管理應用等。而 docker 很好地解決了應用層的問題，那是不是我們可以借鑑 docker 的思路來解決 OS 運維的問題？
其實在業界已經有了一些容器優化版作業系統，即我們常說的 ContainerOS，包括 AWS 的 bottlerocket、Redhat 的 Fodera CoreOS 以及 Rancher 的 RancherOS 等，它們大多具有以下特點：
- 輕量化：作業系統僅僅包含足夠支撐容器執行所需的軟體包與系統服務，大大減少攻擊面，啟動快。
- 原子升級回滾：基於不可變基礎設施的設計原則，提供只讀根檔案系統保證系統不被惡意篡改，作業系統的管理以映象為粒度，不提供 YUM 等包管理軟體，整個系統以映象為粒度進行升級與回滾。Bottlerocket 採用了 A/B 雙分割槽的方式實現映象的原子升級，CoreOS 則通過 rpm-ostree 像管理一個 git 程式碼倉一樣管理一個 OS 版本，而 RancherOS 則更加激進地把所有的系統服務全部容器化，實現用容器"管理"作業系統映象。
- 預設整合雲原生元件：預設安裝 docker/containerd/kubernetes 等雲原生元件，作業系統開箱即用，不需要使用者進行額外的安裝操作，簡單易用。
- 受控的運維通道：系統去除 sshd 服務，不允許直接登入系統進行運維，同時提供豐富的 API 介面用於主機的運維，另外還提供專用的運維容器作為最後的“退路”用以登入系統。
這些特點其實也印證了我們的思考：用映象的方式解決版本零散的問題，用 API 解決叢集運維的問題，而我們更是發現，如果可以把運維 API 化，那我們是不是可以把 OS 也作為一個 K8S 可以管理的資源，讓 K8S 像管理容器一樣管理OS？
LifseaOS：為雲而生的作業系統
基於以上的思考，我們推出了 LifSeaOS，一款為雲原生而生的 OS。
LifseaOS 使用了 rpm-ostree 的功能，實現映象的原子性升級回滾，讓使用者可以在叢集維度對 OS 映象進行 rolling upgrade，像管理牛群一樣管理一整個叢集的作業系統；同時做了大量的裁剪優化，使整體 OS 更輕、更快、更安全。
API 化運維更重要的作用是將 OS 運維往雲原生的方向牽引，我們可以通過一個 K8s 的 controller 對接運維 API，結合上述的 OS 版本化，讓 K8s 像管理一個容器一樣管理一個 HostOS。
當然，LifseaOS 的特徵不僅僅是以上描述的映象版本化和運維 API 化，它的名字也直接闡述了 LifseaOS 作為一個為雲而生、為容器而生的 OS 所具備的特質：
Lightweight
LifseaOS 預設整合 containerd、kubernetes 元件，僅僅保留 kubernetes pods 執行所需的系統服務與軟體包，整個系統大約只有 200 左右的軟體包，相比傳統作業系統（Alibaba Cloud Linux 2/3、CentOS）500+ 軟體包而言，數量減少 60%，更加的輕量。
繁重的 cloud-init（雲廠商常用的雲主機元資料管理元件）套件被替換為 CoreOS 的 Ignition，且裁剪了大量不需要的功能，僅保留最基礎的磁碟擴容、hostname 配置、chronyd 時區同步伺服器配置與執行 user-data 指令碼的功能。去除了不必要的核心模組、 systemd 服務（比如 systemd-logind、systemd-resolved）以及 systemd 附帶的許多實用性極低的小工具。
Fast
LifseaOS 的定位是跑在雲上虛擬機器的作業系統，所以不會涉及到太多的硬體驅動，必要的核心驅動模組修改為 built-in 模式，去除了 initramfs，udev 規則也被大大簡化，這樣，啟動速度得到了大幅提升，以 ecs.g7.large 規格的 ECS 例項為例，LifseaOS 的首次啟動時間保持在 2s 左右：
LifseaOS 根檔案系統為只讀許可權，只有 /etc 和 /var 目錄可寫以滿足基礎的系統配置需求。這種設計既符合雲原生場景下的基礎設施不可變原則，又能防止逃逸容器篡改主機檔案系統。不支援 python 但仍然保留了 shell（因為 ACK 在叢集部署階段需要執行一系列的 shell 指令碼來進行初始化工作，後續會考慮進一步去除）。
另外，LifseaOS 去除了 sshd 服務，禁止使用者直接登入到系統中進行一系列可能無法追溯的操作；當然，考慮到特殊運維或者緊急運維的需要，LifseaOS 仍然提供一個專用的運維容器滿足非日常的運維需求，運維容器需要通過 API 按需拉起，預設不開啟。
Atomic
LifseaOS 不支援單個 rpm 包的安裝、升級和解除安裝，不提供 yum，所以去除了 Fedora CoreOS 裡的 rpm-ostree 軟體包而僅保留 ostree 的功能（前者提供了以 rpm 包為粒度的管理功能，而後者僅僅管理檔案）。以整個映象為粒度的更新和回滾極大程度上保證整個叢集內的各個節點的軟體包版本與系統配置的一致性。每個映象經過內部嚴格的測試之後才會上線，相較於傳統作業系統基於單個 rpm 包的升級帶來的不確定性，以映象為粒度的測試釋出更能保證升級後系統的穩定性。
原文連結
本文為阿里雲原創內容，未經允許不得轉載。