開源專案CRI-O（https://github.com/kubernetes-incubator/cri-o），即之前的OCID，旨在不依賴傳統容器引擎的前提下，使開源Kubernetes排程框架可以管理和啟動容器化的工作負載。

使用Google發起、Kubernetes工程師開發的容器執行時介面（CRI），通過與Kubernetes或Kubernetes的商業例項（如CoreOS Tectonic）進行互動，該軟體可以幫助DevOps專家管理整個“容器生命週期”。

開發者需要容器引擎來建立和構建容器映象，也可以使用自己的模擬環境。在管理更復雜的生產環境時，管理和運營團隊會發現使用Kubernetes stack——即排程框架、CRI和CRI-O——會比將排程框架和標準容器引擎配對更加方便。

該專案將容器排程工具，而非容器引擎，推上了容器棧元件的當家位置。CRI的貢獻者告訴我們，CRI允許Kubernetes使用任何容器引擎，只要該引擎符合開放容器倡議的規範，包括OCI自己的runC引擎，它可以做到品牌容器引擎如Docker和CoreOS的rkt的許多功能，包括從registry中pull映象的功能，但不能從makefile構建映象。

CRI-O是什麼

谷歌開發工程師， Kubernetes引擎的倡導者和領導者，Kelsey Hightower，在接受The New Stack採訪時談到，儘管開放容器倡議已經減輕了它對CRI-O的責任（但其成員和貢獻者還是相同的供應商和相同的人），但該專案是“OCI的自然程序”，是在發展容器執行時和映象的標準介面。

CRI-O專案最重要的主張是，使用者不應該對建立工作負載並用以stage的容器產生依賴。按照最初的設想，該專案將對Kubernetes提供工具，使其不需要Docker、rkt、OpenShift、Photon等任何的品牌容器，就可以管理容器的全生命週期。

Hightower 表示，“我們從容器執行時中需要得到的東西並不多——無論是Docker還是rkt ，它們要做的都很少，主要是把核心的API給我們。所以這並不僅僅是關於Linux的，我們也可以用在Windows系統上。如果這是社群想要發展的方向，我們需要Kubernetes去支援這些想法——因為這比Docker Inc.更重要，這才是重點。”

此主張的潛在假設是，排程框架位於容器生態系統的中心位置，而我們必須認識到“引擎”其實只是一個開發工具。

另一方面，CRI（通過Kubernetes開發，也是為了Kubernetes而開發的API）向容器引擎製造商們提供了一個機會，即實現Kubernetes的開放介面，這樣一來，擁有容器引擎的環境便可以合理連線。據一位谷歌核心工程師表示，這些連線可以在沒有容器引擎提供商“重構”引擎的情況下實現Kubernetes的相容性。

相反，一個叫做shim的抽象層可以被插入容器引擎和排程框架之間。容器供應商們如何實現shim抽象層就取決於他們了。

完成之後，CRI API（和Kubernetes連線的部分）可以將更多的容器生命週期控制交給Kubelet——即Kubernetes專屬的容器管理器，它將被容器生態系統所採用。

Kubernetesd的下一個版本，即1.5版本的目標是，包含一個定型的CRI用來使kubelet和Docker、rkt、中國的容器供應平臺Hyper.sh（https://www.hyper.sh/），以及由紅帽領導開發的CRI-O進行互動。

Philips表示，“許多不同的容器執行時都想和Kubernetes進行互動，所以我們沒有在kubelet中為每一個容器進行時構建單獨的介面，而是建立一個更加抽象的介面，讓其他人不需與Kubernetes上游工作直接相關也可以接入。

誰重構誰

Hightower描述容器執行時介面（CRI-O中的CRI）為容器引擎應該支援的基本特性的抽象。一旦CRI被完成，Kubernetes計劃重構自己的程式碼庫以實現CRI。

如果CRI-O成功了，他解釋說，所有容器引擎生產者都不必再更改引擎的程式碼庫，只要和Kubernetes互動操作就行了。

Hightower承認，“目前，想要玩好Kubernetes，需要構建一堆東西，而且可能改變目前使用的一些方式，你必須自己檢視程式碼庫搞清楚一些東西，這就是我們為Docker做的，如何為你的執行時引擎調整到適合你的方式，同時也適用與Kubernetes。”

CoreOS的Philips解釋道，每一個容器引擎會利用shim元件，它可以將容器本地詞彙的API請求翻譯為Kubernetes可以理解的形式。

Philips 說，“由於CRI的工作方式的原因，你需要一個GRPC 守護程序，它會監聽這些請求，並和kubelet進行交流。”反過來，kubelet會通過套接字向實現了CRI的引擎傳送遠端呼叫反饋。

“當前的Docker和rkt支援正被拉進CRI介面，”philis解釋道。CoreOS的rkt對CRI的實現目前在GtiHub上，名為rktlet（https://github.com/kubernetes-incubator/rktlet）。他希望不管是rktlet還是Docker的實現，最終都能重構進CRI中。

Docker已經要求實現和Kubernetes之間的shim了，谷歌的Hightower告訴我們，這個shim是Kubernetes而不是Docker的工程師生產的。Philips說，不管誰來實現CRI shim，Docker都會被重製以適應和其他人的合作。

“為了和CRI結合，Docker容器和rkt容器都在發生改變。” ——Brandon Philips，CoreOS

OCI映象格式的最終標準還未敲定，儘管OCI的一位發言人曾告知《The New Stack》，在釋出OCI映象格式的1.0版本之前還保留兩個候選版本。

同時，Docker繼續增強其容器引擎，將特徵聯絡起來，比如其Swarm 排程框架和服務發現。

“我覺得一切都好，”他說，“當然可能有人不喜歡，但沒關係，每個人都可以有自己的意見。Kubernetes——我們也提供一堆東西。但我們更相信我們是在做一些商品之上的東西”

Kubernetes 及展望

“要正確實現我們所說的pod，需要了解很多事情，” Hightower解釋道，“把負擔分解到每個容器執行時的做法對這些容器執行時來說是不公平的，想要玩一玩Kubernetes還必須實現那麼多程式碼。這樣想吧：他們還要為了Mesos、Swarm等等分別再做一些不同的事。為了簡化，我們將把Kubernetes特有的邏輯儲存在kubelet內部，而在外部，我們只會用到本地容器執行時已有的東西。”

假設真的實現了一個能理解當前容器化語言的介面，能夠抽象出面向pod、基於kubelet的邏輯，而相同的API可以和Kubernetes之外的東西對接時，可以以不同的方式抽象出自己的邏輯。

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

“我覺得行業真正在探尋的東西，是可以被靈活操作的部件，” Hindman 向 The New Stack解釋道，“我認為，以Kubernetes為例，這非常關鍵。Kubernetes以往是依賴於Docker去做容器管理的，他們也曾嘗試去構建排程。Docker併入了Swarm之後，他們就有了一個可以用來做排程的容器管理器。所以單從構架和工程師的角度，我會說‘我們要是有一個做容器管理的元件就好了……這樣可能有成倍的人來使用’”。

Hindman相信Docker是很想把runc作為開放標準的。但排程需要的不僅僅是和執行時進行互動操作。

“還有更多的相關的東西。下載映象、開啟映象——要做的還有很多。我認為行業中曾被廣泛探討的是，這些東西是不是應該被分解和模組化？怎麼做才能在構架層面上更有意義，而不是針對一次fork。”——Ben Hindman，Mesosphere

Hindman解釋說，Mesosphere的DC/OS 環境中也有這種元件，它們已經能夠脫離對runc和Docker元件的依賴。這如他所說，容器社群真正要追求的目標，是確定元件之間的架構界限，並在其中建立良好的介面。

這是否意味著Mesosphere支援CRI-O，其目標——正如Kelsey Hightower所說——和Hindman之前所說的完全一

儘管Hindman並不代表OCI，但必須注意到Mesosphere是OCI的創始成員之一。正如Hindman迴應的，OCI的初衷是發展一種常規執行時模式，並使runc可以將其作為一個容器來開啟。容器化社群也十分關心映象格式問題，其中包括容器rest狀態時的檔案系統和元資料。OCI也十分認同上文中的目標， Hindman表示，“其實，這比執行時格式更吸引我們。”

至於Mesosphere為什麼著手去做所謂的“萬能容器”，Hindman繼續說道，“是為了生產面向所有開放格式的容器，包括OCI。”

Hindman說，但在這最佳的構架下，可能並沒有標準化的排程工作負載的方式，因為排程任務特徵的差異性太大。因此，之前為了實現任何排程器都可以部署和開啟，而去尋找單一配置檔案、元資料檔案或者描述工作負載的努力，也隨著Hindman所謂“最低共同標準規範”而終止，該“規範”擁有功能集更為廣泛的排程器。

而決定通用的映象格式，相比之下就簡單多了。它歸結於Linux是否支援該格式。“如果Linux支援，我們就公開該標準。我認為大家不會在映象格式的問題上有太多爭議，因此，把它當做標準是完全沒問題的。”

Mesosphere將繼續支援OCI（或者叫“OCID”），Hindman總結說，也會根據支援OCI的程度繼續支援CRI-O。但是Mesosphere的“通用容器執行時”會以不同的方式進行這項支援。

市場將會變得更具競爭力，彼時市場的主角將會是排程框架，而不是被排程的內容。

原文：thenewstack.io/cri-o-make-kubernetes-center-container-ecosystem