歡迎光臨
每天分享高質量文章

容器戰爭

引子

在前東家寫完了 Eru2[1] 之後,花了很長一段回顧過去 4 年容器圈的發展,學習其他系統的經驗。一方面 CNCF 崛起之快令人難以置信,短短幾年已經成為不亞於 ASF 的存在,在各種 conference 上面不遺餘力強推自己的專案,或撕逼,隱約有一統江湖之勢。另一方面 Kubernetes 的調度編排戰爭已經幾乎打完,依托於 CNCF 的推廣和已經成為了事實的標準的 CNI/CRI 等接口規範,隔壁親家 Docker 的核心組件拆的拆(containerd),「無奈」內置 CRI 實現的,逐步拋棄 CNM 模型等,完全毫無招架之力,拆得只剩個 bug 略多的 daemon。更別說親兒子 Swarm 的下場了,喪權辱國的直接接上 Kubernetes。也就 ASF 下的 Mesos 還能吊著一口氣。但那不爭氣的 Marathon 啊,看看隔壁 Kubernetes 的生態,What can I say。
有意思的是 16 年我寫《Docker 的未來》的時候還被人「教育」過不懂 Docker,不好意思你大爺還是你大爺。現在來看 CRI-O[2]、rkt[3] 甚至 Docker 自己的 containerd 發展趨勢,只能回一個關愛智障的微笑並手動再見。就連經過了大量生產驗證的老牌網絡組件 Calico[4] 都已在 3.X 版本之後不再維護和更新 libnetwork CNM 模型下的 Docker 網絡接口,去掉了對 Mesos 的支持,還說戰爭沒打完的不是蠢就是壞。
毫無疑問戰爭已打完了,CNCF 天量資金加持下的 Kubernetes 贏得了天下,但它真的就無懈可擊麽?

人!人!人!

不可否認 Kubernetes 是一個非常不錯的系統,無論是調度編排這個層面還是宏觀上架構設計層面。你可以說早期的 Kubernetes 就是娘不親爹不愛就那麼幾個工程師打著 Google 旗號在開源界見縫插的這個針。無奈是豬對手加 G 家光環,我一個開源系統怎麼就做到了世界之王呢?
個人看來還是因為 G 家光環太過於耀眼。
前有 Mapreduce GFS bla bla 大量工業界論文,後有神乎其神的 Borg 把編排玩出花。大多數人選型的時候一看喲 G 家的東西啊,上上上,然後就沒然後了。再加上對手實在是不夠打,比如 Mesos 至今周邊無論是語言還是完善度都不統一(當然你可以說它兩層結構註定的),再比如愚蠢的 Swarm mode 助攻。人又不傻,有爹的東西當然最好啦。
然而我很不想說的是,每一家的東西無論開源與否都是立足於自身業務上的,不是用了 G 家的東西就會讓你的團隊成為 G 家的一毛一樣,就和 G 家平起平坐站在工程界金字塔的尖端了。手頭有什麼牌就打什麼牌,能贏那是技術好,但一對三真乾不過四個二的。
我見過大多數用 Kubernetes 的團隊,很大程度上都是把 Kubernetes 當黑箱用。規模小了搭建起來成本就很高,那麼多概念上的東西在規模小的時候就去強加於業務真的有必要麼?Pod 的設計不就是 Virtual Machine 下多行程業務在容器時代沒辦法的一個 Workaround,那服務治理概念一堆堆但本質上沒有什麼事是一個 Proxy 解決不了的,有那不就再加個 Proxy 麽。另外規模大了這麼一個大黑箱真出了什麼毛病,怎麼搞?我自己看 Kubelet 的執行流程和實現,包括對比 CRI-O、rktnetes containerd、docker-shim 等 Runtime 實現細節想找人交流交流都很難找到。另外還有社區有更新你跟不跟,不跟有 security 問題怎麼辦,升級出了幺蛾子怎麼搞,要知道 Kubernetes 嚴格意義上可不算什麼旁路編排和調度系統,升級慘案還少麽?
真不是用了 G 家的東西就和 G 家工程師一個水平了。

Kubernetes 的未來

不管怎麼說,Kubernetes 已經成為了事實的標準。可以預見的未來裡面,在 CNCF 的支持下,社區是它最深的護城河。假如你需要一個能解決容器調度編排,能解決服務治理,能鏈路控制(升降級、流控、發現等),能一勞永逸開箱即用(拋開各種概念)的基礎設施,它是唯一的選擇,也是最好的選擇。
但它實在是太複雜了,遠的 Pod 不說,近一點服務治理裡面的 Sidecar 概念和我單獨起 SDK 中間件有啥區別。好你要說不需要語言系結是沒毛病,但比性能這種樣式你也比不過 in-memory 的設計啊?
你想用 Istio[5] ok,上 Kubernetes。你想用 Linkerd[6] ok,上 Kubernetes 。拆開用是能用,但只有 Kubernetes 下,這些東西所宣稱的那些花樣你才玩得溜,這和強制系結有啥區別。hmmm,新時代的 Apache httpd[7] 即視感有沒有?
那麼隨著業務的增長,基礎平臺是抽象出來了,但依然需要大量人力成本去維護去學習。本來搞個平臺層面的東西就想自動化壓低成本,現在倒好概念能和前端界一樣日新月異靠人堆,個人覺得並不是什麼好事情。在戰爭結束前 Kubernetes 可能還沒這麼多爭議,戰爭結束後眾口難調的情況下只有這一個靶子,攤手。可以想象得出隨著時間的增長對 Kubernetes 複雜度的吐槽將會越來越多。同樣的,我也預計不久的將來,和 Apache httpd 終究遭遇了 nginx 一樣,編排和調度系統的 「nginx」也會出現在我們視野,就像老牌 Hashicrop 下的 Nomad[8] 一樣等待著和 Kubernetes 平分天下。

新的戰場

Docker 是輸了編排和調度,也失去了那種號令天下的霸權。然而對 Kubernetes 來說最不幸的是產生容器的「工廠」標準依然在 Docker 手中。
無論是 OCI 鏡像標準和 Docker 鏡像標準親兄弟,還是運行層面的 containerd。Kubernetes 整了 CRI/CNI 什麼的,又扶持了 CRI-O 還有隔壁 Rkt 什麼的,並沒有一點卵用,看看那個 AppC 的概念還有人提麽。containerd 在最新 RC 中內置 CRI 支持,可以直接替換 kubelet 的 dockershim 實現,也把之前的 cri-containerd 丟入了歷史的垃圾堆,已然成為了集大成的事實標準。
你 CRI-O 說自己測試完備率更高,高得過一直內置代碼在 Kubernetes 的 dockershim/containerd 一脈相承?你 rkt 說自己行程樹扁平,能比 containerd 直接掛容器到 systemd 下更平?況且都抽象控制平面了,下麵 Runtime 不都是支持 runC、runV 混布麽。還有你一個 CRI-O 別的不學,硬要去做個內置 Pod 你讓隔壁的 Kubelet 沒飯吃怎麼辦?
基礎設施是一定圖穩的,在目前換 CRI-O Rkt 等沒有明顯顯著優勢的情況下,甚至大劣的情況下,containerd 就是事實標準。Docker 回歸到了他應該在的位置,那就是容器「引擎」。當然了 containerd 的成功也是依托於 Kubernetes 的成功,隨著 dockershim 的實現走進千家萬戶。
而隨著 containerd 的日益成熟,新的編排系統,新的系統架構,也就有了新的血液。在這之上產生一個足以威脅到 Kubernetes 的新基礎設施系統,是完全可以期待的。

尾聲

即便站在 2018 年這個時間點上,我依然認為調度和編排還是一件可以做的事情。怎麼單獨的用 containerd 去驅動容器,怎麼解構複雜 Pod 轉變為 native container (1 process 1 container)再通過上層的組合完成複雜業務形態,怎麼通過 CNI 結合現有的基礎網絡等插件,怎麼實現更高效的萬台機器編排等,依然還有想象力空間。
舊的戰爭已經結束,新的戰場已經硝煙四起。對於 containerd 的前途而言我個人是比較看好的。沒有歷史的包袱,又向下兼容各類系統的接口,穩定性經過了大量生產實踐,還可以很方便的二次開發。也許過幾年我們就能看到基於其新的調度編排「nginx」了吧。
相關鏈接:
  1. https://projecteru2.gitbook.io/white-paper/

  2. http://cri-o.io/

  3. https://coreos.com/rkt/

  4. https://www.projectcalico.org/

  5. https://github.com/istio/istio

  6. https://linkerd.io/

  7. https://httpd.apache.org/

  8. https://www.nomadproject.io/

原文鏈接:https://zhuanlan.zhihu.com/p/35951990

Kubernetes入門與進階實戰培訓

本次培訓內容包括:Docker基礎、容器技術、Docker鏡像、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心組件原理分析、Kubernetes服務質量保證、調度詳解與應用場景、網絡、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等,點擊瞭解具體培訓內容

5月11日正式上課,點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂