Docker和rkt快別爭了，k8s纔是容器生態的中心

開源項目 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 」將以不一樣的方式被支持。

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

本文由時速雲翻譯，如若轉載，需註明轉載自「時速雲」

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

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

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