簡介：如果可以把運維 API 化，那我們是不是可以把 OS 也作為一個 K8S 可以管理的資源，讓 K8S 像管理容器一樣管理OS？

引言

在 2021 年 10 月的云棲大會上，為云原生而生的 OS Lifsea 正式對外發布，并集成進入阿里云容器服務 ACK Pro 的托管節池，成為可選的操作系統選項。

不久前，LifseaOS 核心代碼正式在龍蜥社區開源，用戶可以基于 LifseaOS 開源代碼構建、定制一個屬于自己的容器專屬 OS。

WHY LifseaOS？

說到 LifseaOS，不得不提到其主要面向的場景：容器。

從最早的 UNIX chroot，到 Linux 的 LXC，早期以 cgroup、namespace 為基礎的容器運行時技術一直在持續演進，但并沒有出現階段性的突破。直到 2013 年，docker 的出現直接推進了容器的快速普及，經過短短幾年的發展，容器已經成為了主流的 IT基礎設施技術被廣泛地應用。容器的快速發展 docker 功不可沒，而我們回顧當時 docker 最初的工作，可以發現其并沒有進行顛覆性的技術變革，其核心創新主要包括以下兩個部分：

• 定義了容器分層鏡像標準以及鏡像倉庫：容器鏡像將應用運行環境，包括代碼、依賴庫、工具、資源文件和元信息等，打包成一種操作系統發行版無關的不可變更軟件包
• 定義了覆蓋容器全生命周期 restful API：restful API 的將整個容器的創建、監控、銷毀過程標準化，部署、運維人員可以在一個集群內對大量的容器進行統一化的管理

這兩個關鍵創新帶來了整個開發、集成、部署的革命。首先鏡像能力為 devops 提供了一條便捷的道路，開發人員可以在開發過程中便完成對于整個運行環境的把控，將自己開發成果直接上線部署生產投入，無需再去考慮操作系統兼容、庫依賴等環境因素，實現了 docker 的口號“Build，Ship and Run Any App，Anywhere”。其次，restful API 出現使得容器的生命周期管理愈加的便捷，利用編排工具對容器的管理，SRE 可以快速、無差別地進行應用的部署、升級、下線，實現了針對應用管理由“寵物”到“牛群”的質的飛越。

伴隨著容器一起發展的是以容器為基礎衍生而出的容器編排、容器存儲、容器網絡等領域，這些領域緊密結合形成了“云原生”生態，并且在 2015 年開始，圍繞著 K8S 逐步形成了一套完整的“云原生操作系統”。通過 K8S，用戶可以在一個分布式集群內快速、高效地部署容器，無需再去關注復雜的集群資源分配、容器調度等工作。為了完整地支持 K8S，云廠商也進行了大量的 K8S 的支撐對接，紛紛提供適配自身 I 層基礎設施的 CNI（Container Network Interface）、CSI（Container Storage Interface）以及相對應的 cluster-autoscaler 等組件，讓 K8S 可以完美的管理自己的存儲、網絡、計算資源。

在基礎設施紛紛“云原生化”的過程中，有一個同屬于 Infra 的組件卻步驟緩慢，這就是操作系統，也就是我們一直說的 OS。雖然存在感并不是很強，但是 OS 作為下接硬件、上接業務的底層軟件，默默地為應用提供了單機資源管理、運行環境構建等能力，發揮著舉足輕重的作用。但是在云原生場景下，傳統操作系統已經逐漸表現出各種“不適”：

• 體積臃腫：傳統的操作系統為了兼容不同的使用場景，包含了各種各樣的硬件驅動、軟件包、系統庫、系統服務等，操作系統后臺服務繁多，體積也顯得龐大。在云原生容器場景下，必要的服務大都已經被容器化，以容器的方式被部署到節點上，通過容器的方式來實現版本、配置的管理，逐步取代了傳統 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 延續了 CoreOS rpm-ostree 的技術流派，基于由龍蜥社區(OpenAnolis)發布的龍蜥操作系統(Anolis OS) 作為軟件包選型基礎。

LifseaOS 使用了 rpm-ostree 的功能，實現鏡像的原子性升級回滾，讓用戶可以在集群維度對 OS 鏡像進行 rolling upgrade，像管理牛群一樣管理一整個集群的操作系統；同時做了大量的裁剪優化，使整體 OS 更輕、更快、更安全。

同時，我們提供了一個用于 OS 運維的小工具（功能還在持續豐富中），將常規的 OS 運維抽象出來并進行收斂，借助阿里云云助手或自動化運維編排服務，用戶針對 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 左右：

傳統的操作系統，以 Alibaba Cloud Linux 3 為例，首次啟動時間則在 1min 以上：

Security

LifseaOS 根文件系統為只讀權限，只有 /etc 和 /var 目錄可寫以滿足基礎的系統配置需求。這種設計既符合云原生場景下的基礎設施不可變原則，又能防止逃逸容器篡改主機文件系統。不支持 python 但仍然保留了 shell（因為 ACK 在集群部署階段需要執行一系列的 shell 腳本來進行初始化工作，后續會考慮進一步去除）。

另外，LifseaOS 去除了 sshd 服務，禁止用戶直接登錄到系統中進行一系列可能無法追溯的操作；當然，考慮到特殊運維或者緊急運維的需要，LifseaOS 仍然提供一個專用的運維容器滿足非日常的運維需求，運維容器需要通過 API 按需拉起，默認不開啟。

Atomic

LifseaOS 不支持單個 rpm 包的安裝、升級和卸載，不提供 yum，所以去除了 Fedora CoreOS 里的 rpm-ostree 軟件包而僅保留 ostree 的功能（前者提供了以 rpm 包為粒度的管理功能，而后者僅僅管理文件）。以整個鏡像為粒度的更新和回滾極大程度上保證整個集群內的各個節點的軟件包版本與系統配置的一致性。每個鏡像經過內部嚴格的測試之后才會上線，相較于傳統操作系統基于單個 rpm 包的升級帶來的不確定性，以鏡像為粒度的測試發布更能保證升級后系統的穩定性。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的一款跑在云上的定制容器专属 OS 来了——LifseaOS | 龙蜥技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。