在云原生場景下，容器和 Kubernetes 在開發(fā)、測試、生產(chǎn)中的應(yīng)用越來越廣泛，傳統(tǒng)的操作系統(tǒng)往往會(huì)帶來安全性、運(yùn)維開銷、OS 版本等方面的問題，容器操作系統(tǒng)即容器 OS 是針對(duì)云原生場景設(shè)計(jì)的一種輕量化操作系統(tǒng)。本次分享首先介紹容器 OS 的理念，然后分享在 openEuler 社區(qū)孵化的容器操作系統(tǒng) KubeOS 的設(shè)計(jì)思路和解決的問題，最后深入介紹 KubeOS 的架構(gòu)、功能和使用。

本文整理自華為操作系統(tǒng)開發(fā)工程師、KubeOS 開源項(xiàng)目負(fù)責(zé)人李元戎在DIVE全球基礎(chǔ)軟件創(chuàng)新大會(huì)2022的演講分享，主題為“KubeOS : 面向云原生場景的容器操作系統(tǒng)”。

分享主要分為三部分：

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

2.KubeOS:?向云原?場景的容器操作系統(tǒng)；

3. 未來的工作。

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

現(xiàn)在說起容器，大家想到的基本上都是 Docker。

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

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

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

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

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

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

可以說容器和 Kubernetes 促進(jìn)了云原生生態(tài)的發(fā)展，在基礎(chǔ)設(shè)施紛紛云化的情況下，云原生場景下 OS 管理的問題也就隨之而來了。

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

第二個(gè)問題就是 OS 的版本管理問題。一個(gè)通用的 Linux 操作系統(tǒng)，一般都會(huì)內(nèi)置一個(gè)軟件更新升級(jí)的包管理器，通過這個(gè)包管理器，每一個(gè)包獨(dú)立進(jìn)行安裝、升級(jí)、刪除，這對(duì)于操作系統(tǒng)來說非常靈活。

但是在云原生場景下，往往會(huì)帶來版本分裂的問題。就像圖中所示，一開始這個(gè)集群中兩個(gè)節(jié)點(diǎn)的包版本都是一致的。但是隨著使用，有的包升級(jí)了，有的包沒升級(jí)，或者升級(jí)的版本不一致。時(shí)間久了集群中每一臺(tái)節(jié)點(diǎn)都會(huì)有不同的軟件包，不同的版本，這樣造成的版本分裂問題是很嚴(yán)重的。

如果 OS 和業(yè)務(wù)耦合比較緊密的話，OS 進(jìn)行大版本的升級(jí)也會(huì)比較困難。業(yè)界比較主流的思想是通過改造 OS 來解決以上問題。因?yàn)槿萜靼褢?yīng)用運(yùn)行所需要依賴的環(huán)境都打包到了容器鏡像里面。它對(duì)一個(gè)操作系統(tǒng)所需要的功能越來越少，所以就有了輕量級(jí)的操作系統(tǒng)。為了容器運(yùn)行而設(shè)計(jì)的這種輕量級(jí)操作系統(tǒng)，我們叫它為容器 OS，也就是 Container OS，也可以叫做 Container specific OS。

那么對(duì)一個(gè)容器 OS 來說，都需要它有什么呢？首先肯定是有一個(gè) Linux kernel，然后要有容器引擎，比如 Docker，然后還需要一些安全的機(jī)制，這些就夠了。所以容器 OS 第一個(gè)特點(diǎn)就是極簡化，它包含的軟件包比較少，相應(yīng)的攻擊面和漏洞肯定就少，容器 OS 就更安全。第二個(gè)特點(diǎn)是不可變，只有在部署的時(shí)候可以修改，一旦部署就是固定的。第三個(gè)是原子更新，因?yàn)樗豢勺儯灾荒苷w進(jìn)行更新。最后是應(yīng)用以容器的形式運(yùn)行。

KubeOS:?向云原?場景的 容器操作系統(tǒng)

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

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

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

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

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

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

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

當(dāng)集群中 OS 的狀態(tài)發(fā)生了變化以后，OS Operator 就會(huì)感知到這個(gè)變化，去查詢集群中所有節(jié)點(diǎn)的狀態(tài)，若發(fā)現(xiàn)和當(dāng)前節(jié)點(diǎn)的狀態(tài)不一致，就會(huì)把需要升級(jí)的節(jié)點(diǎn)標(biāo)記為升級(jí)節(jié)點(diǎn)，相當(dāng)于把任務(wù)下發(fā)到各個(gè)節(jié)點(diǎn)了。

OSProxy 監(jiān)控發(fā)現(xiàn)當(dāng)前的節(jié)點(diǎn)被標(biāo)記為升級(jí)節(jié)點(diǎn)了，就開始執(zhí)行升級(jí)操作，從集群中獲取要升級(jí)到的 OS 的版本，它把當(dāng)前節(jié)點(diǎn)的所有 Pod 進(jìn)行驅(qū)逐，并把當(dāng)前節(jié)點(diǎn)鎖定，把 OS 的信息發(fā)送給 OS Agent，Os Agent 接收到相關(guān)的信息以后，從一開始用戶指定的升級(jí)鏡像存放的服務(wù)器下載鏡像，然后設(shè)置啟動(dòng)分區(qū)，進(jìn)行重啟和升級(jí)。升級(jí)以后 OS Proxy 看當(dāng)前節(jié)點(diǎn)的狀態(tài)發(fā)現(xiàn)已經(jīng)升級(jí)完成了，就把當(dāng)前節(jié)點(diǎn)重新解鎖，并且取消升級(jí)標(biāo)記。

未來的工作

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

審核編輯：郭婷