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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果 CRI-O 成功，容器引擎廠商不需要對引擎代碼庫進行修改，就可以簡單地與 Kubernetes 交互。

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

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

“考慮到 CRI 的運行機制，你需要一個 GRPC daemon 去監(jiān)聽請求”， Philips 說，“它能與 kubelet 通信；反過來， kubelet 可以通過 socket 對實現(xiàn) CRI 的引擎發(fā)送一個遠程調(diào)用”。

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

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

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

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

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

“我認為這一切進展都不錯，” Philips 說，“人們可能不喜歡這樣——這很正常，每個人都可以有自己的觀點。對于 Kubernetes ，我們?nèi)匀粫峁┮话鼥|西。但我們在創(chuàng)造和改進它時，不認為它僅僅是一件商品（還有情懷）。

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

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

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

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

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

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

對我來說，我認為行業(yè)中還在就一個問題爭論：這些東西應(yīng)不應(yīng)該被分解和模塊化？它不僅僅是 fork the repo 那么簡單，還需要在架構(gòu)上解釋得通。”[ Ben Hindman ]。

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

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

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

“對于我們而言，鏡像格式比運行時格式更有趣，也有意義” ， Hindman 說，“ Mesosphere 之所以擁抱 universal containerizer ，原因是希望支持所有開放格式的容器，包括 OCI 。”

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

但是，確定一個通用鏡像格式則簡單很多，最終取決于 Linux 是否支持該格式。“如果支持它，我們可以公開它。在鏡像格式上，我認為沒有太大的爭論，因此，把它作為一個標(biāo)準(zhǔn)就 OK 。”

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

未來在編排領(lǐng)域，我們會看到一個激烈競爭的市場，而不是容器引擎領(lǐng)域。

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

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

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

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