撰稿 | 云昭 

出品 | 51CTO技術棧（微信號：blog51cto）

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

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，為了微服務而上微服務，即便可能壓根就不需要它。

圖源：知乎

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 容器編排王者地位的新產品，讓即使是開發運維經驗有限的人，也能夠描述他們想要什么，并由平臺負責實現。

7、寫在最后

當然，持續的吸收擴展，讓 Kubernetes 快速在云原生時代壯大，但快速吸收新功能的“吸星大法”，也開始出現了反噬。目前，Kubernetes 在容器編排領域的賽道上，正在被拖慢速度，而新對手正虎視眈眈，試圖超越。

正如一位業內人士建議 Hockin 的那樣“延遲滿足”：為了保持活力，Kubernetes 應該保持未完成狀態！

參考鏈接：

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?