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

成都網(wǎng)站建設(shè)、成都做網(wǎng)站,成都做網(wǎng)站公司-成都創(chuàng)新互聯(lián)公司已向上千余家企業(yè)提供了,網(wǎng)站設(shè)計(jì),網(wǎng)站制作,網(wǎng)絡(luò)營(yíng)銷(xiāo)等服務(wù)!設(shè)計(jì)與技術(shù)結(jié)合,多年網(wǎng)站推廣經(jīng)驗(yàn),合理的價(jià)格為您打造企業(yè)品質(zhì)網(wǎng)站。

1. 運(yùn)維能力眾多卻難以管理

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

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

比如我們上線了一個(gè) CronHPA，可以定時(shí)設(shè)置在每個(gè)階段會(huì)根據(jù) CPU 調(diào)整實(shí)例數(shù)的范圍。應(yīng)用運(yùn)維并不知道跟原生不帶定時(shí)功能的 HPA 會(huì)產(chǎn)生沖突，而我們也沒(méi)有一個(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ò)展能力，我們就沒(méi)有一個(gè)統(tǒng)一的方式去獲知了。

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

2. 云資源難以描述和統(tǒng)一交付

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

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

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

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

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

3. 每個(gè)公司和團(tuán)隊(duì)都在自己定義應(yīng)用

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

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

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

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

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

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

 

 區(qū)分使用者的分層模型與模塊化的封裝

讓我們回過(guò)頭來(lái)重新審視我們面臨的挑戰(zhàn)，歸根結(jié)底在于 K8s 的 All in One API 是為平臺(tái)提供者設(shè)計(jì)的，我們不能像下圖左側(cè)顯示的一樣，讓?xiě)?yīng)用的研發(fā)、運(yùn)維跟 K8s 團(tuán)隊(duì)一樣面對(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)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)Kubernetes運(yùn)維的訴求是什么這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

新聞標(biāo)題：Kubernetes運(yùn)維的訴求是什么
文章轉(zhuǎn)載：http://chinadenli.net/article14/jogode.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、定制網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)公司、ChatGPT、App設(shè)計(jì)、軟件開(kāi)發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)