容器,你還只用Docker嗎?(上)

為擴大運維派影響力,網站及其公眾號轉讓中,有意微信:helloywp

作者介紹

周暉,Pivotal大中國區云計算首席架構師,有豐富的PaaS云實際建設經驗,負責過國內某知名銀行已經生產上線一年的PaaS云的架構設計和部分功能的實現,參與過某超算PaaS、某超市電商PaaS、某電力PaaS等項目的建設。

一、從一場容器的撕逼戰開始說起

從2016年7月底開始,GoogleKubernetes布道師KelseyHightower和Docker的CTOSolomonHykes在Twitter上發生了一場撕逼大戰,主題是要不要用RunC或其他容器來取代Docker引擎以及OCI的意義。

首先是Google的Kelsey挑事,說:“很多平臺都可以跑Docker鏡像,已經不再需要DockerDaemon了。哪個會成功呢?”

DockerCTOSolomon馬上接招:“其他平臺跑Docker鏡像是假的,其中只有90%能正常工作,其余10%則隨時可能會出問題。而且Docker還在演進中。”“所以嘛,聲稱‘可以跑Docker鏡像’的都是在撒謊。”

KelseyHightower反諷:“好吧,那我們就沒必要再提支持Docker了。我們實際支持的只是Docker的容器格式”,“Docker擁有創建和分發鏡像的最佳工作流,而運行時,還是留給它的競爭者們吧。”

所羅門繼續強調Docker的不兼容性:“這些都是不完整的、不兼容的支持”,“他們也并不支持鏡像格式,鏡像的很多信息都會丟失”。

后來,所羅門急眼了,說“OCI就是個偽標準”。

此言一出,驚詫四方,因為OCI有50多家廠商參與,而且Docker還是重要貢獻者,有說“標準不是一個人可以決定對錯的”,有反諷的“我相信工程師們樂于聽到他們創始人說他們做的工作是假貨”。

K8s的老大TimHockin直接就說“不爽你就走,不要假裝參與”。

所羅門不得不改口說“OCI標準的初衷是好的,只可惜擴展太早,我不認同就得走?”

有人隨即反駁“只有你一個人說擴展的太早,這是明顯的利益投射”。

所羅門還嘴硬“就因為我是唯一的不認同者,那我就必須離開?”

Kelsey隨后則直點主題,“有兩個問題在臺面上,一是容器需不需要標準化,二是需不需要由Docker來領導這個標準化的工作?”

Kelsey再以嘲諷的口吻自問自答“如果是Docker來回答這些問題,對第一個肯定是說不,那干脆對第二個問題也同樣說不吧,這可不是對和錯的問題”。

因為事關OCI,Docker現在這么鄙視RunC,OCI不得點出Docker你也是參與者就別鬧了,“Docker參與在OCI運行時和鏡像規范,也參與了每周的開發會議”。

Kelsey乘勝追擊,代表業界吐了個槽,“我一直相信Docker會給容器帶來很多,但是我真的擔心一個人想控制的太多”。Docker公司的控制欲早成為人們的吐槽點,什么都想做,把整個生態圈其他的參與者逼到墻角去了。

看業界大佬撕逼,感覺和咋人民群眾撕逼沒太大差別。所羅門的撕逼技巧明顯略遜一籌,有點像祥林嫂反復說“其他容器就是和Docker不兼容,包括RunC”,但是沒說出個哪里不兼容的道道。

二、容器撕逼之爭反應了容器生態面臨的問題

我們來總結這次著名的撕逼事件的來龍去脈,這會成為容器界一個關鍵的歷史轉折事件。容器之爭始實際上是很早之前就起源于Docker生態面臨的問題。

1、Docker商標的注冊圍剿了容器生態圈

從表面上看,是容器標準之爭,其實,反應的是赤裸裸的利益問題。Docker從容器開始,在獲得社區的熱烈響應之后,就進入了圈地過程,而且第一招圈地就非常兇悍,把公司從dotCloud改名為Docker,然后注冊Docker商標,商標意味著當其他公司使用未經Docker社區許可的補丁、代碼或軟件包的時候時可能面臨法律責任。這種情況下,一個公司可能因為補丁尚未經過Docker公司許可,抑或尚未被合并到項目中,而不能為客戶提供技術支持。

這不只是法務上的圈地,對于很多采用Docker名字的,Docker公司給予了實際行動—口頭警告(誰叫Docker是人家注冊的名字呢,就好比weibo.com就是微博),包括你建一個群名不加修飾限定的叫Docker,或是你要寫本書,不加修飾的叫DockerXXX,都容易受到Docker的警告。從法務上看這確實也屬于侵權,就看Docker要不要告你。

其后果就是第三方Docker生態廠商被迫忍受Docker公司任何對該開源項目作出的決定,在問題出現的時候等待Docker公司的補丁。最好的結果與Docker達成某種協議,由Docker公司來保證提供穩定的發行版本。那Docker的生態公司就淪為Docker公司的代理商了。

2、Docker攜容器引擎優勢進入容器集群管理,擠壓了容器生態圈的其他廠商生存空間

如果只是口頭撕逼,那大伙兒看看熱鬧就可以了,事實上這涉及到巨大的利益和整體生態環境的分歧。

在Docker獲得廣泛關注以后,就利用Docker容器的廣泛性優勢來擠壓生態圈其他伙伴的生存空間。直接把Swarm內置在Docker中。和當年的Microsoft通過Windows捆綁IE來打擊NetScape有異曲同工之妙。

Docker公司原來只在容器領域發展,K8s/Mesos等做容器集群管理,屬于CaaS(ContainerasaService),相互補充,互不競爭。等Docker容器被廣泛關注以后,Docker進入容器編排市場,收購了相關的技術以后推出Swarm的容器集群管理,從容器進入CaaS市場。2016年7月發布的Docker1.12把Swarm內置到Docker中去了,DockerSwarm作為容器集群管理軟件,內置在Docker中,幾乎就是Windows捆綁瀏覽器IE的模式,這就是用不平等的市場優勢打擊了Google的K8s和Mesos等,Google也不是吃素的,所以7月底馬上就是和DockerCTO口頭開撕。

對于Docker生態圈的集群管理軟件K8s和Mesos等來說,不但是不平等的競爭,最關鍵的是在容器生態圈最能帶來商業價值的就是容器集群管理,單單容器本身并沒有太多的商業價值,容器沒有集群管理是很難進入企業運行環境的。因為容器的直接商業價值并不大,CaaS廠商也沒有自己做容器。容器用于生產系統,就必須有容器的集群管理,而K8s和Mesos已經進入了這個商業領域并且取得了一定的優勢。現在Docker進入這個領域,就直接和容器集群管理的公司競爭,但Docker又是必須進入這個領域,如果不進入這個領域,很難取得商業成功,Docker本身又經過多輪風投,風投給Docker帶來了巨大的盈利壓力,如果久久不能盈利,那風頭的臉色不會那么好看了。

如果是公平競爭還好,比如Docker單獨發布Swarm的Docker集群管理,但是Docker直接把Swarm內置到Docker中去,安裝部署Docker就帶了Swarm,而Swarm的很多功能和K8s和Mesos是重疊的,K8s和Mesos再用Docker就顯得功能有大量重疊,而且帶來了系統的復雜性和不穩定性。

三、Docker的問題——業界對Docker的吐槽

在Google和Docker口水戰之后,業界對Docker的吐槽越來越多,主要包括以下幾點:

1、Docker向后兼容性問題

Docker被業界詬病最多的就是后向兼容性,Docker的新版本更關注的是革新性,而不是兼容性,但是,對于一個生產系統來說,后向兼容性至關重要,沒有后向兼容性,意味著每次Docker升級都帶來巨大的風險。

這也和Docker的企業文化有關,Docker更傾向于采納新技術,實現突破性的功能,這是典型的初創公司的企業文化,不斷的追加新功能,而不考慮企業級特性,更不考慮后向兼容的束縛。這個好處是能在個人粉絲中取得共鳴,這也是Docker快速流行的一個重要原因。任何特征都可能是雙刃劍,這種企業文化并不適合企業級,不考慮生產運行的可用性,對企業級應用來說可能是災難性的。

我們看看業界人士是怎么說的:“Docker不斷地破壞向后的兼容性”,RackN公司的CEORobHirschfeld說。RackN公司的應用程序生命周期管理平臺同時使用和提供了Docker組件,因此對后端的改動將會對其支持的客戶的業務造成影響。

“Docker將DockerEngine用作一個產品,而不是一個社區用來構建自有服務的組件”,Hirschfeld指責道。這種基于產品的策略意味著使用者被逼著在Docker發布新的革新特性或者合并新的組件(如Swarm)的時候去修復其破壞的向后兼容的問題。

“盡管我們會使用這些發布的特性,然而這些改動會帶來一系列與穩定性、版本、遷移和后端兼容相關的問題”。

BobWise,一名三星SDS云工程師,也同樣呼吁Docker放慢其容器創新的腳步,該公司同樣提供了基于云的容器相關支持服務。

“如果你的團隊在深度使用Kubernetes、Mesos或CloudFoundry,你需要一個穩定、簡單、無奇的容器實現方案,僅有最少的基本功能,由社區協商鏡像的創建、命名和發布”,Wise的一篇博客中寫道。“你需要使用每個都人都在使用的一個相同的、簡單的、無奇的容器實現方案。作為一個社區,我們需要放緩對于基本構建組件的變更速度。唯有穩定性才能讓構建其上的系統蓬勃發展。”

2、Docker容器在企業級方面還有待提高

Docker雖然一直宣稱ProductionReady,但是在實際的生產系統中同樣受到不少詬病。

看看業界人士的說法:

Apcera技術產品經理PhillipTribble在個人博客中,以一種外交辭令的口吻,讓Docker不要再把其新推出的特性鼓吹成一個完工的企業級可用的產品。Tribble寫道:“讓互聯網或者大會充斥著營銷材料,宣揚各種令人振奮的新特性,但實際上卻不如所說那樣能用,不是一個明智的做法”,Apcera的商業模式一部分是基于提供Docker容器的支持。

Tribble的帖子引發了其他人在HackerNews上表達他們的Docker經歷,包括一些新版本帶來的讓人傷心的bug。一位讀者談到一天中啟動70,000到90,000個容器,約9%左右的會因為“各種Dockerbug”遇到問題,這個比例最近的一次升級后下降到了4%。

但也有一些人在稱贊Docker的穩定性,“我們一直在生產中使用Docker約3年了,還沒有發現什么大的問題”,另一外讀者評論說,“它將一些很炫的Linux內核特性用簡潔的方式封裝了起來”。

當然也有不少Docker的支持者認為Docker公司的軟件是穩定的。同一個產品,在不同的客戶有截然相反的反應說明有的用的好,有的用的碰到不少問題,在不同的環境下缺乏一致性,這也是企業生產系統的大忌。

3、Docker撈過界了,越過了紅帽的操作系統界限?

哪些功能應該有Docker來實現,哪些功能應該由底層操作系統或者技術棧中的其他組件來負責處理?

在今年的很多會議上,包括LinuxConNorthAmerica2016,紅帽工程師DanWalsh說紅帽陷入了困境,一方面客戶越來越多的使用systemd來初始化Linux系統,而另一方面Docker似乎不愿使用systemd,取而代之使用DockerDaemon來提供初始化,服務激活,安全和容器日志的相關功能。

“在過去的三年里,我們一直試圖使systemd和Docker更好的整合,而我卻發現,兩個領導人都非常強烈的堅持己見”,Walsh說,兩個領導人指Hykes和systemd的創造者-LennartPoettering

“所以,當機器的時候,誰來負責啟動系統服務,是systemd還是Docker?”Walsh問到。一個拙劣的系統實現可能會導致systemd和Docker互相沖突。

紅帽為自己的客戶維護著自己的Docker版本分支,紅帽分支中的補丁Docker有一天可能會合并,或者永遠不。紅帽也冒著巨大的風險,紅帽的客戶也冒著巨大的風險。所以紅帽對Docker的支持其實遠不如Ubuntu,因為Docker已經侵入到OS的領域了。

即使是面對以上種種吐槽,Docker也不打算折中一下,甚至也不打算照顧這些意見,而是繼續我行我素。

四、容器生態圈集群管理廠商的應對

——不用Docker,把容器引擎拆解重組

撕逼只是矛盾爆發的階段總結,后面就開始進入實質性的對抗階段了。容器生態圈的集群管理廠商如Google/Mesos也不是嚇大的,快要被Docker斷了財路———“人為財死鳥為食亡”,其反應也直取Docker命門——在其CaaS中廢棄Docker,對容器進行抽象,用誰的容器都可以。容器運行時不再用Docker,而直接采用RunC,容器擴展功能通過插件來實現,基本就是全拋棄Docker了,這對Docker來說幾乎是生死之戰。

其實,容器技術本身的壁壘不高,Docker2013年一開始也就是幾十人的開發隊伍,到現在也只有200多人,各大廠商一直沒有重視這一塊,因為單單容器的商業價值比較低。真正要投入做容器,也只是分分鐘的事情,只不過Docker已經在容器領域形成了氣候,所以要走些變通的曲折路線。

各大廠商一起做個RunC,大家再只用RunC還是輕而易舉的。

我們再來看容器最主要的兩個的技術來源:

Namespace—來源于IBM

cGroup—-來源于Google

其他的容器核心技術都是Linux操作系統的功能,容器的核心技術是和Linux操作系統密切相關的,Docker本身在容器核心并沒有什么貢獻,NameSpace和cGroup都不是Docker的,也和Docker無關。Docker也不是最早用容器技術的,CloudFoundry比Docker更早把容器用于PaaS。

所以容器生態圈的公司撇開Docker做一個容器標準并不是什么難事。

我們再從時間線來梳理這個撕逼事件,讓大家更直觀的理解:

Docker

1、提前鋪墊:先通過RunC把容器運行時分離出Docker

2012年,隨著CloudFoundry的PaaS率先引入了容器技術,容器技術發展的愈發火熱,特別是Docker成為流行技術,形成了廣泛的生態圈,由于Docker一貫的控制欲,讓生態圈的其他大小伙伴難以參與,為破解這種狀況。Google先是支持CoreOS打造了Rocket容器,在Rocket和CF容器Garden的競爭壓力下,Docker終于同意容器標準化—-RunC項目成立,通過RunC對容器運行時進行標準化。

于是容器生態圈終于達到了拆解Docker技術堆棧第一個小目標—通過RunC把容器運行時獨立于Docker之外。在2015年6月成立OCI(OpenContainerInitiative)組織,掛在Linux基金會旗下。旨在圍繞容器格式和運行時制定一個開放的工業化標準。該組織超過50家大小成員,包括谷歌、Pivotal、Docker、CoreOS、微軟、亞馬遜、華為等一系列云計算廠商,按照該開放容器格式標準(OCF,OpenContainerFormat)制定的一種具體實現,當然Docker是RunC的重要貢獻者。

OCI對Docker意味著什么,Docker不是不清楚,知道RunC是來搶食的,除了會削弱自己的優勢,也還會被OCI標準束縛住,限制自己的發揮,所以Docker對OCI是消極抵制,但是無法和整個生態圈抗衡,不是不接受OCI和RunC。

面對Google、RedHat或者Microsoft這樣的大公司,不管從技術實力還是財務實力,以及政治關系處理上,Docker應該都很難占到太多便宜。但是技術大勢所趨,Docker也無法抗拒。

2、RunC容器格式標準是什么?

制定容器格式標準的宗旨概括來說就是不受上層結構的綁定,如特定的客戶端、編排棧等,同時也不受特定的供應商或項目的綁定,即不限于某種特定操作系統、硬件、CPU架構、公有云等。

最核心,是通過格式標準化來脫離Docker,有利于CaaS生態圈的公司各自發展,但是在標準層面匯聚。

3、RunC容器標準化宗旨

標準化容器的宗旨具體分為如下五條。

操作標準化:容器的標準化操作包括使用標準容器感覺創建、啟動、停止容器,使用標準文件系統工具復制和創建容器快照,使用標準化網絡工具進行下載和上傳。

內容無關:內容無關指不管針對的具體容器內容是什么,容器標準操作執行后都能產生同樣的效果。如容器可以用同樣的方式上傳、啟動,不管是php應用還是mysql數據庫服務。

基礎設施無關:無論是個人的筆記本電腦還是AWSS3,亦或是Openstack,或者其他基礎設施,都應該對支持容器的各項操作。

為自動化量身定制:制定容器統一標準,是的操作內容無關化、平臺無關化的根本目的之一,就是為了可以使容器操作全平臺自動化。

工業級交付:制定容器標準一大目標,就是使軟件分發可以達到工業級交付成為現實。

RunC標準化是瞄準工業級交付和運行時的,和Docker定位不一樣。各個CaaS/PaaS生態廠商需要一個標準的容器運行時,然后圍繞著這個標準運行時各自發揮自己的技術優勢,做編排的、做集群管理的、做資源調度等等,形成真正的容器生態圈。

4、第一步:虛張聲勢揚言對Docker容器另起分支,廢棄Docker公司對Docker的獨一控制權

在和Docker撕逼之后,引起了業界的集體吐槽,然后Google進入第一步:虛張聲勢,先來個大殺招嚇唬Docker——嘗試分支開源Docker來廢除Docker公司對Docker容器的獨家控制權。

先是Google方放出風聲,要對開源的DockerEngine重起爐灶—分支出一個容器,馬上在業界引起巨大的波瀾。

“在諸多正在考慮的選項之中,包括可能會將整個開源的DockerEngine一起重起爐灶(fork)。據一些接近討論的人士透露,相關代表來自RedHat、Google、CoreOS、華為和兩家大量使用Docker的客戶。”

隨后大家對Docker的代碼庫穩定性不足表達了各自的憂慮,因為這可能會在生產環境下基于Docker構建附加服務或者向客戶提供技術支持的時候招致各種麻煩。在表達各種對Docker公司在DockerEngine上管理的失望之后,沒有得到Docker的正面響應,相當多的技術專家和公司是支持分支的。因為Docker也不是嚇大的,對種種指責不予理會。

但是,也有很強的聲音擔心Docker從此支離破碎:

“目前發生的這件事情,如果處理不得當,會讓讓容器生態系統支零破碎,并導致單個的容器再無可能適配多種目標運行時環境。”一位HackerNews上的觀察員指出。

鑒于直接分支對整個生態會產生不可預知的影響,屬于殺敵三千自損八百的,雖然DockerCTO所羅門當初說OCI是個偽標準就是“殺敵三千自損八百”的招,但是碰到豬隊友不能把自己也變成豬。直接分支停留在口頭上。

5、第二步:通過RunC和插件來拆解Docker技術堆棧

在和Docker撕逼之后,引起了業界的集體吐槽,然后Google和業界進入第二步:

隨著RunC標準化的發展,RunC逐步成了構建容器運行隔離環境的標準,和Libcontainer的功能類似,Libcontainer對RunC也有很大的貢獻。那到底RunC和Docker是什么關系,如下圖:

Docker

Docker從1.11開始就采用了右邊的架構,這其實是Docker公司折中妥協的結果,因為面對Rocket和Garden的競爭,如果不支持RunC,那么在容器馬上就會進入分裂競爭狀態。

而OCI業界希望能夠在容器的運行環境標準化,也就是構建出一個容器運行環境的這部分能標準化,在容器運行環境下不需要Docker龐雜的功能,容器運行時這部分占Docker的整體功能比重很小,所以OCI組織很快就達成的一致,發展RunC容器運行時。

所以,理解Docker和RunC的關系,你可以理解為RunC是Docker一部分,而且是構建容器隔離運行環境的一部分,而這一部分,也恰恰是CaaS的廠商所需要的,他們只需要一個生產環境下的容器環境構建,不需要容器的鏡像打包等,這屬于開發測試所需。

通過RunC,也基本確定了CaaS/PaaS產品如CloudFoundry/K8s/Mesos等只需要RunC這個容器生產時的運行環境,而Docker更多的用于開發測試時。

除了RunC,容器插件也是一個關鍵的公有技術,把容器的功能擴展和外部交互的功能插件化,而插件在開源社區相當活躍,插件主要是四類:安全認證、存儲卷管理、網絡、IP池。比如各個存儲廠商都在開發或是已經開發了自己的存儲插件。

而這些插件也可以和RunC交互,通過上面一層的集成,可以讓RunC用到這些插件。而插件也基本外化了Docker的功能。

雖然Docker定義和開發了很多插件,但是插件可以各自開發。插件只要提供接口就可以容器運行時交互。不再局限于某個公司的插件。這里不得不提到K8s開發的網絡插件CNM和Docker自身提供的CNI就不一樣,雖然理論上是可以相互兼容,但是實際上是兩套實現機制,而且CNM得到了CaaS/PaaS廠商更廣泛的支持。

通過RunC和插件,把Docker容器引擎的功能進行了分拆,而且分拆的部分都有了替代品,只等下一步。

6、第三步:CaaS生態廠商通過容器抽象、RunC和插件來重組自己的容器技術堆棧

如下圖是各個業界廠商對Docker容器技術堆棧的進一步分拆,然后進行組合,形成各自自己的容器堆棧。分拆不是目標,是手段,組成成自己的容器才是目標。和我們的國產化替代是不是有點類似?

首先把Docker的技術堆棧分解為容器運行時RunC、插件、容器管理進程和容器倉庫。因為已經有了RunC的基礎,而且插件可以公用,各個廠商只要做容器進程管理和容器鏡像管理,既然是新的技術架構,各個廠商也考慮到容器的兼容性,大家很一致的做了一個模塊,稱為容器抽象,無論是Mesos還是K8s。有的把容器鏡像也一起做在容器抽象層,有的是單獨再做一個鏡像管理。

看下圖右邊的重組后的技術架構,完全沒有了Docker,也不需要Docker,但是很自然而然的取代了Docker的容器。這就是很典型的對Docker技術棧分解,先取代最核心的容器運行時RunC,再把功能外化到插件,然后再做一個容器抽象層,徹底肢解并取代了Docker。

Docker

注意紅色的框架,通過RunC和插件,CaaS/PaaS業界把他們所需的容器功能從Docker中獨立出來了,也就是有了RunC和插件,CaaS/PaaS完全可以不需要Docker就構建出CaaS/PaaS運行環境。

行文至此,大家應當對容器生態圈的撕逼事情的來龍去脈、各個廠商的應對、撕逼原因以及整個容器生態圈的巨大變化有個初步了解,欲知后事,且聽下回分解。

文章出處:DBAplus社群(訂閱號ID:?dbaplus)

網友評論comments

發表評論

電子郵件地址不會被公開。 必填項已用*標注

  1. afon說道:

    復盤文章是哪篇…

Copyright ? 2012-2019 YUNWEIPAI.COM - 運維派 - 粵ICP備14090526號-3
掃二維碼
掃二維碼
返回頂部
街机电玩捕鱼抢红包 148期曾道人玄机图 如意娱乐苹果 北京快中彩推荐 江西多乐彩官方网站 搜狐凯利即时指数 乐米彩票苹果 老快3走势 内蒙古十一选五6月30日 体彩20选5中4个奖金 青海快3开奖结果