KubeOS：面向云原生場景的容器操作系統(tǒng)

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

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

分享主要分為三部分：

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

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

3. 未來的工作。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

未來的工作

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

審核編輯：郭婷