Kubernetes對應用開發者來說是不是太復雜了?

幾周前，我參加了KubeCon EU大會，并發表了演講。這是一個大約有4700人參加的大型活動，讓我想起了2014年11月在巴黎舉行的OpenStack峰會。同樣是人潮涌動，廠商露臉，程序員派對……然而，我發現了一個根本性問題：我遇到的幾乎是清一色的運維人員或SRE工程師。應用程序開發人員都去哪兒了?這些復雜的基礎設施不是應該為這些人提供服務的嗎?Kubernetes社區是否真的關注用戶的需求?于是我禁不住想：Kubernetes是否太復雜了?它的復雜性會阻礙自身的發展嗎?

我這樣想似乎有點太過了，不過我不認為最終會出現這種情況。相比OpenStack，Kubernetes有自己獨到的優勢。首先，它具有更高的可擴展性，因此能夠在擁有數千臺服務器的環境中實現大規模集群調度。其次，三家主要云供應商已經推出了Kubernetes托管服務產品。在短短的四年時間里，Kubernetes幾乎成為云計算和基礎設施領域的事實標準。不過，Kubernetes的復雜性對大家來說仍然是一個問題。OpenStack在2014年以后漸趨頹勢，Kubernetes會步入OpenStack的后塵嗎?

[[238474]]

大多數開發人員沒有Google那樣的規模問題

Kubernetes的推出旨在解決類似Google那樣規模的復雜性和問題。我們希望基礎設施具有自我修復、水平伸縮和聲明式配置(如基礎設施即代碼)能力。但問題是，絕大多數應用程序和應用程序開發人員不會面臨這些問題。大多數應用程序只有適度的規模(包括項目規模和用戶群)，或者它們還處在市場產品研究的早期階段。

在應用程序還沒有達到規模化之前，通常沒有必要增加這些復雜性。在這種情況下，單個數據庫和應用程序服務器可能是更好的選擇，只要它們能夠處理你的流量負載。如果99.5%的時間是可用的，并具有完備的運維警報，那么對于大部分應用程序和工作負載來說已經很不錯了。建立分布式系統所帶來的復雜性以及對上市時間造成的延遲只會讓我們得不償失。

對于全新的應用程序來說，它們***的風險是找不到目標產品或市場。也就是說，這些應用程序雖然被部署了，但從未被使用過。它們的代碼最終被遺棄，因為沒有人想要使用這些應用程序。這是絕大多數應用程序的代碼可能會面臨的處境。在我的職業生涯中，大部分時間都花在了代碼和功能的迭代上，并嘗試找到正確的應用程序功能集。一旦找到了，就可以對其進行擴展，但在此之前所做的努力都只不過是不成熟的優化。

我認為Kubernetes的問題在于它對項目早期階段的認知負載有很高的要求。在一開始就需要考慮很多事情，這對于啟動項目和快速迭代來說是一種阻礙。在項目的早期階段，功能開發速度和迭代速度是最重要的。我認為Heroku是一個理想的開發模型，可以一邊使用Postgres托管數據庫，一邊通過Git推送來部署新代碼并對外提供服務，不需要考慮太多的東西。它可能無法***擴展，并且可能會很貴，但在應用程序達到規模化之前，根本不需要擔心這些問題。

簡單地說，Kubernetes讓簡單的事情變復雜，讓解決復雜的問題成為可能。如果Kubernetes想要取得真正的成功，需要讓項目的早期階段變得更簡單，并降低應用程序開發人員的認知負擔。要讓開發者在某個時刻開始學習Kubernetes錯綜復雜的細節，這并不是什么問題，因為隨著規模增長，一切事物都會變得復雜和棘手。但作為一個成功的開發平臺，不應該在沒有必要的情況下將這些決策壓力放在開發者面前。Ruby on Rails之父David Heinemeier Hansson(網絡代號DHH)在RailsConf 2018主題演講中將這種情況稱為“JIT Learning(即時學習)”。

我想用Rails作為例子：為什么Rails當時如此成功?并不是因為Ruby的流行(它當時只是來自日本的一門新的編程語言)，也不是因為Rails和Ruby在動態網頁方面的優異表現，而是因為它們可以提高開發人員的生產力。DHH給大家介紹了如何用15分鐘創建一個博客，這引起了Java和.NET開發人員的注意，因為他們需要花幾個星期甚至幾個月才能做出同樣的東西。開發人員選擇Rails是因為他們可以更快地向用戶發布功能，而這正是這些框架和基礎設施能夠提供的。

Rails為開發者創建應用程序骨架，并生成腳手架和部分項目代碼。開發人員不需要在項目開始時做出大量決策，比如應該如何組織應用程序代碼、數據庫模型應該放在哪里、應該定義怎樣的asset管道、如何進行數據庫遷移以及完成其他的任務和決策。

我認為Kubernetes也可以從這類生成器中受益。現在已經有一些特定的資源生成器，但還遠遠無法滿足需求。如果有針對不同類型應用程序的模板，那就更好了。關系數據庫、應用程序層、緩存服務器、消息隊列和工作線程池的組合占到了構建應用程序的90%甚至更多，這種簡單的結構可以擴展到令人難以置信復雜程度。模板或生成器可以生成開箱即用且具有Kubernetes組織結構的資源和代碼，這將非常有用。

用于生成共公元素的腳手架生成器就很不錯。需要一個MySQL數據庫?可以使用類似下面的命令

kubectl scaffold mysql --generate 

來創建一組有狀態的服務和其他必需的東西。然后，只需一個命令就可以將腳手架部署到k8s環境中，然后再使用幾個控制臺命令即可擁有一個生產就緒的數據庫。對于流行的應用程序框架、消息代理服務器以及我們能夠想到的其他任何東西，都可以使用類似的方法。

或許Operator和Helm的組合就可以完成這些工作，但我認為這樣還不夠好。因為開發人員在Kubernetes之外還需要了解兩個額外的工具。即使是了解簡單的技術術語和安裝新的命令行工具也需要額外的努力和思考。這些東西應該成為Kubernetes開箱即用體驗的一部分，并可以直接通過kubectl來訪問。

CNCF的領地越來越廣闊

CNCF中的項目越來越多，這對Kubernetes來說算不上是特別的問題，但CNCF項目的格局非常龐大，以致于KubeCon/CNCF大會非常分散，一個大會就包含了14個主題。作為開發人員，我怎么知道哪些工具適合我的項目?看一下CNCF中的項目：

要了解圖中所有的項目是不可能的。如果已經存在一組預選好的工具，那么應用程序開發者將會有更好的體驗。如果他們想加入不同的工具，完全沒問題，但至少不應該讓他們在事先就去考慮這些問題。CNCF日益增長的復雜性和廣泛的影響力可能會淡化Kubernetes作為構建平臺的品牌效應。我不確定結果會怎樣，也不確定我是否在夸大其詞，但是就我看來，它更像是一種工具大雜燴。當你費勁畢生精力來學習和構建基礎設施工具時，還會有精力去解決用戶的問題嗎?

我想強調的是：基礎設施的存在是為了幫助應用程序開發人員解決用戶的實際問題，它們需要不斷優化，提高交付的效率和能力。能夠做到這一點的開放平臺才會勝出。

必要的知識

在某些時候，開發人員需要更深入地學習基礎設施工具。大多數在AWS工作的開發人員都熟悉AWS的一些組件，就像Google Cloud Platform或Azure開發人員熟悉他們的云一樣。將Kubernetes作為基礎層更有可能成功，因為開發人員只需要學習Kubernetes，就能在任何公共云或私有云上使用。

不過Kubernetes的學習曲線并不平穩。作為一個生態系統，Kubernetes需要滿足應用程序開發人員的需求才能真正取得成功。畢竟，基礎設施是解決用戶問題的支持工具。提高應用程序開發人員的工作效率才是確保一個平臺能夠被廣泛采用并取得成功的***途徑。