Kube.NETes 變得太復雜了，它需要學會克制，否則就會停止創新，直至丟失大本營。

Kubernetes 聯合創始人Tim Hockin 罕見發聲。在今年的 KubeCon 上，他建議，Kubernetes 核心維護者應該權衡提議的新功能的好處和它們帶來的額外復雜性。

1、Kubernetes 不那么閃亮了！

當初那個容器編排的平臺，越來越不像自己了。K8s 本身也在變得越來越復雜，不僅開發和運維人員不堪其重，就連 K8s 內部人員也開始發聲了。

Kubernetes 聯合創始人、google 杰出軟件工程師 Tim Hockin 開始擔憂 K8s 的未來。

Kubernetes最初由Google工程師于2014年創建，兩年后成為云原生計算基金會的第一個托管項目，也是繼linux之后全丟第二大的開源項目。

高效、可擴展是K8s一直以來的亮點，尤其是可擴展，不僅可以部署和管理應用程序的可擴展性，同時還能讓開發團隊專注于創新軟件，也能為企業為新興技術做好準備。

9年（半）過去，K8s這個便士也許沒那么閃閃“發光”了。“以前它是為高度可擴展的應用程序做支持，現在正慢慢成為更復雜工作的首選平臺，比如機器學習推理。”一個典型的例子就是，兩年前Kubeflow被用于Tensorflow模型的部署和推理，還有最近的LLMOps同樣也看到了Kubernetes的身影。

2、最緊迫的挑戰

“你認為K8s最緊迫的挑戰是什么？”Hockin 毫無遮掩地向云原生社區中詢問。

沒錯，意料之中的那個答案在場上被反復提及：部署和維護容器編排引擎的復雜性實在恐怖！讓所有這些復雜性推給開發運維人員，簡直是場噩夢！有人甚至說這是 K8s 的“最大的生存威脅”。

“必須付出一些代價，”Hockin 指出這就是K8s這么多年來吸收許多復雜性項目進來所付出的代價。不止最終用戶，核心維護人員同樣也受到了復雜性的影響。

復雜性越高，K8s 核心維護人員在未來輕松進行更改的敏捷性就越低。同時，軟件越復雜，用戶的阻力就越大。

Kubernetes 正在讓開發人員不堪重負。不使用 K8s 之前，開發工程師要做的是：開發應用程序，編寫，測試，打包和部署。但有了 K8s 之后，開發流程全顛覆了：

對于開發人員來說，運維任務變得繁重。尤其當平臺工程團隊介入時，往往代表著一場戰斗即將來臨，他們往集群里甩入工件的同時，也對質量要求有著不低的預期，然而說服開發人員按照平臺工程的要求去做，往往需要不少回合的 battle。

3、兩條疲勞鴻溝

Kubernetes 從一個容器編排平臺到如今的龐大生態，為云原生時代的開發運維創造了兩條需要跨越的“疲勞鴻溝”。DevOps 團隊在轉向云原生架構時必須擴展其專業領域，沒錯，這明顯超出他們的舒適區。

雙方都必須學習比他們的舒適區所允許的更多的技能：基礎設施團隊成員必須更加適應開發人員的需求，而開發人員的工作量越來越多地覆蓋了與基礎設施相關的任務。

具體來講，開發人員需要更加了解基礎設施問題，另一方面，運維、基礎設施或系統工程人員越來越接近開發方面，因為編寫 Kubernetes 資源或 Kubernetes YAML 的方式難免需要向軟件開發的同事學習，因為涉及到迭代。

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

Kubernetes創始人發聲！K8s在被反噬！圖源：知乎

4、復雜性“就像預算”總有花完的一天

Kubernetes 軟件是社區驅動的：迄今為止，該社區已有了超過74680 名貢獻者，7812 家貢獻企業。這離不開第一代 K8s 用戶的努力，但隨著新用戶的不斷加入，他們對 Kubernetes 工作原理的興趣不可避免地衰減了，更多的是增加復雜的東西。

“我們添加的東西越復雜，我們消耗的預算就越多。當預算用完時，糟糕的事情就會發生，K8s 的創新就會停止，用戶轉向其他解決方案。”

因此，Kubernetes 項目經理需要將復雜性視為一種有限資源，比如稱之為“復雜性預算”，不可能無限繼續下去。

頂級 Kubernetes 工程師一致認為：對于最終用戶甚至核心維護人員本身來說，K8s 變得太復雜了。是時候將復雜性納入預算了。

5、K8s 內部人員得更多說“不”

Hockin 承認，他不知道如何衡量一個軟件的復雜性，更不知道最終用戶處理復雜軟件的耐心程度。但他巧妙地轉化將復雜性問題轉變成了一個預算問題：“工程師通常知道自己何時超支預算。”

因此，當考慮添加新功能時，他們必須問這樣的問題：我們是否有足夠的復雜性預算來承擔這個任務？我們應該在這方面浪費有限的預算嗎？

工程師的部分工作是權衡任何決策的權衡，新功能可能帶來的額外復雜性應該是需要評估的因素之一。

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

K8s 全部工作人員都需要提高標準，同時愿意說“不”，“愿意對我們很像要的東西說不，愿意對看起來不是壞主意的事情說不，愿意對本身看起來顯而易見且容易的事情說不，愿意對貢獻了我們看起來真正想要的東西說不！”

通過對某些提案說“不”，可以在復雜性預算中留下一些空間來處理未來更相關的項目。

Hockin 認為，K8s 必須對今天的事情說“不”，這樣我們明天才有能力做有趣的事情。

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

6、K8s 被取代的跡象

K8s是Google創建的，卻是并不適合所有企業。如果說前幾年大家追逐新技術，為了K8s而采用K8s，那么現在已經將近十年的K8s正在產生慢慢被替代的跡象。“如果你不需要Kubernetes，就不要采用它。”

即便在容器編排領域，由于它對開發人員并不友好，需要大量的時間和理解來部署、操作和故障排除，企業不得不花費大量時間用于管理Kubernetes。最近兩年，企業們正在尋求其他可選項。

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

此外，市面上也誕生了諸如 cycle.io 等致力于取代 K8s 容器編排王者地位的新產品，讓即使是開發運維經驗有限的人，也能夠描述他們想要什么，并由平臺負責實現。