容器云平臺(tái)容量規(guī)劃及管理優(yōu)化

1、隨著容器云平臺(tái)實(shí)踐的深入，容器基礎(chǔ)設(shè)施資源的分配和使用也 暴露出了前期產(chǎn)品設(shè)計(jì)的一些意料之外的問題。特別在證券行業(yè)，資 源的使用時(shí)段往往比較集中在上午9點(diǎn)到10點(diǎn)時(shí)段前后，過了這個(gè) 時(shí)段，資源的使用量就迅速下來(lái)了，所以平時(shí)看起來(lái)資源利用率很低、 很空閑，但各個(gè)團(tuán)隊(duì)又不敢輕易釋放資源，也就導(dǎo)致容器云平臺(tái)資源 的浪費(fèi)，使平臺(tái)容量的規(guī)劃和優(yōu)化比較困難。在原來(lái)各個(gè)團(tuán)隊(duì)自己管 理時(shí)，由于沒有相應(yīng)的資源使用監(jiān)控，也就不關(guān)注是否有資源浪費(fèi)。 但在容器云平臺(tái)，不得不考慮資源的規(guī)劃、需求預(yù)測(cè)、增長(zhǎng)趨勢(shì)、意 外卜處理等。既要考慮彈性擴(kuò)容，又要避免資源過度浪費(fèi)等，因此做好 容器云平臺(tái)的容量規(guī)劃和管理，并不是件很輕松

2、的事。工欲善其事，必先利其器。要做好容量的規(guī)劃和管理，就必須對(duì)容器 云平臺(tái)的資源分配情況和資源使用情況比較了解，并了解和理解用戶 的需求和關(guān)注點(diǎn)等，提升用戶體驗(yàn)和滿意度。如何讓租戶用戶更好的了解和理解自己的資源使用情況？分配量、使 用量、可用量等該怎么展示？不同的對(duì)象該面向哪些角色和人員?等 等都需要認(rèn)真的考慮和規(guī)劃。從管理員視角，我們需要知道每個(gè)租戶分配了多少資源、分出去了多 少資源、使用了多少資源、可用的資源等。在私有云環(huán)境，我們不僅 要關(guān)心租戶用多少資源，還要關(guān)心資源的使用效率。不是說資源隨便 分配隨便用，好鋼用在刀刃上，因此，雖然私有云環(huán)境不進(jìn)行計(jì)費(fèi)， 但要關(guān)心資源的使用效率。同時(shí)在用

3、戶界面上要簡(jiǎn)潔、一目了然。從租戶視角，我們要能很清晰的看到有多少資源，用了多少資源，可 用多少資源，這些資源分布在哪些集群上、哪些分區(qū)上，部署了多少 應(yīng)用、多少服務(wù)，有多少實(shí)例，資源的利用效率多高，請(qǐng)求峰值及資 源使用峰值及時(shí)點(diǎn)等，在每個(gè)服務(wù)和實(shí)例管理界面要能看到服務(wù)的配 置和實(shí)例的配置及資源使用情況和使用效率。例如如果一個(gè)服務(wù)分配 了大量資源卻一直利用率很低那么就是不合理的造成了資源浪費(fèi)， 就需要進(jìn)行調(diào)整，給它分配合適的資源。反過來(lái)，如果一個(gè)服務(wù)分配 的資源太少而服務(wù)可能無(wú)法啟動(dòng)，容器就可能不斷的嘗試重啟。因此 合理的資源分配和管理是容器云平臺(tái)重要的事項(xiàng)之一。總的來(lái)說，從用戶體驗(yàn)角度，容器云

4、平臺(tái)要盡可能提供完善的輔助能 力，幫助用戶提高資源分配和使用效率。二容器云平臺(tái)資源管理 我們討論過多集群的設(shè)計(jì)和管理及適用場(chǎng)景。在初始需求量不是很大 時(shí)不適合搭建多個(gè)集群，當(dāng)然需要根據(jù)業(yè)務(wù)的要求來(lái)確定，比如需要 多集群備份，就需要搭建至少兩個(gè)集群實(shí)現(xiàn)關(guān)鍵業(yè)務(wù)的備份部署。從容器云平臺(tái)角度，一定要有全局的頂層的平臺(tái)資源視角。平臺(tái)的資 源總量、使用量、分配量、可用量等，然后才是每個(gè)集群、每個(gè)分區(qū)、 每個(gè)租戶甚至每個(gè)節(jié)點(diǎn)的資源總量、分配量和使用量等。在實(shí)現(xiàn)容器 云平臺(tái)多集群不能只考慮kubernetes，不是實(shí)現(xiàn)Kubernetes集群 聯(lián)邦就ok 了，一定要從平臺(tái)的層次考慮，平臺(tái)設(shè)計(jì)一定要高于 ku

5、berneteso很多人可能僅僅是從開發(fā)人員的角度來(lái)考慮如何使用容器云，也就把 容器云平臺(tái)等同于kuberneteso如果是這樣，直接使用kubernetes 就好，沒必要再畫蛇添足封裝一層。我們定義的容器云平臺(tái)是基于容 器管理的輕量化PaaS平臺(tái)，所以僅僅kubernetes是不夠的。同時(shí) 也從頂層設(shè)計(jì)來(lái)考慮容器云平臺(tái)、云管平臺(tái)、基礎(chǔ)設(shè)施資源管理、 DevOps平臺(tái)、服務(wù)治理、中臺(tái)、API網(wǎng)關(guān)和OpenAPI管理等的建 設(shè)與融合。因此容器云平臺(tái)的資源規(guī)劃、擴(kuò)容和管理需要結(jié)合相關(guān)的 系統(tǒng)和平臺(tái)的整合與融合。三、需求預(yù)測(cè)及容規(guī)劃租戶的資源需求通常是基于租戶的應(yīng)用部署要求來(lái)確定的。為租戶分 配資源

6、通常也是按照最大的請(qǐng)求量來(lái)考慮的。某一階段內(nèi)所有租戶的 需求總和基本上反映了容器云平臺(tái)的資源需求量，同時(shí)可以考慮再預(yù) 留部分資源以應(yīng)對(duì)意外情況（或者實(shí)現(xiàn)按比例自動(dòng)擴(kuò)展等能力），就 可以得出并準(zhǔn)備這段時(shí)間內(nèi)的資源容量。通過評(píng)估應(yīng)用服務(wù)和部署每 個(gè)實(shí)例的CPU / Memory資源分配，可以大致知道所需的計(jì)算資源， 評(píng)估服務(wù)持久化數(shù)據(jù)存儲(chǔ)量確認(rèn)持久化存儲(chǔ)資源需求，評(píng)估網(wǎng)絡(luò)部署 需求、實(shí)例數(shù)、訪問需求等確認(rèn)網(wǎng)絡(luò)資源需求等。（一）計(jì)算資源計(jì)算資源可能來(lái)自于多個(gè)集群甚至是多個(gè)云平臺(tái)。基礎(chǔ)設(shè)施資源由云 管來(lái)提供，容器云平臺(tái)只考慮使用資源。不過需要實(shí)現(xiàn)資源的自動(dòng)擴(kuò) 容能力，這需要和云管集成。在設(shè)計(jì)實(shí)現(xiàn)時(shí)需要

7、提前規(guī)劃考慮。有一個(gè)問題可能需要注意，就是平臺(tái)的組件和kubernetes組件占用 的資源。如果平臺(tái)設(shè)計(jì)的不好，可能平臺(tái)組件和kubernetes組件會(huì) 占用很多資源，造成浪費(fèi)。很多人追求微服務(wù)，把服務(wù)分拆成很多小 服務(wù)。在容器云平臺(tái)，如果每個(gè)服務(wù)都部署成一個(gè)容器，就需要維護(hù) 很多這樣的容器，會(huì)造成大量的資源浪費(fèi)。所以平臺(tái)組件服務(wù)的設(shè)計(jì) 和整合會(huì)是很關(guān)鍵的一個(gè)事項(xiàng)。另外，容器基礎(chǔ)鏡像的優(yōu)化也非常重要。比如運(yùn)行java微服務(wù)，是 用jdk還是用jre鏡像，是用tomcat或別的應(yīng)用服務(wù)器鏡像，鏡像 大小不同，所耗費(fèi)的資源就不一樣。這樣的容器部署的量多了，就會(huì) 帶來(lái)比較大的不同。（二）持久化存儲(chǔ)不

8、論私有化或者公有云，容器云平臺(tái)持久化存儲(chǔ)是不可缺少的。對(duì)于 私有容器云，如果沒有特殊的要求，通常使用NFS就可以了。在我 們的實(shí)踐過程中，一個(gè)重要的需求就是持久化存儲(chǔ)的動(dòng)態(tài)分配。通常， 租戶在首次申請(qǐng)資源時(shí)，會(huì)評(píng)估資源需求，也包括持久化存儲(chǔ)需求。 租戶分配了一定的存儲(chǔ)空間，除了靜態(tài)創(chuàng)建持久化存儲(chǔ)卷之外，某些 容器也會(huì)動(dòng)態(tài)被創(chuàng)建并且需要?jiǎng)討B(tài)分配持久化存儲(chǔ)卷。不過這倒不存 在什么問題，用 kubernetes 的 storageclass、PV、PVC 和 useraccout, serviceaccount等對(duì)象來(lái)實(shí)現(xiàn)存儲(chǔ)和租戶的訪問控制 能力。（三）網(wǎng)絡(luò)資源容器云調(diào)研選型更多的是考慮選擇什么網(wǎng)

9、絡(luò)模型，卻比較少提及網(wǎng)絡(luò) 資源的規(guī)劃和管理。由于選擇不同的網(wǎng)絡(luò)模型，后期運(yùn)維和管理可能 會(huì)不一樣。比如用underlay網(wǎng)絡(luò)，就需要提前規(guī)劃分配網(wǎng)段及IP地 址范圍，提前規(guī)劃業(yè)務(wù)p od網(wǎng)段以及網(wǎng)絡(luò)地址類型（日類或C類地 址）等，作為容器云平臺(tái)專用網(wǎng)段，不要和其它業(yè)務(wù)混用；如果用 overlay網(wǎng)絡(luò)，則不需要考慮規(guī)劃業(yè)務(wù)網(wǎng)段。如果使用underlay兩層網(wǎng)絡(luò)，則需要提前規(guī)劃獨(dú)立的業(yè)務(wù)網(wǎng)段。同 時(shí)需要考慮部署的容器量，確定選擇網(wǎng)絡(luò)地址類型。不同類型的網(wǎng)絡(luò) 地址可用IP數(shù)是不一樣的，我們通常使用的C類地址一個(gè)網(wǎng)段只有 250來(lái)個(gè)可用地址。所以要提前規(guī)劃管理網(wǎng)段（也就是節(jié)點(diǎn)所在的網(wǎng) 段）和業(yè)務(wù)網(wǎng)段（

10、業(yè)務(wù)服務(wù)容器實(shí)例所使用的IP網(wǎng)段），并確定網(wǎng) 絡(luò)地址類型。為了便于管理和維護(hù)，這些網(wǎng)段和IP最好是規(guī)劃預(yù)留 給容器云平臺(tái)獨(dú)立使用，不要再分配給其他業(yè)務(wù)或應(yīng)用系統(tǒng)使用。如 果使用overlay三層網(wǎng)絡(luò)，則容器網(wǎng)絡(luò)是虛擬的。相對(duì)來(lái)說所需要規(guī) 劃的網(wǎng)段和IP會(huì)少些，但最好對(duì)虛擬網(wǎng)絡(luò)也進(jìn)行統(tǒng)一規(guī)劃，選擇合 適的虛擬網(wǎng)段和虛擬IP地址范圍。不同的網(wǎng)絡(luò)類型各有優(yōu)缺點(diǎn)，在企業(yè)級(jí)容器云平臺(tái)場(chǎng)景下，不同的集 群可能需要部署不同的網(wǎng)絡(luò)類型，以支持不同業(yè)務(wù)場(chǎng)景需求。比如一 個(gè)集群使用underlay網(wǎng)絡(luò)，另外一個(gè)集群可能使用overlay網(wǎng)絡(luò)。使用underlay網(wǎng)絡(luò)的容器是全網(wǎng)可達(dá)的，對(duì)于需要通過固定IP訪問 或

11、者容器的維護(hù)則相對(duì)容易些。在容器云平臺(tái)實(shí)踐過程中，容器的彈性伸縮是一個(gè)重要的能力。但由 于廠商彈性伸縮設(shè)計(jì)的不合理，也導(dǎo)致彈性伸縮功能配置和使用復(fù)雜 化，帶來(lái)了很多額外的管理工作。主要表現(xiàn)在namespaces資源限 額，租戶擴(kuò)容限制等方面。（一）namespace資源限額我們知道kubernetes的namespaces可以設(shè)置限額，但不是必須 設(shè)置限額。但是廠商在實(shí)現(xiàn)容器平臺(tái)的時(shí)候，以namespaces對(duì)應(yīng) 租戶下應(yīng)用，強(qiáng)制必須設(shè)置namespaces資源限額，也就是應(yīng)用的 資源限額。這就導(dǎo)致到了應(yīng)用下的服務(wù)難以按需實(shí)現(xiàn)自動(dòng)彈性擴(kuò)展。 因?yàn)榉峙涞馁Y源可能是不夠的，經(jīng)常導(dǎo)致擴(kuò)容的服務(wù)實(shí)例無(wú)

12、法啟動(dòng)， 不得不去修改namespaces限額。由于很多租戶下操作人員不是很 熟悉，所以也就導(dǎo)致了很多額外的解釋和問題處理事情，給平臺(tái)管理 和運(yùn)維人員帶來(lái)了眾多不應(yīng)該有的額外工作量。（二）租戶自動(dòng)擴(kuò)容與限制 在Kubernetes中沒有租戶的概念，因此無(wú)法用kubernetes的特性 來(lái)實(shí)現(xiàn)租戶的功能，這就需要在容器云平臺(tái)來(lái)實(shí)現(xiàn)。這也是我們一直 強(qiáng)調(diào)容器云平臺(tái)一定要有自己的平臺(tái)層的原因，不能只是簡(jiǎn)單封裝 kubernetes就是冒充容器云平臺(tái)了。對(duì)Kubernetes來(lái)說，租戶可以是一個(gè)邏輯概念。其是Kubernetes 一些對(duì)象的集合，當(dāng)然也包括kubernetes之外的對(duì)象。比如說我們 定

13、義的資源分區(qū)”，配置中心、日志中心等，這些共同來(lái)服務(wù)于租 戶。所以一個(gè)kubernetes是遠(yuǎn)遠(yuǎn)不夠的。那么如果租戶資源不足時(shí)，如何實(shí)現(xiàn)自動(dòng)擴(kuò)容？我們?cè)紤]過租戶自 動(dòng)擴(kuò)容申請(qǐng)審批流程，和云管平臺(tái)來(lái)集成實(shí)現(xiàn)。但是從我考慮的角度 來(lái)說，這依然帶來(lái)了很多的維護(hù)工作量。和云管平臺(tái)集成實(shí)現(xiàn)自動(dòng)彈 性資源擴(kuò)容是正確的，不過要盡量實(shí)現(xiàn)自動(dòng)化，減少人為的介入和干 預(yù)。這里有兩層的資源管理。一層是容器云平臺(tái)層資源，一層是云管平臺(tái) 資源。容器云平臺(tái)資源是基于云管資源的，這也是容器云或者容器化 PaaS和云管平臺(tái)的合理職責(zé)范圍劃分，不要混在一起使問題復(fù)雜化。 租戶的資源擴(kuò)容是由容器云平臺(tái)來(lái)分配的。容器云平臺(tái)資源不足時(shí)則 由云管平臺(tái)自動(dòng)分配。在多集群環(huán)境下，租戶可能擁有多個(gè)集群的資源，每個(gè)集群的資源都 可以基于云管來(lái)進(jìn)行擴(kuò)容。所有這些能力都需要容器云平臺(tái)層來(lái)實(shí) 現(xiàn)。（三）平臺(tái)擴(kuò)容方式 可能有個(gè)細(xì)節(jié)是云管往往是虛擬化的，資源管理相對(duì)容易些，所以用 云管來(lái)支撐容器云平臺(tái)的彈性資源伸縮相對(duì)容易實(shí)現(xiàn)，可以快速創(chuàng)建 虛擬機(jī)，增加節(jié)點(diǎn)，擴(kuò)展資源等。但另外一種情況是容器云平臺(tái)可以 直接基于物理服務(wù)器來(lái)部署容器，每臺(tái)物理服務(wù)器是一個(gè)節(jié)點(diǎn)。要擴(kuò) 展資源可能就需要增加物理務(wù)器節(jié)點(diǎn)。節(jié)點(diǎn)加入容器云平臺(tái)容易，但 物理服務(wù)器的準(zhǔn)備通常需要時(shí)間，這就需要備份一些機(jī)器用于彈性擴(kuò) 容。這些機(jī)器可以由云管平臺(tái)來(lái)維護(hù)。所以理想的情況可