開源項目CRI-O（https://github.com/kubernetes-incubator/cri-o），即之前的OCID，旨在不依賴傳統容器引擎的前提下，使開源Kubernetes調度框架可以管理和啟動容器化的工作負載。 使用Google發起、Kubernetes工程師開發的容器運行時介面 ...
開源項目CRI-O（https://github.com/kubernetes-incubator/cri-o），即之前的OCID，旨在不依賴傳統容器引擎的前提下，使開源Kubernetes調度框架可以管理和啟動容器化的工作負載。
使用Google發起、Kubernetes工程師開發的容器運行時介面（CRI），通過與Kubernetes或Kubernetes的商業實例（如CoreOS Tectonic）進行交互，該軟體可以幫助DevOps專家管理整個“容器生命周期”。
開發者需要容器引擎來創建和構建容器鏡像，也可以使用自己的模擬環境。在管理更複雜的生產環境時，管理和運營團隊會發現使用Kubernetes stack——即調度框架、CRI和CRI-O——會比將調度框架和標準容器引擎配對更加方便。
另外大家要註意：光理論是不夠的。在此順便送大家十套2020最新JAVA架構項目實戰教程及大廠面試題庫，進我扣裙 ：七吧傘吧零而衣零傘 （數字的諧音）轉換下可以找到了，還可以跟老架構師交流
該項目將容器調度工具，而非容器引擎，推上了容器棧組件的當家位置。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的“通用容器運行時”會以不同的方式進行這項支持。
市場將會變得更具競爭力，彼時市場的主角將會是調度框架，而不是被調度的內容。
最後註意：光理論是不夠的。在此順便送大家十套2020最新JAVA架構項目實戰教程及大廠面試題庫，進我扣裙 ：七吧傘吧零而衣零傘 （數字的諧音）轉換下可以找到了，還可以跟老架構師交流
本文的文字及圖片來源於網路加上自己的想法,僅供學習、交流使用,不具有任何商業用途,版權歸原作者所有,如有問題請及時聯繫我們以作處理
