分享下雲原生技術之外的另類話題

好久沒 K8S 相關的原創了,懶得更新了,主要不知道寫了是否會有幫助。直到最近幾天有同學跟我探討引入了一堆雲原生組件,不僅沒有提高效率,反而徒增了很多心智負擔。我纔想起來好久沒有更文了,應該爲大夥分享一些自己的所見所聞。本想寫點硬核技術,後來作罷;一來技術文章讀起來傷腦筋,二來 K8S 相關的技術及最佳實踐文章氾濫,基本遇到的問題都有解決方案,所以今天主要聊聊 K8S 技術細節之外的一些另類話題。

可以想想爲啥 K8S 會成爲各個雲廠商及中大型公司的基礎設施? 比如 Facebook 的 Twine,它的設計跟 K8S 反其道而行之,規避了 K8S 的中心化設計,能夠容納更多的節點、管理更多的機器。但是卻沒有進入我們的視野,究其原因,K8S 足夠開源、中立,核心組件都是插件式設計,保持了軟件設計的靈活性,允許社區及雲廠商進行定製開發;各大雲廠商嘗試之後發現能夠起到降本增效的作用,開始定製屬於自己的技術和標準;這樣下游的大中型公司可以直接使用或者購買雲廠商開放出來技術或者平臺;上游運營盈利者、標準制定開發者、下游使用者相互促進,從而形成了互利共贏的良性循環。

而對於有些組織,對安全有一定要求,很多服務不允許直接使用公有云,只能搭建以 K8S 爲基礎搭建自己的私有云平臺,說着也很簡單,谷歌多年的沉澱,頭部雲廠商都在使用,理論上沒有任何技術問題。之前有個同事給我說,以 K8S 爲中心的相關雲原生技術其實非常簡單,基於 docker 的容器化打包技術,定義好編排文件,發佈到 K8S 平臺,拉起服務,支持擴容.....

50W 以上的核心代碼,僅次於一個操作系統;再看看 K8S 發佈速度和 bug 修復數量。另外重點來了,各種組件出現的數量,各種容器運行時、各種日誌收集組件 Loki、fluentd、EFK、監控工具、應用管理工具 OAM、各種集羣管理工具,應接不暇,我該怎麼選擇? 別的不說,最起碼得根據自己的使用場景,每種類型的要選擇一種吧。

但是問題來了,我選擇了一堆可以滿足使用場景的工具,這些工具應該如何串聯起來?

我之前曾面試過某上萬人造車公司,問了我一個問題,以 K8S 爲中心的各種基礎設施,應該如何管理? 比如認證、授權,甚至如何讓相關人員輕而易舉的發現和使用這些基礎設施?

如果使用規模比較小,可以做一個導航頁面,在頁面裏面列舉所有的組件,大家可以一目瞭然的看到所有的組件,自己選擇使用了。如果使用規模比較大,可以做一個單點登陸認證系統,這樣方便一鍵登錄所有系統使用。

現在回想起來,我的想法實在天真。

雲原生體系的組件特別多,如果大家共用一個賬號肯定有問題,各自組件中申請賬號又沒有辦法管理,所以單點登錄只是最基本的要求。如果公司有 ldap 域賬戶可以同步過來使用,如果沒有可能要自己通過其它方式錄入人員信息了。某種意義上說,你要自己做一個單點登錄系統,需要把各種雲原生組件串聯起來,或者說你需要在各種雲原生組件界面上添加屬於自己的登錄跳轉界面,這種高度定製化的功能,雲原生社區沒人幫你實現。

登錄進去之後,老闆們一定希望不同的人看到的菜單是不一樣的,防止誤操作,多麼接地氣的需求。如果雲原生組件做的好,那麼你就可以對接他們的菜單權限管理功能,如果沒有,可能你要自己實現了。但是不管怎樣,你又要定製雲原生組件了。

如果身邊有個同事換了個部門,需要另外一個服務的增刪改查權限,怎麼辦? 發郵件申請,你會發現在人工智能高速發展的今天,很多事情不得不人肉完成,最後迫於無奈,你只能開發一套權限申請系統,自行申請權限,只需要對應部門的同事批准即可,不管怎樣,還是會存在一定程度的開發成本和工作量。

上面這些其實都是基本權限管理,對於一些服務上線前的資源申請、服務接入、甚至一些自助日誌接入系統,都需要相應的管理平臺,這些平臺聽起來都很簡單,沒什麼複雜度,但是結合到你的實際使用場景,很難找到現成的.....

雲原生指的是你的上層應用原生了,雲原生基礎設施自身並不原生。

說到這裏,有些同學可能要擡槓了,我們的幾十臺機器用的就非常簡單,那麼恭喜你,你之所以覺得簡單,可能是享受到了 K8S 給我們帶來的技術紅利,也可能你的集羣規模還不足以使用 K8S 進行管理。K8S 本身是用來管理上千個物理節點的。你非要用它來管理你的幾十臺物理機。雖然你的硬件資源不需要人肉管理,但是你需要專業運維人員去維護 K8S 集羣,最終小規模集羣可以帶來的收益和付出的成本,基本上可以抵消;或者引入更多的成本、更高的學習複雜度。之前寫過一篇關於小公司使用 K8S 帶來的問題,有興趣的可以參考:過早關注基礎設施建設是萬惡之源

人總是喜歡高估現在自己,很多事情看起來都不會太複雜,如果真的太複雜,基本當時就放棄了。當你真正入手去做的時候,你會發現各種不合適,各種需要定製化,領導期望一再降低,週期一直推遲,預算持續增長。這大概也就是很多雲廠商重複造輪子的原因。洋洋灑灑扯了這麼多,也沒有說個解決方案,其實這種事情不用說,說了也沒用,只是做的時候心裏有譜就行了。

推薦

Kubernetes入門培訓(內含PPT)

A Big Picture of Kubernetes


原創不易,隨手關注或者”在看“,誠摯感謝!

本文分享自微信公衆號 - 雲原生技術愛好者社區(programmer_java)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章