Kubernetes對(duì)應(yīng)用開發(fā)者來說是不是太復(fù)雜了?

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

我這樣想似乎有點(diǎn)太過了，不過我不認(rèn)為最終會(huì)出現(xiàn)這種情況。相比OpenStack，Kubernetes有自己獨(dú)到的優(yōu)勢(shì)。首先，它具有更高的可擴(kuò)展性，因此能夠在擁有數(shù)千臺(tái)服務(wù)器的環(huán)境中實(shí)現(xiàn)大規(guī)模集群調(diào)度。其次，三家主要云供應(yīng)商已經(jīng)推出了Kubernetes托管服務(wù)產(chǎn)品。在短短的四年時(shí)間里，Kubernetes幾乎成為云計(jì)算和基礎(chǔ)設(shè)施領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。不過，Kubernetes的復(fù)雜性對(duì)大家來說仍然是一個(gè)問題。OpenStack在2014年以后漸趨頹勢(shì)，Kubernetes會(huì)步入OpenStack的后塵嗎?

[[238474]]

大多數(shù)開發(fā)人員沒有Google那樣的規(guī)模問題

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

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

對(duì)于全新的應(yīng)用程序來說，它們***的風(fēng)險(xiǎn)是找不到目標(biāo)產(chǎn)品或市場(chǎng)。也就是說，這些應(yīng)用程序雖然被部署了，但從未被使用過。它們的代碼最終被遺棄，因?yàn)闆]有人想要使用這些應(yīng)用程序。這是絕大多數(shù)應(yīng)用程序的代碼可能會(huì)面臨的處境。在我的職業(yè)生涯中，大部分時(shí)間都花在了代碼和功能的迭代上，并嘗試找到正確的應(yīng)用程序功能集。一旦找到了，就可以對(duì)其進(jìn)行擴(kuò)展，但在此之前所做的努力都只不過是不成熟的優(yōu)化。

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

簡單地說，Kubernetes讓簡單的事情變復(fù)雜，讓解決復(fù)雜的問題成為可能。如果Kubernetes想要取得真正的成功，需要讓項(xiàng)目的早期階段變得更簡單，并降低應(yīng)用程序開發(fā)人員的認(rèn)知負(fù)擔(dān)。要讓開發(fā)者在某個(gè)時(shí)刻開始學(xué)習(xí)Kubernetes錯(cuò)綜復(fù)雜的細(xì)節(jié)，這并不是什么問題，因?yàn)殡S著規(guī)模增長，一切事物都會(huì)變得復(fù)雜和棘手。但作為一個(gè)成功的開發(fā)平臺(tái)，不應(yīng)該在沒有必要的情況下將這些決策壓力放在開發(fā)者面前。Ruby on Rails之父David Heinemeier Hansson(網(wǎng)絡(luò)代號(hào)DHH)在RailsConf 2018主題演講中將這種情況稱為“JIT Learning(即時(shí)學(xué)習(xí))”。

我想用Rails作為例子：為什么Rails當(dāng)時(shí)如此成功?并不是因?yàn)镽uby的流行(它當(dāng)時(shí)只是來自日本的一門新的編程語言)，也不是因?yàn)镽ails和Ruby在動(dòng)態(tài)網(wǎng)頁方面的優(yōu)異表現(xiàn)，而是因?yàn)樗鼈兛梢蕴岣唛_發(fā)人員的生產(chǎn)力。DHH給大家介紹了如何用15分鐘創(chuàng)建一個(gè)博客，這引起了Java和.NET開發(fā)人員的注意，因?yàn)樗麄冃枰◣讉€(gè)星期甚至幾個(gè)月才能做出同樣的東西。開發(fā)人員選擇Rails是因?yàn)樗麄兛梢愿斓叵蛴脩舭l(fā)布功能，而這正是這些框架和基礎(chǔ)設(shè)施能夠提供的。

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

我認(rèn)為Kubernetes也可以從這類生成器中受益?，F(xiàn)在已經(jīng)有一些特定的資源生成器，但還遠(yuǎn)遠(yuǎn)無法滿足需求。如果有針對(duì)不同類型應(yīng)用程序的模板，那就更好了。關(guān)系數(shù)據(jù)庫、應(yīng)用程序?qū)?、緩存服?wù)器、消息隊(duì)列和工作線程池的組合占到了構(gòu)建應(yīng)用程序的90%甚至更多，這種簡單的結(jié)構(gòu)可以擴(kuò)展到令人難以置信復(fù)雜程度。模板或生成器可以生成開箱即用且具有Kubernetes組織結(jié)構(gòu)的資源和代碼，這將非常有用。

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

kubectl scaffold mysql --generate 

來創(chuàng)建一組有狀態(tài)的服務(wù)和其他必需的東西。然后，只需一個(gè)命令就可以將腳手架部署到k8s環(huán)境中，然后再使用幾個(gè)控制臺(tái)命令即可擁有一個(gè)生產(chǎn)就緒的數(shù)據(jù)庫。對(duì)于流行的應(yīng)用程序框架、消息代理服務(wù)器以及我們能夠想到的其他任何東西，都可以使用類似的方法。

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

CNCF的領(lǐng)地越來越廣闊

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

要了解圖中所有的項(xiàng)目是不可能的。如果已經(jīng)存在一組預(yù)選好的工具，那么應(yīng)用程序開發(fā)者將會(huì)有更好的體驗(yàn)。如果他們想加入不同的工具，完全沒問題，但至少不應(yīng)該讓他們?cè)谑孪染腿タ紤]這些問題。CNCF日益增長的復(fù)雜性和廣泛的影響力可能會(huì)淡化Kubernetes作為構(gòu)建平臺(tái)的品牌效應(yīng)。我不確定結(jié)果會(huì)怎樣，也不確定我是否在夸大其詞，但是就我看來，它更像是一種工具大雜燴。當(dāng)你費(fèi)勁畢生精力來學(xué)習(xí)和構(gòu)建基礎(chǔ)設(shè)施工具時(shí)，還會(huì)有精力去解決用戶的問題嗎?

我想強(qiáng)調(diào)的是：基礎(chǔ)設(shè)施的存在是為了幫助應(yīng)用程序開發(fā)人員解決用戶的實(shí)際問題，它們需要不斷優(yōu)化，提高交付的效率和能力。能夠做到這一點(diǎn)的開放平臺(tái)才會(huì)勝出。

必要的知識(shí)

在某些時(shí)候，開發(fā)人員需要更深入地學(xué)習(xí)基礎(chǔ)設(shè)施工具。大多數(shù)在AWS工作的開發(fā)人員都熟悉AWS的一些組件，就像Google Cloud Platform或Azure開發(fā)人員熟悉他們的云一樣。將Kubernetes作為基礎(chǔ)層更有可能成功，因?yàn)殚_發(fā)人員只需要學(xué)習(xí)Kubernetes，就能在任何公共云或私有云上使用。

不過Kubernetes的學(xué)習(xí)曲線并不平穩(wěn)。作為一個(gè)生態(tài)系統(tǒng)，Kubernetes需要滿足應(yīng)用程序開發(fā)人員的需求才能真正取得成功。畢竟，基礎(chǔ)設(shè)施是解決用戶問題的支持工具。提高應(yīng)用程序開發(fā)人員的工作效率才是確保一個(gè)平臺(tái)能夠被廣泛采用并取得成功的***途徑。