Kubernetes會不會被自身的複雜性壓垮？

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

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

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

大多數開發人員沒有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需要滿足應用程式開發人員的需求才能真正取得成功。畢竟，基礎設施是解決使用者問題的支援工具。提高應用程式開發人員的工作效率才是確保一個平臺能夠被廣泛採用並取得成功的最佳途徑。