撰稿 | 云昭 

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

Kubernetes 變得太復(fù)雜了，它需要學(xué)會(huì)克制，否則就會(huì)停止創(chuàng)新，直至丟失大本營(yíng)。

Kubernetes 聯(lián)合創(chuàng)始人 Tim Hockin 罕見(jiàn)發(fā)聲。在今年的 KubeCon 上，他建議，Kubernetes 核心維護(hù)者應(yīng)該權(quán)衡提議的新功能的好處和它們帶來(lái)的額外復(fù)雜性。

1、Kubernetes 不那么閃亮了！

當(dāng)初那個(gè)容器編排的平臺(tái)，越來(lái)越不像自己了。K8s 本身也在變得越來(lái)越復(fù)雜，不僅開(kāi)發(fā)和運(yùn)維人員不堪其重，就連 K8s 內(nèi)部人員也開(kāi)始發(fā)聲了。

Kubernetes 聯(lián)合創(chuàng)始人、Google 杰出軟件工程師 Tim Hockin 開(kāi)始擔(dān)憂 K8s 的未來(lái)。

Kubernetes 最初由 Google 工程師于2014年創(chuàng)建，兩年后成為云原生計(jì)算基金會(huì)的第一個(gè)托管項(xiàng)目，也是繼 Linux 之后全球第二大的開(kāi)源項(xiàng)目。

高效、可擴(kuò)展是 K8s 一直以來(lái)的亮點(diǎn)，尤其是可擴(kuò)展，不僅可以部署和管理應(yīng)用程序的可擴(kuò)展性，同時(shí)還能讓開(kāi)發(fā)團(tuán)隊(duì)專(zhuān)注于創(chuàng)新軟件，也能為企業(yè)為新興技術(shù)做好準(zhǔn)備。

9年（半）過(guò)去，K8s 這個(gè)便士也許沒(méi)那么閃閃“發(fā)光”了?！耙郧八菫楦叨瓤蓴U(kuò)展的應(yīng)用程序做支持，現(xiàn)在正慢慢成為更復(fù)雜工作的首選平臺(tái)，比如機(jī)器學(xué)習(xí)推理?！币粋€(gè)典型的例子就是，兩年前 Kubeflow 被用于 Tensorflow 模型的部署和推理，還有最近的 LLMOps 同樣也看到了 Kubernetes 的身影。 

2、最緊迫的挑戰(zhàn) 

“你認(rèn)為 K8s 最緊迫的挑戰(zhàn)是什么？”Hockin 毫無(wú)遮掩地向云原生社區(qū)詢問(wèn)。

沒(méi)錯(cuò)，意料之中的那個(gè)答案在場(chǎng)上被反復(fù)提及：部署和維護(hù)容器編排引擎的復(fù)雜性實(shí)在恐怖！讓所有這些復(fù)雜性推給開(kāi)發(fā)運(yùn)維人員，簡(jiǎn)直是場(chǎng)噩夢(mèng)！有人甚至說(shuō)這是 K8s 的“最大的生存威脅”。

“必須付出一些代價(jià)，”Hockin 指出這就是K8s這么多年來(lái)吸收許多復(fù)雜性項(xiàng)目進(jìn)來(lái)所付出的代價(jià)。不止最終用戶，核心維護(hù)人員同樣也受到了復(fù)雜性的影響。

復(fù)雜性越高，K8s 核心維護(hù)人員在未來(lái)輕松進(jìn)行更改的敏捷性就越低。同時(shí)，軟件越復(fù)雜，用戶的阻力就越大。  

Kubernetes 正在讓開(kāi)發(fā)人員不堪重負(fù)。不使用 K8s 之前，開(kāi)發(fā)工程師要做的是：開(kāi)發(fā)應(yīng)用程序，編寫(xiě)，測(cè)試，打包和部署。但有了 K8s 之后，開(kāi)發(fā)流程全顛覆了：

對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，運(yùn)維任務(wù)變得繁重。尤其當(dāng)平臺(tái)工程團(tuán)隊(duì)介入時(shí)，往往代表著一場(chǎng)戰(zhàn)斗即將來(lái)臨，他們往集群里甩入工件的同時(shí)，也對(duì)質(zhì)量要求有著不低的預(yù)期，然而說(shuō)服開(kāi)發(fā)人員按照平臺(tái)工程的要求去做，往往需要不少回合的 battle。 

3、兩條疲勞鴻溝

Kubernetes 從一個(gè)容器編排平臺(tái)到如今的龐大生態(tài)，為云原生時(shí)代的開(kāi)發(fā)運(yùn)維創(chuàng)造了兩條需要跨越的“疲勞鴻溝”。DevOps 團(tuán)隊(duì)在轉(zhuǎn)向云原生架構(gòu)時(shí)必須擴(kuò)展其專(zhuān)業(yè)領(lǐng)域，沒(méi)錯(cuò)，這明顯超出他們的舒適區(qū)。

雙方都必須學(xué)習(xí)比他們的舒適區(qū)所允許的更多的技能：基礎(chǔ)設(shè)施團(tuán)隊(duì)成員必須更加適應(yīng)開(kāi)發(fā)人員的需求，而開(kāi)發(fā)人員的工作量越來(lái)越多地覆蓋了與基礎(chǔ)設(shè)施相關(guān)的任務(wù)。

具體來(lái)講，開(kāi)發(fā)人員需要更加了解基礎(chǔ)設(shè)施問(wèn)題，另一方面，運(yùn)維、基礎(chǔ)設(shè)施或系統(tǒng)工程人員越來(lái)越接近開(kāi)發(fā)方面，因?yàn)榫帉?xiě) Kubernetes 資源或 Kubernetes YAML 的方式難免需要向軟件開(kāi)發(fā)的同事學(xué)習(xí)，因?yàn)樯婕暗降?/p>

更為可怕的是，截止現(xiàn)在都仍有一種迷戀新技術(shù)的誤區(qū)：為了K8s而上K8s，為了微服務(wù)而上微服務(wù)，即便可能壓根就不需要它。

圖源：知乎

4、復(fù)雜性“就像預(yù)算”總有花完的一天

Kubernetes 軟件是社區(qū)驅(qū)動(dòng)的：迄今為止，該社區(qū)已有了超過(guò)74680 名貢獻(xiàn)者，7812 家貢獻(xiàn)企業(yè)。這離不開(kāi)第一代 K8s 用戶的努力，但隨著新用戶的不斷加入，他們對(duì) Kubernetes 工作原理的興趣不可避免地衰減了，更多的是增加復(fù)雜的東西。

“我們添加的東西越復(fù)雜，我們消耗的預(yù)算就越多。當(dāng)預(yù)算用完時(shí)，糟糕的事情就會(huì)發(fā)生，K8s 的創(chuàng)新就會(huì)停止，用戶轉(zhuǎn)向其他解決方案?！?/p>

因此，Kubernetes 項(xiàng)目經(jīng)理需要將復(fù)雜性視為一種有限資源，比如稱(chēng)之為“復(fù)雜性預(yù)算”，不可能無(wú)限繼續(xù)下去。

頂級(jí) Kubernetes 工程師一致認(rèn)為：對(duì)于最終用戶甚至核心維護(hù)人員本身來(lái)說(shuō)，K8s 變得太復(fù)雜了。是時(shí)候?qū)?fù)雜性納入預(yù)算了。

5、K8s 內(nèi)部人員得更多說(shuō)“不”

Hockin 承認(rèn)，他不知道如何衡量一個(gè)軟件的復(fù)雜性，更不知道最終用戶處理復(fù)雜軟件的耐心程度。但他巧妙地轉(zhuǎn)化將復(fù)雜性問(wèn)題轉(zhuǎn)變成了一個(gè)預(yù)算問(wèn)題：“工程師通常知道自己何時(shí)超支預(yù)算?！?/p>

因此，當(dāng)考慮添加新功能時(shí)，他們必須問(wèn)這樣的問(wèn)題：我們是否有足夠的復(fù)雜性預(yù)算來(lái)承擔(dān)這個(gè)任務(wù)？我們應(yīng)該在這方面浪費(fèi)有限的預(yù)算嗎？

工程師的部分工作是權(quán)衡任何決策的權(quán)衡，新功能可能帶來(lái)的額外復(fù)雜性應(yīng)該是需要評(píng)估的因素之一。

對(duì)代碼庫(kù)的一些擴(kuò)充，可能會(huì)在軟件的某些方面帶來(lái) 5% 的性能提升，但如果這會(huì)給維護(hù)人員帶來(lái)更多的內(nèi)部復(fù)雜性來(lái)處理，那么還值得這樣做嗎？如果更改 API 以滿足特定用例，是否值得讓所有其他用戶承擔(dān)此更改帶來(lái)的負(fù)擔(dān)？

K8s 全部工作人員都需要提高標(biāo)準(zhǔn)，同時(shí)愿意說(shuō)“不”，“愿意對(duì)我們很像要的東西說(shuō)不，愿意對(duì)看起來(lái)不是壞主意的事情說(shuō)不，愿意對(duì)本身看起來(lái)顯而易見(jiàn)且容易的事情說(shuō)不，愿意對(duì)貢獻(xiàn)了我們看起來(lái)真正想要的東西說(shuō)不！”

通過(guò)對(duì)某些提案說(shuō)“不”，可以在復(fù)雜性預(yù)算中留下一些空間來(lái)處理未來(lái)更相關(guān)的項(xiàng)目。

Hockin 認(rèn)為，K8s 必須對(duì)今天的事情說(shuō)“不”，這樣我們明天才有能力做有趣的事情。 

Hockin 說(shuō)，我們都習(xí)慣于總是認(rèn)為越多越好，但 Kubernetes 現(xiàn)在可能更需要考慮“少即是多”。而且，Kubernetes 還有很多工作要做，但這并不意味著所有這些都需要立即完成。

6、K8s 被取代的跡象

K8s 是 Google 創(chuàng)建的，卻是并不適合所有企業(yè)。如果說(shuō)前幾年大家追逐新技術(shù)，為了 K8s 而采用 K8s，那么現(xiàn)在已經(jīng)將近十年的 K8s 正在產(chǎn)生慢慢被替代的跡象?！叭绻悴恍枰?Kubernetes，就不要采用它。”

即便在容器編排領(lǐng)域，由于它對(duì)開(kāi)發(fā)人員并不友好，需要大量的時(shí)間和理解來(lái)部署、操作和故障排除，企業(yè)不得不花費(fèi)大量時(shí)間用于管理 Kubernetes。最近兩年，企業(yè)們正在尋求其他可選項(xiàng)。

• 有的選擇將 Kubernetes 托管出去，使用一家云供應(yīng)商的托管 Kubernetes 服務(wù)；
• 有的則使用可以減少 K8s 操作的發(fā)行版，如 Red Hat 的 OpenShift；
• 有的則使用 HashiCorp 的 Nomad 這樣的替代品；
• 或者采用亞馬遜可持續(xù)發(fā)展架構(gòu)副總裁 Adrian Cockcroft 所說(shuō)的“無(wú)服務(wù)器優(yōu)先方法”，直接跳到 FaaS 產(chǎn)品，如 Azure 功能、亞馬遜網(wǎng)絡(luò)服務(wù)Lambda或谷歌云功能，并完全繞過(guò) Kubernetes。

此外，市面上也誕生了諸如 cycle.io 等致力于取代 K8s 容器編排王者地位的新產(chǎn)品，讓即使是開(kāi)發(fā)運(yùn)維經(jīng)驗(yàn)有限的人，也能夠描述他們想要什么，并由平臺(tái)負(fù)責(zé)實(shí)現(xiàn)。

7、寫(xiě)在最后

當(dāng)然，持續(xù)的吸收擴(kuò)展，讓 Kubernetes 快速在云原生時(shí)代壯大，但快速吸收新功能的“吸星大法”，也開(kāi)始出現(xiàn)了反噬。目前，Kubernetes 在容器編排領(lǐng)域的賽道上，正在被拖慢速度，而新對(duì)手正虎視眈眈，試圖超越。

正如一位業(yè)內(nèi)人士建議 Hockin 的那樣“延遲滿足”：為了保持活力，Kubernetes 應(yīng)該保持未完成狀態(tài)！

參考鏈接：

https://thenewstack.io/how-to-fight-kubernetes-complexity-fatigue/

https://thenewstack.io/tim-hockin-kubernetes-needs-a-complexity-budget/ 

https://blog.container-solutions.com/adrian-cockcroft-on-serverless-continuous-resilience?