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

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

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

開發人員需要使用容器引擎構建鏡像，通常情況下更喜歡用自己的 staging 環境做本地測試。但是管理和運營人員會發現，相對于標準容器引擎， Kubernetes 技術棧（比如編排系統、 CRI 和 CRI-O ）更適合用來管理復雜的生產環境。

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

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

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

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

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

另一方面， CRI （通用容器接口 API 和 Kubernetes ）將給容器引擎廠商一個機會，以便接入 Kubernetes 系統。運行容器的環境中，只要暴露出適當的連接，不需要容器引擎進行代碼重構就可以兼容 Kubernetes 。

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

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

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

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

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

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

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

就像 CoreOS 的 Philips 解釋的一樣，每個容器引擎將利用一個中間層—— 它能夠將容器引擎的 API 請求，轉化成 Kubernetes 可以處理的形式。

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

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

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

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

OCI 鏡像格式的最終標準還沒有確定， OCI 發言人也表明 OCI 鏡像格式 1.0 發布之前還有兩個迭代版本。

同時， Docker 在不斷增強其容器引擎的特性，并且捆綁了 Swarm 編排工具和服務發現。

“我認為這一切進展都不錯，” Philips 說，“人們可能不喜歡這樣——這很正常，每個人都可以有自己的觀點。對于 Kubernetes ，我們仍然會提供一包東西。但我們在創造和改進它時，不認為它僅僅是一件商品（還有情懷）。

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

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

我們和 Mesosphere 創始人 Ben Hindman 也探討了這種可能性。

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

對于 Docker 公司有意向將 runc 作為開放標準， Hindman 非常認同，但他也不忘吐槽：完整的編排不僅僅是與與容器引擎交互。

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

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

Mesosphere 的 DC/OS 環境中也有這些組件做鋪墊， Hindman 解釋說，已經無需依賴 runc 或任何 Docker 組件。容器社區的真正目標，正如他所說的，是在組件之間指定架構層面上的邊界，并建立它們之間建立適當的接口。

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

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

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

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

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

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

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

本文由時速云翻譯，如若轉載，需注明轉載自“時速云”

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

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

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