Docker與k8s的恩怨情仇(一)—成為PaaS前浪的Cloud Foundry

葡萄城技術團隊發表於2021-06-16

轉載請註明出處:葡萄城官網,葡萄城為開發者提供專業的開發工具、解決方案和服務,賦能開發者。

大家在工作中或許或多或少都接觸過Docker,那你知道Docker以及容器化背後的原理到底是什麼嗎?

容器化技術滿天下,那為什麼只有Docker被大家所熟知呢?

後Docker時代,到底誰才是雲原生時代的王者?

我們相信本系列文章能幫您解答這些疑惑。

被“嫌棄”的物理伺服器

在雲時代以前,開發者如需構建一個線上的站點,必須自己維護物理伺服器。但是隨著業務發展,大體量伺服器逐漸增多,隨之而來的是硬體、場地和維護成本的不斷提高。對於面向C端的站點來說,網路熱點事件具有隨機性,流量的變化並不可控,難免會遭遇站內流量暴漲的情況。此時如果沒有備用伺服器,突發的大流量很可能會沖垮整個站點。但在沒有突發事件的時候,備用伺服器的採購和維護成本又讓人不可忽略。

2.png
(運維的傳統藝能:上線拜祖,圖片來自網路)

哪裡有問題,哪裡就有商機。有人想到,如果買一批伺服器放在外網,安排專人管理,然後按照使用者的需要租賃出去,不正好解決了這個問題嗎?

於是,一場雲端計算的好戲,正式上演。

虛擬機器還是“超重”了

雲端計算時代的大幕拉開,大廠先後登臺,讓我們先簡單做一下回顧。

  • 2006年,亞馬遜成立aws,從雲端儲存業務開始。
  • 2008年,雲端計算初創。
  • 2009年,阿里雲成立。目前最新的資料表明,2020年度IaaS市場份額調查,阿里雲位居全球第三,亞太第一;前兩名分別是亞馬遜和微軟,市場份額達9.5%,超過谷歌的6.1%,亞馬遜40.8%,微軟17%。國內市場份額40% ,第二是華為雲,佔18%。
  • 2010年,OpenStack由NASA釋出。OpenStack是一個IaaS架構,可以用其架構來搭建自己的私有云,讓任何人都可以自行建立和提供雲端計算服務。對比而言,AWS和aliyun都是自研架構,OpenStack是開源的。所以公司如果需要,完全可以接入OpenStack搭建自己的私有云。(當然前提需要有OpenStack核心開發能力)。
  • 2010-2013年之間,雲端計算的全球份額被aws和OpenStack瓜分。

這時的雲端計算技術,本質都是虛擬化技術,將硬體資源作為基礎設施提供給使用者,簡稱IaaS。簡單理解,IaaS就是將一個很大的伺服器,通過虛擬化技術拆分成多個小的虛擬伺服器,提供服務,類似於在本機裝了虛擬機器。

1.png
(雲端計算主力玩家的進場時間,圖片來自網路)

但是,IaaS時代的虛擬機器還是太過於笨重了。每一臺虛擬機器都需要消耗CPU、記憶體等計算資源才能支撐應用的執行。即便應用再小,系統的開銷都是固定的成本。如何為IaaS減肥,讓虛擬機器系統的開銷降到最低?

2013年開始,雲端計算正式進入了PaaS時代。PaaS時代,雲端計算所銷售的單元,從虛擬機器變成了應用執行平臺。於是,雲廠商提供的服務更多,資源利用率也更高了。

什麼是PaaS?我們用一個通俗的例子來解釋。如果我們現在是一個燒餅店老闆,採用IaaS模式意味著我們需要用別人廚房、鍋爐、煤氣,自己和麵做餡料,做燒餅。如果是PaaS,我們燒餅的麵粉、餡料和調料都是別人提供好了,我們只需要把餅烤熟。

雲廠商該如何構建一套好用的PaaS服務呢?借力開源專案,成為各廠商的共識。

Cloud Foundry開啟PaaS開源時代

PaaS的核心是平臺。最早出現在開發者視野中的PaaS開源專案中,vmware創立的Cloud Foundry是知名度最高的。與IaaS提供雲上虛擬機器的服務方式不同,基於Cloud Foundry的雲端計算能夠提供應用託管的功能。開發者只需要通過一條簡單的命令比如:cf push "我的應用",就可以將專案打成一個壓縮包,上傳到Cloud Foundry伺服器。而Cloud foundry會開啟自己的排程器,在一群雲主機中找到滿足使用者需求的主機(系統版本、效能、個數),然後通過容器化技術,在主機上建立一個容器,在容器中下載壓縮包,解壓並執行,最終成為一個對外提供服務的應用。

此外,Cloud Foundry平臺對這些應用專案提供分發,災備,監控,重啟等等服務(這也是我們提供給使用者的核心服務)。這種託管服務解放了開發者的生產力,讓他們不用再關心應用的運維狀況,而是專心開發自己的應用。而這就是PaaS的“初心”,平臺即服務。

5.png
(Cloud Foundry提供的服務)

這裡就會有同學問了,容器是什麼?容器是用來解決多個應用資源衝突與隔離性問題的技術。Linux上的namespace機制和cgroups命令都能用做資源隔離和限制,這些都是容器技術。

容器技術並不是Docker建立的,在Docker興起之前,就已經被其他公司商用了,但是為什麼現在一談起容器,所有人第一時間想到的就是Docker呢?這就要提到Cloud Foundry的死亡。

從Cloud Foundry到Docker

Cloud Foundry似乎已經和我們現在使用的雲功能區別不大,但2021年的現實情況卻是Cloud Foundry已經死了。

我們看過網際網路上很多文章,再結合我們活字格公有云開發的經驗,我們認為這個專案的致命缺陷集中它的打包機制上。

Cloud Foundry最核心的元件就是應用的打包和分發機制,也是開發者打交道最多的功能。Cloud Foundry為每一種主流的語言都定義了一套打包的方式,這些方式之間毫無章法。但就是這個打包功能,成了Cloud Foundry的軟肋,一直為使用者所詬病。開發者不得不為每一種語言,每一種框架,甚至是每個版本應用維護一個打好的包,還有可能出現本機執行成功,打了個包上傳上去之後就無法執行的情況。情況最嚴重的時候,開發者在除錯雲平臺系統上花的時間都已經比開發一個新軟體的時間要長了。

本來是為賦能開發者的而生的技術,Cloud Foundry卻對開發者如此不友好。當開發者的抱怨積累到一定程度,想要在PaaS浪潮中央站穩腳跟的Cloud Foundry被後起之秀Docker“紅牌罰出局”也就順理成章了。

最初,Docker是一個當時還叫dotCloud的公司(2010年由所羅門海克斯建立,Y Combinator孵化)開發的容器專案。在Cloud Foundry困於打包問題時,Docker正在悄悄積蓄力量,在開源後的短短几個月內就迅速崛起,成為一個不容忽視的PaaS技術方案,吸引了雲服務開發者的眼球。

滑稽的是,在Docker剛開源的時候,Cloud Foundry的首席產品經理 James Bayer就在社群做了一次詳細的對比,告訴使用者Docker和Cloud Foundry一樣,都是使用了Namespace和Cgroups技術的沙箱而已,沒什麼值得關注的。

事實上,Docker也確實就和他所說的一樣,採用了這個“傳統”的技術方案,但是Docker與Cloud Foundry相比,做了一點小小的創新,體現了所羅門海克斯的遠見。從2010他就開始考慮應用打包的一致性與複用性問題,並提出了創新的解決方案,最終對Cloud Foundry造成了毀滅性的打擊。這個解決方案就是Docker映象。

4.jpg

(Docker,圖片來自官網)

剛開源的Docker迅速爆火,憨態可掬的小鯨魚,對使用者友好的文件,三分鐘部署一個Nginx叢集的宣傳語,以及Docker Image這個 “微不足道的創新”,讓Docker席捲整個PaaS領域。

Docker的制勝法寶:映象

Docker成功的關鍵,在於Docker映象幾乎完美地解決了Cloud Foundry在打包方面的軟肋。

所謂的映象,其實也是一個壓縮包,但是比起Cloud Foundry那種執行檔案+啟動指令碼的打包結果,映象提供給使用者的是一套完整的執行環境,每一個映象都可以指定作業系統版本,內部可以構建程式執行的檔案結構,並且一份映象可以完全共享在多處使用。

6.png

此外,Docker還給開發者提供了一套完善的映象製作流程,這套流程與程式語言和框架無關。開發者只需要按照該流程,定製對應程式所需要的執行的作業系統環境即可。

總之,Docker 映象完美解決了兩個問題:

1.本地環境和伺服器環境的差異
2.同一份映象可以讓所有的機器進行復用

從這一刻開始,PaaS的市場已經完全是Docker的天下。

小結

本文是系列文章的第一期,我們一起回顧了IaaS取代物理伺服器,基於IaaS構建PaaS的發展路線。在構建PaaS時,我們經歷了Cloud Foundry的衰敗,見證了Docker的成功。

但是,只依靠Docker就能構建起完整的PaaS服務嗎?我們的活字格公有云版最終選擇了哪個技術方案?雲端計算的故事還沒有講完,敬請期待下期精彩內容。

相關文章