使用Google發起、Kubernetes工程師開發的容器運行時接口（CRI），經過與Kubernetes或Kubernetes的商業實例（如CoreOS Tectonic）進行交互，該軟件能夠幫助DevOps專家管理整個「容器生命週期」。git
開發者須要容器引擎來建立和構建容器鏡像，也可使用本身的模擬環境。在管理更復雜的生產環境時，管理和運營團隊會發現使用Kubernetes stack——即調度框架、CRI和CRI-O——會比將調度框架和標準容器引擎配對更加方便。
另外你們要注意：光理論是不夠的。在此順便送你們十套2020最新JAVA架構項目實戰教程及大廠面試題庫，進我扣裙 ：七吧傘吧零而衣零傘 （數字的諧音）轉換下能夠找到了，還能夠跟老架構師交流github
該項目將容器調度工具，而非容器引擎，推上了容器棧組件的當家位置。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架構項目實戰教程及大廠面試題庫，進我扣裙 ：七吧傘吧零而衣零傘 （數字的諧音）轉換下能夠找到了，還能夠跟老架構師交流本文的文字及圖片來源於網絡加上本身的想法,僅供學習、交流使用,不具備任何商業用途,版權歸原做者全部,若有問題請及時聯繫咱們以做處理