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

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

我這樣想似乎有點(diǎn)太過(guò)了，不過(guò)我不認(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)。不過(guò)，Kubernetes的復(fù)雜性對(duì)大家來(lái)說(shuō)仍然是一個(gè)問(wèn)題。OpenStack在2014年以后漸趨頹勢(shì)，Kubernetes會(huì)步入OpenStack的后塵嗎?

[[238474]]

大多數(shù)開(kāi)發(fā)人員沒(méi)有Google那樣的規(guī)模問(wèn)題

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

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

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

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

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

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

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

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

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

kubectl scaffold mysql --generate 

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

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

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

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

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

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

必要的知識(shí)

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

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