在云原生場景下，容器和 Kubernetes 在開發、測試、生產中的應用越來越廣泛，傳統的操作系統往往會帶來安全性、運維開銷、OS 版本等方面的問題，容器操作系統即容器 OS 是針對云原生場景設計的一種輕量化操作系統。本次分享首先介紹容器 OS 的理念，然后分享在 openEuler 社區孵化的容器操作系統 KubeOS 的設計思路和解決的問題，最后深入介紹 KubeOS 的架構、功能和使用。

本文整理自華為操作系統開發工程師、KubeOS 開源項目負責人李元戎在DIVE全球基礎軟件創新大會2022的演講分享，主題為“KubeOS : 面向云原生場景的容器操作系統”。

分享主要分為三部分：

1. 云原?場景下 OS 管理問題與解決?法；

2.KubeOS:?向云原?場景的容器操作系統；

3. 未來的工作。

云原?場景下 OS 管理問題與解決?法

現在說起容器，大家想到的基本上都是 Docker。

Docker 在 2013 年開源以后就立即火爆了起來，可以說 Docker 將容器技術推向了巔峰。那么 Docker 技術到底解決了一個什么樣的問題呢？Docker 自己宣傳的口號是：一次構建到處運行。

它一舉解決了開發、測試、生產中環境不一致這困擾業界多年的問題。從更高的維度來說，Docker 其實解決的是軟件到底應該通過什么樣的方式進行交付。當軟件的交付方式變得清晰明確以后，那么我們做托管軟件的平臺也就變得非常簡單明了了。

Docker 提供了三個概念：容器、鏡像和鏡像倉庫，通過 Docker Client 可以以 Restful API 的方式去管理容器的全生命周期。那么 Docker 最核心的創新是什么呢？其實就是 Docker 鏡像這個概念，通過 Docker 容器鏡像，可以將一個應用軟件運行依賴的全部環境都打包在一起，讓這個程序通過 Docker 容器運行的時候可以與操作系統是無關的。這樣也就基本上實現了它所宣傳的 run anywhere。

Docker 鏡像為了可以共享資源，在制作過程中引入了層的概念。也就是說如果想做一個新的容器鏡像，不需要從頭開始做，只需要找到一個有 Root FS 的 Base Image ，以后需要什么就可以一層一層的往上疊加。Docker 容器其實也是基于分層概念，容器運行的時候它就會在鏡像上面增加一個可寫層，也就是我們常說的容器層，然后容器層下面是鏡像層，鏡像層都是只讀的。容器鏡像的一個核心的特性就是 copy on right，可以把對于容器的修改全限制在容器層下，不會影響其他共享這個鏡像的容器。Docker 在單機上的打包、發送、運行的性能是很優秀的，但只在單機上運行并不能發揮它最大的價值。業界更希望基于 Docker 技術可以形成云化的集群系統，然后進行業務容器的調度和編排。那我們就要說接下來的 Kubernetes 了。

Kubernetes 現在可以說已經真正成為了全球的主流技術。2017 年的時候，Kubernetes、Swarm 和 Mesos 三家容器編排系統的大戰就基本上結束了，Kubernetes 成為了最后的贏家，成為了容器編排系統的事實標準。Kubernetes 的思想是將一切都視為資源，比如說 node、POD、deployment、service，這些日常的、內置的資源對于一般的系統部署升級和管理是夠用的。但是在一些特定的場景下，當內置的資源不滿足需求的時候，Kubernetes 又提供了一種擴展的機制，你可以把需要的新資源抽象成 Kubernetes 的 API 對象，然后注冊到集群中，和其他資源一起來使用，即 CRD 機制。說起 CRD 就不得不提 operator。其實從 Kubernetes 的設計和定義來看，它其實似乎更適用于無狀態的應用。

但是 CoreOS 公司它基于 Kubernetes 的聲明式 API 機制提出的 Kubernetes operator 可以有效解決有狀態的應用或者是分布式應用的狀態描述，在 operator 當中的 API 對象不再是描述單狀態應用的狀態，而是去描述分布式應用集群的狀態。也就是說它把一個完整的分布式應用的集群都算作 Kubernetes 它需要最終去維護的這種最終的狀態。當你定義的分布式應用集群的狀態發生改變以后，operator 會根據實現代碼去執行相應的邏輯功能，然后達到向我們預期的狀態不停演進的功能。

可以說容器和 Kubernetes 促進了云原生生態的發展，在基礎設施紛紛云化的情況下，云原生場景下 OS 管理的問題也就隨之而來了。

首先是 Kubernetes 并不能對集群節點的 OS 進行管理，所以云原生場景下 OS 管理的第一個問題，Kubernetes 和 OS 是分別獨立進行管理的。Kubernetes 也需要進行更新維護，然后進行用戶權限控制，這和 OS 的管理其實非常類似。所以當運維人員分別對 Kubernetes 和 OS 進行管理的時候，他往往需要進行很多冗余操作。按理來說是希望它們互相能夠感知的，但是實際上這兩套系統互相協調非常困難，甚至它們之間根本就沒有協調。所以當 OS 升級影響到了節點可用性的時候，Kubernetes 無法進行感知。如果 OS 進行升級，又希望集群中業務不中斷，運維人員首先需要鎖定節點，讓工作負載不再分配到這個節點，然后需要把這個節點上的 POD 調入到其他節點，然后才能去升級這個節點，最后再把這個節點解鎖，恢復正常的應用，這無疑增加了運維的難度和開銷。

第二個問題就是 OS 的版本管理問題。一個通用的 Linux 操作系統，一般都會內置一個軟件更新升級的包管理器，通過這個包管理器，每一個包獨立進行安裝、升級、刪除，這對于操作系統來說非常靈活。

但是在云原生場景下，往往會帶來版本分裂的問題。就像圖中所示，一開始這個集群中兩個節點的包版本都是一致的。但是隨著使用，有的包升級了，有的包沒升級，或者升級的版本不一致。時間久了集群中每一臺節點都會有不同的軟件包，不同的版本，這樣造成的版本分裂問題是很嚴重的。

如果 OS 和業務耦合比較緊密的話，OS 進行大版本的升級也會比較困難。業界比較主流的思想是通過改造 OS 來解決以上問題。因為容器把應用運行所需要依賴的環境都打包到了容器鏡像里面。它對一個操作系統所需要的功能越來越少，所以就有了輕量級的操作系統。為了容器運行而設計的這種輕量級操作系統，我們叫它為容器 OS，也就是 Container OS，也可以叫做 Container specific OS。

那么對一個容器 OS 來說，都需要它有什么呢？首先肯定是有一個 Linux kernel，然后要有容器引擎，比如 Docker，然后還需要一些安全的機制，這些就夠了。所以容器 OS 第一個特點就是極簡化，它包含的軟件包比較少，相應的攻擊面和漏洞肯定就少，容器 OS 就更安全。第二個特點是不可變，只有在部署的時候可以修改，一旦部署就是固定的。第三個是原子更新，因為它不可變，所以只能整體進行更新。最后是應用以容器的形式運行。

KubeOS:?向云原?場景的 容器操作系統

近幾年容器 OS 又有了新的發展，Kubernetes OS 除了剛才講的容器 OS 的特征以外，最顯著的特征是集成了 Kubernetes 的某些社區版本。它會把 OS 的管理交由 Kubernetes 去控制，由 Kubernetes 來控制 OS 的更新。其實業界已經有一些主流的操作系統公司推出了這樣的容器 OS，KubeOS 就是 openEuler 推出的這樣一款容器 OS。

KubeOS 的鏡像都是基于 openEuler Repo 源進行構造的。KubeOS 部署以后，用戶可以在 master 節點上只通過命令行和 yaml 文件就去管理集群所有 worker node 上面的 OS 版本。因為 KubeOS 將 OS 作為 Kubernetes 的一個組件接入到集群中, 這樣 OS 和其它的業務容器就位于同等地位，可以通過 Kubernetes 統一去管理容器和 OS，實現 OS 和業務容器的協同調度。并且我們還基于 openEuler 的版本進行了一些定制化的改造，讓 KubeOS 可以進行原子化更新升級，避免版本分裂的問題。

下面對 KubeOS 進行一個詳細的介紹。KubeOS 的第一個特性是將 OS 作為組件接入到 Kubernetes 中。我們利用 Kubernetes 的 API 擴展機制為 OS 設計了一個 CRD 的 API 對象，然后把它注冊到集群中，并且依托于 Kubernetes 的 operator 擴展機制定義了一個 OS controller，去對之前注冊那個 OS 對象進行管理和監控。這樣就讓 OS 和集群中其他的內置資源處于同等地位，都可以通過 kubernetes 進行管理。用戶只需要修改 OS 的 CR，然后輸入預期的 OS 版本和狀態，其他操作都可以由 KubeOS 和 Kubernetes 完成。這樣 OS 的管理就在云端進行了。

KubeOS 的第二個特性是 OS 是進行原子升級的，KubeOS 中不提供包管理器，軟件包的變化即 OS 版本的變化，也就是說每一個 OS 的版本都會對應一個確定的 OS 鏡像，或者說一組確定的 RPM 包的組合。如圖所示，軟件包的更新即為 OS 版本的更新，這樣可以讓任何時候集群中的 OS 的版本是確定的、一致的，有助于大規模應用的部署。并且我們 OS 是盡量輕量化的，只包含 Kubernetes 和容器運行所需要的組件，這樣不僅減少攻擊面，讓 OS 更加安全，也可以進行快速的更新，快速的升級。

如圖是 KubeOS 的架構設計，KubeOS 一共分成三個模塊，第一個模塊 OS operator 部署在 master 節點上的，它是全局的 OS 管理器，會監控集群中所有節點的 OS 的狀態。當用戶去更改集群中 OS 信息的時候，比如說指定了新的版本，Operator 會感知到，然后把升級任務下發到各個節點上。OSProxy 它就是部署在每一個節點上，它就是單節點的 OS 管理器，會監控當前節點的狀態，當他接到 Operator 下發的升級任務時，會去做比如說封鎖節點、遷移 Pod 這些操作，并且把需要升級的 OS 信息轉發給 OS Agent，OS Agent 是真正的 OS 升級的執行單元，它接收來自于 OS Proxy 的相關信息，完成升級和重啟操作。

如圖是 KubeOS 的文件系統布局的設計，首先是 Root 分區，因為 KubeOS 我們采用了雙分區升級的方式，每一個分區它會存放一個 OS 的版本，所以說分成了 RootA 和 RootB，每次升級的時候會下載 OS 鏡像到另外一個分區，在下次啟動的時候將啟動目錄切換到另外一個分區，就完成了雙分區的升級，并且 KubeOS 文件系統是只讀的，這也是為了安全性的考慮，但是我們還是提供了一個 persist 分區，用它存放持久性的用戶數據，它其中有一個 Union Path，它采用 overlay 的形式，在鏡像上增加疊加層，還有一個 Writable Path，它主要使用 bind mount 形式，直接在鏡像上面增加了一個可寫層，最后是 Boot 分區，存放的是 grub2 文件。

最后我們再介紹一下 KubeOS 的升級流程。首先第一步，用戶通過修改 OS 的 Yaml 文件，指定要升級的 OS 信息，比如 OS 的版本、存放鏡像的地址，以及一次升級的 OS 的數量。

當集群中 OS 的狀態發生了變化以后，OS Operator 就會感知到這個變化，去查詢集群中所有節點的狀態，若發現和當前節點的狀態不一致，就會把需要升級的節點標記為升級節點，相當于把任務下發到各個節點了。

OSProxy 監控發現當前的節點被標記為升級節點了，就開始執行升級操作，從集群中獲取要升級到的 OS 的版本，它把當前節點的所有 Pod 進行驅逐，并把當前節點鎖定，把 OS 的信息發送給 OS Agent，Os Agent 接收到相關的信息以后，從一開始用戶指定的升級鏡像存放的服務器下載鏡像，然后設置啟動分區，進行重啟和升級。升級以后 OS Proxy 看當前節點的狀態發現已經升級完成了，就把當前節點重新解鎖，并且取消升級標記。

未來的工作

我們接下來要做什么？首先我們需要去不斷豐富 KubeOS 的功能，比如提供系統配置下發的功能，提供更多的安全策略。第二點是要不斷完善，比如更全面的支持，提供支持更多的架構，更多的容器引擎等等。還有就是讓 KubeOS 的使用和部署變得更加方便，比如提供一鍵式的部署。

審核編輯：郭婷