開源專案 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構建映象）。

CRI-O 是什麼？

「  儘管 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 ，我們仍然會提供一包東西。但我們在創造和改進它時，不認為它僅僅是一件商品（還有情懷）。

超越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”將以不同的方式被支援。

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