開源專案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架構專案實戰教程及大廠面試題庫，進我扣裙 ：七吧傘吧零而衣零傘 （數字的諧音）轉換下可以找到了，還可以跟老架構師交流
本文的文字及圖片來源于網路加上自己的想法,僅供學習、交流使用,不具有任何商業用途,著作權歸原作者所有,如有問題請及時聯系我們以作處理
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/193601.html
標籤：Java