容器戰(zhàn)爭響起， K8S受天量資金加持就能贏得天下？

作者：彭哲夫 2018-04-24 11:37:15
云計(jì)算 不可否認(rèn) k8s 是一個(gè)非常不錯(cuò)的系統(tǒng)，無論是調(diào)度編排這個(gè)層面還是宏觀上架構(gòu)設(shè)計(jì)層面。你可以說早期的 k8s 就是娘不親爹不愛就那么幾個(gè)工程師打著 Google 旗號(hào)在開源界見縫插的這個(gè)針。無奈是豬對(duì)手加 G 家光環(huán)，我一個(gè)開源系統(tǒng)怎么就做到了世界之王呢?

專注于為中小企業(yè)提供做網(wǎng)站、成都網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)任城免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了上1000+企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

引子

在前東家寫完了 Eru2 之后，花了很長一段回顧過去 4 年容器圈的發(fā)展，學(xué)習(xí)其他系統(tǒng)的經(jīng)驗(yàn)。一方面 CNCF 崛起之快令人難以置信，短短幾年已經(jīng)成為不亞于 ASF 的存在，在各種 conference 上面不遺余力強(qiáng)推自己的項(xiàng)目，或撕逼，隱約有一統(tǒng)江湖之勢(shì)。另一方面 Kubernetes 的調(diào)度編排戰(zhàn)爭已經(jīng)幾乎打完，依托于 CNCF 的推廣和已經(jīng)成為了事實(shí)的標(biāo)準(zhǔn)的 CNI/CRI 等接口規(guī)范，隔壁親家 docker 的核心組件拆的拆(containerd)，「無奈」內(nèi)置 CRI 實(shí)現(xiàn)的，逐步拋棄 CNM 模型等，完全毫無招架之力，拆得只剩個(gè) bug 略多的 daemon。更別說親兒子 Swarm 的下場了，喪權(quán)辱國的直接接上 K8s。也就 ASF 下的 Mesos 還能吊著一口氣。但那不爭氣的 Marathon 啊，看看隔壁 K8S 的生態(tài)，What can I say。

有意思的是 16 年我寫 Docker 的未來 的時(shí)候還被人「教育」過不懂 Docker，不好意思你大爺還是你大爺?，F(xiàn)在來看 cri-o、rkt 甚至 Docker 自己的 containerd 發(fā)展趨勢(shì)，只能回一個(gè)關(guān)愛智障的微笑并手動(dòng)再見。就連經(jīng)過了大量生產(chǎn)驗(yàn)證的老牌網(wǎng)絡(luò)組件 calico 都已在 3.X 版本之后不再維護(hù)和更新 libnetwork CNM 模型下的 docker 網(wǎng)絡(luò)接口，去掉了對(duì) Mesos 的支持，還說戰(zhàn)爭沒打完的不是蠢就是壞。

毫無疑問戰(zhàn)爭已打完了，CNCF 天量資金加持下的 k8s 贏得了天下，但它真的就無懈可擊么?

人!人!人!

不可否認(rèn) k8s 是一個(gè)非常不錯(cuò)的系統(tǒng)，無論是調(diào)度編排這個(gè)層面還是宏觀上架構(gòu)設(shè)計(jì)層面。你可以說早期的 k8s 就是娘不親爹不愛就那么幾個(gè)工程師打著 Google 旗號(hào)在開源界見縫插的這個(gè)針。無奈是豬對(duì)手加 G 家光環(huán)，我一個(gè)開源系統(tǒng)怎么就做到了世界之王呢?

個(gè)人看來還是因?yàn)?G 家光環(huán)太過于耀眼。

前有 Mapreduce GFS bla bla 大量工業(yè)界論文，后有神乎其神的 Borg 把編排玩出花。大多數(shù)人選型的時(shí)候一看喲 G 家的東西啊，上上上，然后就沒然后了。再加上對(duì)手實(shí)在是不夠打，比如 Mesos 至今周邊無論是語言還是完善度都不統(tǒng)一(當(dāng)然你可以說它兩層結(jié)構(gòu)注定的)，再比如愚蠢的 Swarm mode 助攻。人又不傻，有爹的東西當(dāng)然最好啦。

然而我很不想說的是，每一家的東西無論開源與否都是立足于自身業(yè)務(wù)上的，不是用了 G 家的東西就會(huì)讓你的團(tuán)隊(duì)成為 G 家的一毛一樣，就和 G 家平起平坐站在工程界金字塔的尖端了。手頭有什么牌就打什么牌，能贏那是技術(shù)好，但一對(duì)三真干不過四個(gè)二的。

我見過大多數(shù)用 k8s 的團(tuán)隊(duì)，很大程度上都是把 k8s 當(dāng)黑箱用。規(guī)模小了搭建起來成本就很高，那么多概念上的東西在規(guī)模小的時(shí)候就去強(qiáng)加于業(yè)務(wù)真的有必要么?Pod 的設(shè)計(jì)不就是 Virtual Machine 下多進(jìn)程業(yè)務(wù)在容器時(shí)代沒辦法的一個(gè) Workaround，那服務(wù)治理概念一堆堆但本質(zhì)上沒有什么事是一個(gè) proxy 解決不了的，有那不就再加個(gè) proxy 么。另外規(guī)模大了這么一個(gè)大黑箱真出了什么毛病，怎么搞?我自己看 kubelet 的執(zhí)行流程和實(shí)現(xiàn)，包括對(duì)比 cri-o rktnetes containerd docker-shim 等 runtime 實(shí)現(xiàn)細(xì)節(jié)想找人交流交流都很難找到。另外還有社區(qū)有更新你跟不跟，不跟有 security 問題怎么辦，升級(jí)出了幺蛾子怎么搞，要知道 k8s 嚴(yán)格意義上可不算什么旁路編排和調(diào)度系統(tǒng)，升級(jí)慘案還少么?

真不是用了 G 家的東西就和 G 家工程師一個(gè)水平了。

Kubernetes 的未來

不管怎么說，k8s 已經(jīng)成為了事實(shí)的標(biāo)準(zhǔn)?？梢灶A(yù)見的未來里面，在 CNCF 的支持下，社區(qū)是它最深的護(hù)城河。假如你需要一個(gè)能解決容器調(diào)度編排，能解決服務(wù)治理，能鏈路控制(升降級(jí)，流控，發(fā)現(xiàn)等)，能一勞永逸開箱即用(拋開各種概念)的基礎(chǔ)設(shè)施，它是唯一的選擇，也是最好的選擇。

但它實(shí)在是太復(fù)雜了，遠(yuǎn)的 Pod 不說，近一點(diǎn)服務(wù)治理里面的 Sidecar 概念和我單獨(dú)起 SDK 中間件有啥區(qū)別。好你要說不需要語言綁定是沒毛病，但比性能這種模式你也比不過 in-memory 的設(shè)計(jì)啊?

你想用 istio ok，上 k8s。你想用 linkerd ok，上 k8s 。拆開用是能用，但只有 k8s 下，這些東西所宣稱的那些花樣你才玩得溜，這和強(qiáng)制綁定有啥區(qū)別。hmmm，新時(shí)代的 Apache httpd 即視感有沒有?

那么隨著業(yè)務(wù)的增長，基礎(chǔ)平臺(tái)是抽象出來了，但依然需要大量人力成本去維護(hù)去學(xué)習(xí)。本來搞個(gè)平臺(tái)層面的東西就想自動(dòng)化壓低成本，現(xiàn)在倒好概念能和前端界一樣日新月異靠人堆，個(gè)人覺得并不是什么好事情。在戰(zhàn)爭結(jié)束前 K8s 可能還沒這么多爭議，戰(zhàn)爭結(jié)束后眾口難調(diào)的情況下只有這一個(gè)靶子，攤手?？梢韵胂蟮贸鲭S著時(shí)間的增長對(duì) K8s 復(fù)雜度的吐槽將會(huì)越來越多。同樣的，我也預(yù)計(jì)不久的將來，和 Apache httpd 終究遭遇了 nginx 一樣，編排和調(diào)度系統(tǒng)的 「nginx」也會(huì)出現(xiàn)在我們視野，就像老牌 Hashicrop 下的 nomad 一樣等待著和 K8s 平分天下。

新的戰(zhàn)場

Docker 是輸了編排和調(diào)度，也失去了那種號(hào)令天下的霸權(quán)。然而對(duì) K8s 來說最不幸的是產(chǎn)生容器的「工廠」標(biāo)準(zhǔn)依然在 Docker 手中。

無論是 OCI 鏡像標(biāo)準(zhǔn)和 Docker 鏡像標(biāo)準(zhǔn)親兄弟，還是運(yùn)行層面的 containerd。K8s 整了 CRI/CNI 什么的，又扶持了 CRI-O 還有隔壁 Rkt 什么的，并沒有一點(diǎn)卵用，看看那個(gè) appc 的概念還有人提么。containerd 在最新 RC 中內(nèi)置 CRI 支持，可以直接替換 kubelet 的 dockershim 實(shí)現(xiàn)，也把之前的 cri-containerd 丟入了歷史的垃圾堆，已然成為了集大成的事實(shí)標(biāo)準(zhǔn)。

你 CRI-O 說自己測(cè)試完備率更高，高得過一直內(nèi)置代碼在 K8s 的 dockershim/containerd 一脈相承?你 rkt 說自己進(jìn)程樹扁平，能比 containerd 直接掛容器到 systemd 下更平?況且都抽象控制平面了，下面 runtime 不都是支持 runc runV 混布么。還有你一個(gè) cri-o 別的不學(xué)，硬要去做個(gè)內(nèi)置 pod 你讓隔壁的 kubelet 沒飯吃怎么辦?

基礎(chǔ)設(shè)施是一定圖穩(wěn)的，在目前換 CRI-O Rkt 等沒有明顯顯著優(yōu)勢(shì)的情況下，甚至大劣的情況下，containerd 就是事實(shí)標(biāo)準(zhǔn)。Docker 回歸到了他應(yīng)該在的位置，那就是容器「引擎」。當(dāng)然了 containerd 的成功也是依托于 K8s 的成功，隨著 dockershim 的實(shí)現(xiàn)走進(jìn)千家萬戶。

而隨著 containerd 的日益成熟，新的編排系統(tǒng)，新的系統(tǒng)架構(gòu)，也就有了新的血液。在這之上產(chǎn)生一個(gè)足以威脅到 K8s 的新基礎(chǔ)設(shè)施系統(tǒng)，是完全可以期待的。

尾聲

即便站在 2018 年這個(gè)時(shí)間點(diǎn)上，我依然認(rèn)為調(diào)度和編排還是一件可以做的事情。怎么單獨(dú)的用 containerd 去驅(qū)動(dòng)容器，怎么解構(gòu)復(fù)雜 Pod 轉(zhuǎn)變?yōu)?native container (1 process 1 container)再通過上層的組合完成復(fù)雜業(yè)務(wù)形態(tài)，怎么通過 CNI 結(jié)合現(xiàn)有的基礎(chǔ)網(wǎng)絡(luò)等插件，怎么實(shí)現(xiàn)更高效的萬臺(tái)機(jī)器編排等，依然還有想象力空間。

舊的戰(zhàn)爭已經(jīng)結(jié)束，新的戰(zhàn)場已經(jīng)硝煙四起。對(duì)于 containerd 的前途而言我個(gè)人是比較看好的。沒有歷史的包袱，又向下兼容各類系統(tǒng)的接口，穩(wěn)定性經(jīng)過了大量生產(chǎn)實(shí)踐，還可以很方便的二次開發(fā)。也許過幾年我們就能看到基于其新的調(diào)度編排「nginx」了吧。

名稱欄目：容器戰(zhàn)爭響起，K8S受天量資金加持就能贏得天下？
瀏覽地址：http://fisionsoft.com.cn/article/dpgdjee.html