開源項目 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和其它容器引擎廠商遵循同樣的規則，都不能搞特權。

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非常認同，但他也不忘吐槽：完整的編排不僅僅是與與容器引擎交互。

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-make-kubernetes-center-container-ecosystem/

您也可以關注我們的官方微信公眾號（ID：ctoutiao），給您更多好看的內容。