摘要：在這一假設(shè)之下，是一個(gè)新奇的觀點(diǎn)編排才是容器生態(tài)的中心，而引擎就我們所知，只是一個(gè)開(kāi)發(fā)工具。是特有的概念，但容器生態(tài)系統(tǒng)必須采用這個(gè)概念。

開(kāi)源項(xiàng)目 CRI-O ，其前身為 OCID ，官方簡(jiǎn)介是“ OCI-based implementation of Kubernetes Container Runtime Interface ”。作為接口，它使得 Kubernetes 不依賴(lài)于傳統(tǒng)的容器引擎（比如 Docker ），也能夠管理容器化工作負(fù)載。

該項(xiàng)目通過(guò)與 Kubernetes （或其商業(yè)版 CoreOS Tectonic ）協(xié)作，可以幫助 DevOps 人員來(lái)管理容器的整個(gè)“生命周期”。

開(kāi)發(fā)人員需要使用容器引擎構(gòu)建鏡像，通常情況下更喜歡用自己的 staging 環(huán)境做本地測(cè)試。但是管理和運(yùn)營(yíng)人員會(huì)發(fā)現(xiàn)，相對(duì)于標(biāo)準(zhǔn)容器引擎， Kubernetes 技術(shù)棧（比如編排系統(tǒng)、 CRI 和 CRI-O ）更適合用來(lái)管理復(fù)雜的生產(chǎn)環(huán)境。

該項(xiàng)目將編排工具放在容器技術(shù)棧的重要位置，同時(shí)降低了容器引擎的重要性。 CRI 的一個(gè) Contributor 說(shuō)，讓 Kubernetes 支持任意容器引擎，在理念上與 Open Container Initiative 一脈相承。容器引擎可以是 docker 或 CoreOS 的 rkt ，或 OCI 的 runc （它可以做很多如 Docker 或 CoreOS rkt 這類(lèi)容器可以做的事情，比如從 registry 拉鏡像，但它不會(huì)從 makefile 構(gòu)建鏡像）。

「 盡管 Open Container Initiative 類(lèi)似的部分已經(jīng)與 CRI-O 的職責(zé)區(qū)別越來(lái)越大，兩個(gè)項(xiàng)目的成員、貢獻(xiàn)者和廠商也有很大重合，但 CRI-O 仍然是 OCI 的自然延伸，它為容器引擎和鏡像提供了一套標(biāo)準(zhǔn)接口。」， Kubernetes 工程師 Kelsey Hightower 在 The New Stack 的采訪中說(shuō)道。

CRI-O 項(xiàng)目的設(shè)想是用戶(hù)不應(yīng)該依賴(lài)任何特定的容器引擎去完成工作負(fù)載。按照最初的設(shè)想，該項(xiàng)目將為 Kubernetes 提供一個(gè)工具集，使其能夠管理容器的整個(gè)生命周期，而不需要 Docker 、 rkt 、 OpenShift 、 Photon 或任何其他容器引擎。

「 我們對(duì)容器引擎的功能要求很少，不管是 Docker 還是 rkt ，它們要做的工作都很少 」， Hightower 說(shuō)，「 我們需要的是訪問(wèn)內(nèi)核的 API ，不僅僅針對(duì) Linux ，也可以是 Windows 。如果這是社區(qū)想要去的方向， Kubernetes 就要支持這些想法-因?yàn)樵谶@一點(diǎn)上它比 Docker 公司更大 」。

在這一假設(shè)之下，是一個(gè)新奇的觀點(diǎn)：編排才是容器生態(tài)的中心，而“引擎”就我們所知，只是一個(gè)開(kāi)發(fā)工具。

另一方面， CRI （通用容器接口 API 和 Kubernetes ）將給容器引擎廠商一個(gè)機(jī)會(huì)，以便接入 Kubernetes 系統(tǒng)。運(yùn)行容器的環(huán)境中，只要暴露出適當(dāng)?shù)倪B接，不需要容器引擎進(jìn)行代碼重構(gòu)就可以兼容 Kubernetes 。

其中一個(gè)方式是，在容器引擎和編排工具中間實(shí)現(xiàn)一個(gè)抽象層，容器廠商如何實(shí)現(xiàn)這一層完全取決于他們自己。

容器引擎中間層實(shí)現(xiàn)以后， CRI API （與 Kubernetes 連接的部分）將把更多的容器生命周期控制權(quán)交給 kubelet —— pod 的管理者。 Pod 是 Kubernetes 特有的概念，但容器生態(tài)系統(tǒng)必須采用這個(gè)概念。

對(duì)于 Kubernetes ，下一個(gè)版本的目標(biāo)是 1.5 版本，包括 CRI 的最終版，允許 kubelet 與 Docker ， rkt 、 Hyper.sh （中國(guó)團(tuán)隊(duì)開(kāi)發(fā)）以及 CRI-O （ RedHat 領(lǐng)導(dǎo)開(kāi)發(fā)）進(jìn)行通信。

“關(guān)于如何與 Kubernetes 通信，很多不同的容器引擎都非常感興趣”， Philips 說(shuō)，“與其在 kubelet 中為每一個(gè)容器引擎構(gòu)建一個(gè)接口，我們創(chuàng)造了一個(gè)更抽象的接口，允許容器引擎去接入而不用直接參與 Kubernetes 的工作?！?/p> 誰(shuí)需要重構(gòu)，重構(gòu)什么？

Hightower 將 CRI （“ CRI ”在“ CRI-O ”之前）描述為一個(gè)抽象的概念，代表容器引擎應(yīng)該支持的基本特性，而 Kubernetes 可以用來(lái)驗(yàn)證這些特性。一旦 CRI 完成，將重構(gòu) Kubernetes 代碼以實(shí)現(xiàn) CRI 。

如果 CRI-O 成功，容器引擎廠商不需要對(duì)引擎代碼庫(kù)進(jìn)行修改，就可以簡(jiǎn)單地與 Kubernetes 交互。

“現(xiàn)在，如果你想很 happy 地玩耍 Kubernetes ，必須構(gòu)建一堆東西，而且可能修改你目前的做事方式”， Hightower 說(shuō)，“你查看現(xiàn)有的代碼庫(kù)，看看為 Docker 做了哪些東西。在某種程度上，你需要付出類(lèi)似的努力，去修改適合你的運(yùn)行時(shí)引擎，從而與 Kubernetes 很好的配合?！?/p>

就像 CoreOS 的 Philips 解釋的一樣，每個(gè)容器引擎將利用一個(gè)中間層—— 它能夠?qū)⑷萜饕娴?API 請(qǐng)求，轉(zhuǎn)化成 Kubernetes 可以處理的形式。

“考慮到 CRI 的運(yùn)行機(jī)制，你需要一個(gè) GRPC daemon 去監(jiān)聽(tīng)請(qǐng)求”， Philips 說(shuō)，“它能與 kubelet 通信；反過(guò)來(lái)， kubelet 可以通過(guò) socket 對(duì)實(shí)現(xiàn) CRI 的引擎發(fā)送一個(gè)遠(yuǎn)程調(diào)用”。

Philips 說(shuō)，“目前對(duì) Docker 和 rkt 的支持將被合并到 CRI 接口”。 CoreOS rkt 對(duì) CRI 的實(shí)現(xiàn)目前已經(jīng)在 Github 上開(kāi)源，項(xiàng)目名稱(chēng)為 rktlet 。不管是 rktlet ，還是 Docker 對(duì) CRI 的實(shí)現(xiàn)（不管將來(lái)叫什么名字），他預(yù)計(jì)都被重構(gòu)為 CRI 。

Google 的 Hightower 說(shuō)：“盡管 Docker 已經(jīng)要求與 Kubernetes 一起實(shí)現(xiàn)中間層，最終仍然是 Google 的工程師去實(shí)現(xiàn)，而不是 Docker 的。 Philips 也表示，不管誰(shuí)去實(shí)現(xiàn)中間層， Docker 和其它容器引擎廠商遵循同樣的規(guī)則，都不能搞特權(quán)。

“為了與 CRI 集成， Docker Engine 和 rkt Engine 都處在不斷變化中”， Brandon Philips 如是說(shuō)。

OCI 鏡像格式的最終標(biāo)準(zhǔn)還沒(méi)有確定， OCI 發(fā)言人也表明 OCI 鏡像格式 1.0 發(fā)布之前還有兩個(gè)迭代版本。

同時(shí)， Docker 在不斷增強(qiáng)其容器引擎的特性，并且捆綁了 Swarm 編排工具和服務(wù)發(fā)現(xiàn)。

“我認(rèn)為這一切進(jìn)展都不錯(cuò)，” Philips 說(shuō)，“人們可能不喜歡這樣——這很正常，每個(gè)人都可以有自己的觀點(diǎn)。對(duì)于 Kubernetes ，我們?nèi)匀粫?huì)提供一包東西。但我們?cè)趧?chuàng)造和改進(jìn)它時(shí)，不認(rèn)為它僅僅是一件商品（還有情懷）。

“前面我們談到 Pod ，為了正確地實(shí)現(xiàn)它，你還需要了解很多東西”， Hightower 說(shuō)，“把負(fù)擔(dān)推給容器引擎，讓它們?nèi)?xiě)一拖代碼才能與 kubernetes 愉快地玩耍，這一點(diǎn)對(duì)于每個(gè)容器引擎都很不公平。想想看：他們還要為 Mesos 和 Swarm 去實(shí)現(xiàn)類(lèi)似功能的代碼，想想都可怕。為了簡(jiǎn)化這部分功能，我們將把 Kubernetes 專(zhuān)屬的邏輯放到 kubelet 中；對(duì)于外部而言，通過(guò)一種友好的方式使用容器引擎本來(lái)就具備的特性。

假設(shè)這已經(jīng)是事實(shí)，現(xiàn)有容器引擎特性被隱藏在一個(gè)接口后面，該接口能夠?qū)?pod 為中心基于 kubelet 的邏輯從 kubernetes 隔離出來(lái)，與 Kubernetes 之外但有同樣 API 的編排工具交互，這個(gè)編排工具對(duì) API 可能有一套完全不同的實(shí)現(xiàn)方式（餅越來(lái)越大）。

我們和 Mesosphere 創(chuàng)始人 Ben Hindman 也探討了這種可能性。

“我認(rèn)為這個(gè)行業(yè)需要的是可拼湊的組件”， Hindman 對(duì) The New Stack 解釋說(shuō)。“在 Kubernetes 案例中，我認(rèn)為這很關(guān)鍵。 Kubernetes 依靠 Docker 做容器管理，并且他們嘗試構(gòu)建編排。當(dāng) Docker 整合 Swarm 時(shí)，他們不僅有一個(gè)容器管理器，也在做編排。僅僅從架構(gòu)的角度來(lái)看，這是非常合理的。我想說(shuō)的是：如果我們只做一個(gè)容器管理的組件，讓很多人可以利用，豈不是很更好？”

對(duì)于 Docker 公司有意向?qū)?runc 作為開(kāi)放標(biāo)準(zhǔn)， Hindman 非常認(rèn)同，但他也不忘吐槽：完整的編排不僅僅是與與容器引擎交互。

“還有很多，比如下載鏡像、鏡像打包、鏡像解包 —— 還有更多的事情必須去做。

對(duì)我來(lái)說(shuō)，我認(rèn)為行業(yè)中還在就一個(gè)問(wèn)題爭(zhēng)論：這些東西應(yīng)不應(yīng)該被分解和模塊化？它不僅僅是 fork the repo 那么簡(jiǎn)單，還需要在架構(gòu)上解釋得通?！盵 Ben Hindman ]。

Mesosphere 的 DC/OS 環(huán)境中也有這些組件做鋪墊， Hindman 解釋說(shuō)，已經(jīng)無(wú)需依賴(lài) runc 或任何 Docker 組件。容器社區(qū)的真正目標(biāo)，正如他所說(shuō)的，是在組件之間指定架構(gòu)層面上的邊界，并建立它們之間建立適當(dāng)?shù)慕涌凇?/p>

這是否意味著 Mesosphere 支持 CRI-O ， CRI-O 的目標(biāo)也如 Kelsey Hightower 向我們解釋的一樣，與 Hindman 預(yù)計(jì)的完全兼容嗎？

然而 Hindman 并不是為 OCI 吶喊，需要注意的是， Mesosphere 是 OCI 的創(chuàng)始成員之一。 OCI 的最初的目的是開(kāi)發(fā)一種通用的運(yùn)行時(shí)格式，讓 runc 能夠以容器的方式啟動(dòng)它。容器社區(qū)也關(guān)心鏡像格式，包括容器在非運(yùn)行狀態(tài)下的文件系統(tǒng)和元數(shù)據(jù)。所以 OCI 也接受這套理念。

“對(duì)于我們而言，鏡像格式比運(yùn)行時(shí)格式更有趣，也有意義” ， Hindman 說(shuō)，“ Mesosphere 之所以擁抱 universal containerizer ，原因是希望支持所有開(kāi)放格式的容器，包括 OCI ?！?/p>

但在這樣一個(gè)最佳架構(gòu)中，可能沒(méi)有方法去規(guī)范工作負(fù)載的調(diào)度器。不同調(diào)度器的特性可能千差萬(wàn)別。因此，如果以這種方式，努力通過(guò)一個(gè)文件描述工作負(fù)載（可能是配置文件、元數(shù)據(jù)文件或 manifest 文件），并且試圖對(duì)所有調(diào)度器通用，最終制定出來(lái)的標(biāo)準(zhǔn)可能滿足不了任何調(diào)度器的需求，進(jìn)而妨礙調(diào)度器本身特性的擴(kuò)展。

但是，確定一個(gè)通用鏡像格式則簡(jiǎn)單很多，最終取決于 Linux 是否支持該格式。“如果支持它，我們可以公開(kāi)它。在鏡像格式上，我認(rèn)為沒(méi)有太大的爭(zhēng)論，因此，把它作為一個(gè)標(biāo)準(zhǔn)就 OK ?！?/p>

Hindman 總結(jié)說(shuō)， Mesosphere 將繼續(xù)支持 OCI ，將來(lái)會(huì)以同樣的粒度支持 CRI-O 。但跟 CRI-O 相比， Mesosphere 的“ universal container runtime ”將以不同的方式被支持。

未來(lái)在編排領(lǐng)域，我們會(huì)看到一個(gè)激烈競(jìng)爭(zhēng)的市場(chǎng)，而不是容器引擎領(lǐng)域。

本文由時(shí)速云翻譯，如若轉(zhuǎn)載，需注明轉(zhuǎn)載自“時(shí)速云”

原文鏈接： http://thenewstack.io/cri-o-m...

——————————————————————————————————————————————————

◆◆◆ 對(duì)文章內(nèi)容有什么建議的小伙伴，歡迎留言~ ◆◆◆