Kubernetes運(yùn)維的訴求是什么

這篇文章主要講解了“Kubernetes運(yùn)維的訴求是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Kubernetes運(yùn)維的訴求是什么”吧！

K8s 的 CRD Operator 機(jī)制非常靈活而強(qiáng)大，不光是復(fù)雜應(yīng)用可以通過編寫 CRD Operator 實(shí)現(xiàn)，我們的運(yùn)維能力也大量通過 Operator 來擴(kuò)展，比如灰度發(fā)布、流量管理、彈性擴(kuò)縮容等等。

我們常常贊嘆于 K8s 的靈活性，它讓我們基礎(chǔ)平臺團(tuán)隊(duì)對外提供能力非常方便，但是對應(yīng)用運(yùn)維來說，他們要使用我們提供的這些運(yùn)維能力，卻變得有些困難。

比如我們上線了一個(gè) CronHPA，可以定時(shí)設(shè)置在每個(gè)階段會根據(jù) CPU 調(diào)整實(shí)例數(shù)的范圍。應(yīng)用運(yùn)維并不知道跟原生不帶定時(shí)功能的 HPA 會產(chǎn)生沖突，而我們也沒有一個(gè)統(tǒng)一的渠道幫助管理這么多種復(fù)雜的擴(kuò)展能力，結(jié)果自然是引起了故障。這血的教訓(xùn)提醒我們要做事前檢查，熟悉 K8s 的機(jī)制很容易讓我們想到為每個(gè) Operator 加上 admission webhook。

這個(gè) admission webhook 需要拿到這個(gè)應(yīng)用綁定的所有運(yùn)維能力以及應(yīng)用本身的運(yùn)行模式，然后做統(tǒng)一的校驗(yàn)。如果這些運(yùn)維能力都是一方提供的還好，如果存在兩方，甚至三方提供的擴(kuò)展能力，我們就沒有一個(gè)統(tǒng)一的方式去獲知了。

事實(shí)上如果我們想的更遠(yuǎn)一些就會發(fā)現(xiàn)，我們需要一個(gè)統(tǒng)一的模型來協(xié)商并管理這些復(fù)雜的擴(kuò)展能力。

當(dāng)我們把應(yīng)用的 Operator 以及對應(yīng)的運(yùn)維能力都寫好以后，我們很容易想到要打包交付這個(gè)應(yīng)用，這樣無論是公有云還是專有云都可以通過一個(gè)統(tǒng)一的方式去交互。社區(qū)的主流方式目前就是使用 Helm 來打包應(yīng)用，而我們也采用了這樣的方式給我們的用戶交付，但是卻發(fā)現(xiàn)我們的用戶需求遠(yuǎn)不止于此。

云原生應(yīng)用有一個(gè)很大的特點(diǎn)，那就是它往往會依賴云上的資源，包括數(shù)據(jù)庫、網(wǎng)絡(luò)、負(fù)載均衡、緩存等一系列資源。

當(dāng)我們使用 Helm 打包時(shí)，我們只能針對 K8s 原生 API，而如果我們還想啟動(dòng) RDS 數(shù)據(jù)庫，就比較困難了。如果不想去數(shù)據(jù)庫的交互頁面，想通過 K8s 的 API 來管理，那就又不得不去寫一個(gè) CRD 來定義了，然后通過 Operator 去調(diào)用實(shí)際云資源的 API。

這一整套交付物實(shí)際上就是一個(gè)應(yīng)用的完整描述，即我們所說的“應(yīng)用定義”。但事實(shí)上，我們發(fā)現(xiàn)“應(yīng)用定義”這個(gè)東西，在整個(gè)云原生社區(qū)里其實(shí)是缺失的。這也是為什么阿里巴巴內(nèi)部有很多團(tuán)隊(duì)開始嘗試設(shè)計(jì)了自己的“應(yīng)用定義”。

這種定義方式最終所有的配置還是會全部堆疊到一個(gè)文件里，這跟 K8s API all-in-one 的問題其實(shí)是一樣的，甚至還更嚴(yán)重了。而且，這些應(yīng)用定義最終也都成為了黑盒，除了對應(yīng)項(xiàng)目本身可以使用，其他系統(tǒng)基本無法復(fù)用，自然就更無法使得多方協(xié)作復(fù)用了。

事實(shí)上幾乎每個(gè)基于 K8s 管理應(yīng)用的公司和團(tuán)隊(duì)都在自己定義應(yīng)用。如下所示，我就搜到了兩家公司的應(yīng)用定義：

應(yīng)用定義實(shí)際上是應(yīng)用交付/分發(fā)不可或缺的部分。但是在具體的實(shí)踐中，我們感受到這些內(nèi)部的應(yīng)用定義都面臨著如下的問題：

1. 定義是否足夠開放，是否可以復(fù)用？

2. 如何與開源生態(tài)協(xié)作？

3. 如何迭代與演進(jìn)？

這三個(gè)問題帶來的挑戰(zhàn)都是巨大的，我在上文已經(jīng)提到，一個(gè)應(yīng)用定義需要容易上手，但又不失靈活性，更不能是一個(gè)黑盒。應(yīng)用定義同樣需要跟開源生態(tài)緊密結(jié)合，沒有生態(tài)的應(yīng)用定義注定是沒有未來的，自然也很難持續(xù)的迭代和演進(jìn)。

讓我們回過頭來重新審視我們面臨的挑戰(zhàn)，歸根結(jié)底在于 K8s 的 All in One API 是為平臺提供者設(shè)計(jì)的，我們不能像下圖左側(cè)顯示的一樣，讓應(yīng)用的研發(fā)、運(yùn)維跟 K8s 團(tuán)隊(duì)一樣面對這一團(tuán) API。

一個(gè)合理的應(yīng)用模型應(yīng)該具有區(qū)分使用者角色的分層結(jié)構(gòu)，同時(shí)將運(yùn)維能力模塊化的封裝。讓不同的角色使用不同的 API，正如上圖右側(cè)部分。

感謝各位的閱讀，以上就是“Kubernetes運(yùn)維的訴求是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Kubernetes運(yùn)維的訴求是什么這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！