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 應該保持未完成狀態！