開源項(xiàng)目CRI-O（https://github.com/kubernetes-incubator/cri-o），即之前的OCID，旨在不依 賴傳統(tǒng)容器引擎的前提下，使開源Kubernetes調(diào)度框架可以管理和啟動(dòng)容器化的工作負(fù)載。
使用Google發(fā)起、Kubernetes工程師開發(fā)的容器運(yùn)行時(shí)接口（CRI），通過與Kubernetes或Kubernetes的商業(yè)實(shí)例（如CoreOS Tectonic）進(jìn)行交互，該軟件可以幫助DevOps專家管理整個(gè)“容器生命周期”。
開發(fā)者需要容器引擎來創(chuàng)建和構(gòu)建容器鏡像，也可以使用自己的模擬環(huán)境。在管理更復(fù)雜的生產(chǎn)環(huán)境時(shí)，管理和運(yùn)營團(tuán)隊(duì)會(huì)發(fā)現(xiàn)使用Kubernetes stack——即調(diào)度框架、CRI和CRI-O——會(huì)比將調(diào)度框架和標(biāo)準(zhǔn)容器引擎配對更加方便。
該項(xiàng)目將容器調(diào)度工具，而非容器引擎，推上了容器棧組件的當(dāng)家位置。CRI的貢獻(xiàn)者告訴我們，CRI允許Kubernetes使用任何容器引擎，只要該引擎符合開放容器倡議的規(guī)范，包括OCI自己的runC引擎，它可以做到品牌容器引擎如Docker和CoreOS的rkt的許多功能，包括從registry中pull鏡像的功能，但不能從makefile構(gòu)建鏡像。
CRI-O是什么
谷歌開發(fā)工程師， Kubernetes引擎的倡導(dǎo)者和領(lǐng)導(dǎo)者，Kelsey Hightower，在接受The New Stack采訪時(shí)談到，盡管開放容器倡議已經(jīng)減輕了它對CRI-O的責(zé)任（但其成員和貢獻(xiàn)者還是相同的供應(yīng)商和相同的人），但該項(xiàng)目是“OCI的自然進(jìn)程”，是在發(fā)展容器運(yùn)行時(shí)和鏡像的標(biāo)準(zhǔn)接口。
CRI-O項(xiàng)目最重要的主張是，用戶不應(yīng)該對創(chuàng)建工作負(fù)載并用以stage的容器產(chǎn)生依賴。按照最初的設(shè)想，該項(xiàng)目將對Kubernetes提供工具，使其不需要Docker、rkt、OpenShift、Photon等任何的品牌容器，就可以管理容器的全生命周期。
Hightower 表示，“我們從容器運(yùn)行時(shí)中需要得到的東西并不多——無論是Docker還是rkt ，它們要做的都很少，主要是把內(nèi)核的API給我們。所以這并不僅僅是關(guān)于Linux的，我們也可以用在Windows系統(tǒng)上。如果這是社區(qū)想要發(fā)展的方向，我們需要Kubernetes去支持這些想法——因?yàn)檫@比Docker Inc.更重要，這才是重點(diǎn)。”
此主張的潛在假設(shè)是，調(diào)度框架位于容器生態(tài)系統(tǒng)的中心位置，而我們必須認(rèn)識(shí)到“引擎”其實(shí)只是一個(gè)開發(fā)工具。
另一方面，CRI（通過Kubernetes開發(fā)，也是為了Kubernetes而開發(fā)的API）向容器引擎制造商們提供了一個(gè)機(jī)會(huì)，即實(shí)現(xiàn)Kubernetes的開放接口，這樣一來，擁有容器引擎的環(huán)境便可以合理連接。據(jù)一位谷歌核心工程師表示，這些連接可以在沒有容器引擎提供商“重構(gòu)”引擎的情況下實(shí)現(xiàn)Kubernetes的兼容性。
相反，一個(gè)叫做shim的抽象層可以被插入容器引擎和調(diào)度框架之間。容器供應(yīng)商們?nèi)绾螌?shí)現(xiàn)shim抽象層就取決于他們了。
完成之后，CRI API（和Kubernetes連接的部分）可以將更多的容器生命周期控制交給Kubelet——即Kubernetes專屬的容器管理器，它將被容器生態(tài)系統(tǒng)所采用。
Kubernetesd的下一個(gè)版本，即1.5版本的目標(biāo)是，包含一個(gè)定型的CRI用來使kubelet和Docker、rkt、中國的容器供應(yīng)平臺(tái)Hyper.sh（https://www.hyper.sh/），以及由紅帽領(lǐng)導(dǎo)開發(fā)的CRI-O進(jìn)行交互。
Philips表示，“許多不同的容器運(yùn)行時(shí)都想和Kubernetes進(jìn)行交互，所以我們沒有在kubelet中為每一個(gè)容器進(jìn)行時(shí)構(gòu)建單獨(dú)的接口，而是創(chuàng)建一個(gè)更加抽象的接口，讓其他人不需與Kubernetes上游工作直接相關(guān)也可以接入。
誰重構(gòu)誰
Hightower描述容器運(yùn)行時(shí)接口（CRI-O中的CRI）為容器引擎應(yīng)該支持的基本特性的抽象。一旦CRI被完成，Kubernetes計(jì)劃重構(gòu)自己的代碼庫以實(shí)現(xiàn)CRI。
如果CRI-O成功了，他解釋說，所有容器引擎生產(chǎn)者都不必再更改引擎的代碼庫，只要和Kubernetes交互操作就行了。
Hightower承認(rèn)，“目前，想要玩好Kubernetes，需要構(gòu)建一堆東西，而且可能改變目前使用的一些方式，你必須自己查看代碼庫搞清楚一些東西，這就是我們?yōu)镈ocker做的，如何為你的運(yùn)行時(shí)引擎調(diào)整到適合你的方式，同時(shí)也適用與Kubernetes。”
CoreOS的Philips解釋道，每一個(gè)容器引擎會(huì)利用shim組件，它可以將容器本地詞匯的API請求翻譯為Kubernetes可以理解的形式。
Philips 說，“由于CRI的工作方式的原因，你需要一個(gè)GRPC 守護(hù)進(jìn)程，它會(huì)監(jiān)聽這些請求，并和kubelet進(jìn)行交流。”反過來，kubelet會(huì)通過套接字向?qū)崿F(xiàn)了CRI的引擎發(fā)送遠(yuǎn)程調(diào)用反饋。
“當(dāng)前的Docker和rkt支持正被拉進(jìn)CRI接口，”philis解釋道。CoreOS的rkt對CRI的實(shí)現(xiàn)目前在GtiHub上，名為rktlet（https://github.com/kubernetes-incubator/rktlet）。他希望不管是rktlet還是Docker的實(shí)現(xiàn)，最終都能重構(gòu)進(jìn)CRI中。
Docker已經(jīng)要求實(shí)現(xiàn)和Kubernetes之間的shim了，谷歌的Hightower告訴我們，這個(gè)shim是Kubernetes而不是Docker的工程師生產(chǎn)的。Philips說，不管誰來實(shí)現(xiàn)CRI shim，Docker都會(huì)被重制以適應(yīng)和其他人的合作。
“為了和CRI結(jié)合，Docker容器和rkt容器都在發(fā)生改變。” ——Brandon Philips，CoreOS
OCI鏡像格式的最終標(biāo)準(zhǔn)還未敲定，盡管OCI的一位發(fā)言人曾告知《The New Stack》，在發(fā)布OCI鏡像格式的1.0版本之前還保留兩個(gè)候選版本。
同時(shí)，Docker繼續(xù)增強(qiáng)其容器引擎，將特征聯(lián)系起來，比如其Swarm 調(diào)度框架和服務(wù)發(fā)現(xiàn)。
“我覺得一切都好，”他說，“當(dāng)然可能有人不喜歡，但沒關(guān)系，每個(gè)人都可以有自己的意見。Kubernetes——我們也提供一堆東西。但我們更相信我們是在做一些商品之上的東西”
Kubernetes 及展望
“要正確實(shí)現(xiàn)我們所說的pod，需要了解很多事情，” Hightower解釋道，“把負(fù)擔(dān)分解到每個(gè)容器運(yùn)行時(shí)的做法對這些容器運(yùn)行時(shí)來說是不公平的，想要玩一玩Kubernetes還必須實(shí)現(xiàn)那么多代碼。這樣想吧：他們還要為了Mesos、Swarm等等分別再做一些不同的事。為了簡化，我們將把Kubernetes特有的邏輯保存在kubelet內(nèi)部，而在外部，我們只會(huì)用到本地容器運(yùn)行時(shí)已有的東西。”
假設(shè)真的實(shí)現(xiàn)了一個(gè)能理解當(dāng)前容器化語言的接口，能夠抽象出面向pod、基于kubelet的邏輯，而相同的API可以和Kubernetes之外的東西對接時(shí)，可以以不同的方式抽象出自己的邏輯。
我們和Mesosphere的創(chuàng)始人Ben Hindman探討了這種可能性。
“我覺得行業(yè)真正在探尋的東西，是可以被靈活操作的部件，” Hindman 向 The New Stack解釋道，“我認(rèn)為，以Kubernetes為例，這非常關(guān)鍵。Kubernetes以往是依賴于Docker去做容器管理的，他們也曾嘗試去構(gòu)建調(diào)度。Docker并入了Swarm之后，他們就有了一個(gè)可以用來做調(diào)度的容器管理器。所以單從構(gòu)架和工程師的角度，我會(huì)說‘我們要是有一個(gè)做容器管理的組件就好了……這樣可能有成倍的人來使用’”。
Hindman相信Docker是很想把runc作為開放標(biāo)準(zhǔn)的。但調(diào)度需要的不僅僅是和運(yùn)行時(shí)進(jìn)行交互操作。
“還有更多的相關(guān)的東西。下載鏡像、打開鏡像——要做的還有很多。我認(rèn)為行業(yè)中曾被廣泛探討的是，這些東西是不是應(yīng)該被分解和模塊化？怎么做才能在構(gòu)架層面上更有意義，而不是針對一次fork。”——Ben Hindman，Mesosphere
Hindman解釋說，Mesosphere的DC/OS 環(huán)境中也有這種組件，它們已經(jīng)能夠脫離對runc和Docker組件的依賴。這如他所說，容器社區(qū)真正要追求的目標(biāo)，是確定組件之間的架構(gòu)界限，并在其中建立良好的接口。
這是否意味著Mesosphere支持CRI-O，其目標(biāo)——正如Kelsey Hightower所說——和Hindman之前所說的完全一
盡管Hindman并不代表OCI，但必須注意到Mesosphere是OCI的創(chuàng)始成員之一。正如Hindman回應(yīng)的，OCI的初衷是發(fā)展一種常規(guī)運(yùn)行時(shí)模式，并使runc可以將其作為一個(gè)容器來打開。容器化社區(qū)也十分關(guān)心鏡像格式問題，其中包括容器rest狀態(tài)時(shí)的文件系統(tǒng)和元數(shù)據(jù)。OCI也十分認(rèn)同上文中的目標(biāo)， Hindman表示，“其實(shí)，這比運(yùn)行時(shí)格式更吸引我們。”
至于Mesosphere為什么著手去做所謂的“萬能容器”，Hindman繼續(xù)說道，“是為了生產(chǎn)面向所有開放格式的容器，包括OCI。”
Hindman說，但在這最佳的構(gòu)架下，可能并沒有標(biāo)準(zhǔn)化的調(diào)度工作負(fù)載的方式，因?yàn)檎{(diào)度任務(wù)特征的差異性太大。因此，之前為了實(shí)現(xiàn)任何調(diào)度器都可以部署和打開，而去尋找單一配置文件、元數(shù)據(jù)文件或者描述工作負(fù)載的努力，也隨著Hindman所謂“最低共同標(biāo)準(zhǔn)規(guī)范”而終止，該“規(guī)范”擁有功能集更為廣泛的調(diào)度器。
而決定通用的鏡像格式，相比之下就簡單多了。它歸結(jié)于Linux是否支持該格式。“如果Linux支持，我們就公開該標(biāo)準(zhǔn)。我認(rèn)為大家不會(huì)在鏡像格式的問題上有太多爭議，因此，把它當(dāng)做標(biāo)準(zhǔn)是完全沒問題的。”
Mesosphere將繼續(xù)支持OCI（或者叫“OCID”），Hindman總結(jié)說，也會(huì)根據(jù)支持OCI的程度繼續(xù)支持CRI-O。但是Mesosphere的“通用容器運(yùn)行時(shí)”會(huì)以不同的方式進(jìn)行這項(xiàng)支持。
市場將會(huì)變得更具競爭力，彼時(shí)市場的主角將會(huì)是調(diào)度框架，而不是被調(diào)度的內(nèi)容。

本文轉(zhuǎn)自中文社區(qū)-CRI-O將如何把Kubernetes推上容器生態(tài)系統(tǒng)的中心位置

總結(jié)

以上是生活随笔為你收集整理的CRI-O将如何把Kubernetes推上容器生态系统的中心位置的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。