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

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

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

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

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

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

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

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

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

9、絡(luò)模型，卻比較少提及網(wǎng)絡(luò) 資源的規(guī)劃和管理。由于選擇不同的網(wǎng)絡(luò)模型，后期運(yùn)維和管理可能 會不一樣。比如用underlay網(wǎng)絡(luò)，就需要提前規(guī)劃分配網(wǎng)段及IP地 址范圍，提前規(guī)劃業(yè)務(wù)p od網(wǎng)段以及網(wǎng)絡(luò)地址類型（日類或C類地 址）等，作為容器云平臺專用網(wǎng)段，不要和其它業(yè)務(wù)混用；如果用 overlay網(wǎng)絡(luò)，則不需要考慮規(guī)劃業(yè)務(wù)網(wǎng)段。如果使用underlay兩層網(wǎng)絡(luò)，則需要提前規(guī)劃獨(dú)立的業(yè)務(wù)網(wǎng)段。同 時需要考慮部署的容器量，確定選擇網(wǎng)絡(luò)地址類型。不同類型的網(wǎng)絡(luò) 地址可用IP數(shù)是不一樣的，我們通常使用的C類地址一個網(wǎng)段只有 250來個可用地址。所以要提前規(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ù)留 給容器云平臺獨(dú)立使用，不要再分配給其他業(yè)務(wù)或應(yīng)用系統(tǒng)使用。如 果使用overlay三層網(wǎng)絡(luò)，則容器網(wǎng)絡(luò)是虛擬的。相對來說所需要規(guī) 劃的網(wǎng)段和IP會少些，但最好對虛擬網(wǎng)絡(luò)也進(jìn)行統(tǒng)一規(guī)劃，選擇合 適的虛擬網(wǎng)段和虛擬IP地址范圍。不同的網(wǎng)絡(luò)類型各有優(yōu)缺點(diǎn)，在企業(yè)級容器云平臺場景下，不同的集 群可能需要部署不同的網(wǎng)絡(luò)類型，以支持不同業(yè)務(wù)場景需求。比如一 個集群使用underlay網(wǎng)絡(luò)，另外一個集群可能使用overlay網(wǎng)絡(luò)。使用underlay網(wǎng)絡(luò)的容器是全網(wǎng)可達(dá)的，對于需要通過固定IP訪問 或

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

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

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