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

工欲善其事，必先利其器。要做好容量的規(guī)劃和管理，就必須對容器云平臺的資源分配情況和資源使用情況比較了解，并了解和理解用戶的需求和關(guān)注點等，提升用戶體驗和滿意度。

一、 從用戶體驗入手

如何讓租戶用戶更好的了解和理解自己的資源使用情況？分配量、使用量、可用量等該怎么展示？不同的對象該面向哪些角色和人員?等等都需要認(rèn)真的考慮和規(guī)劃。

從管理員視角，我們需要知道每個租戶分配了多少資源、分出去了多少資源、使用了多少資源、可用的資源等。在私有云環(huán)境，我們不僅要關(guān)心租戶用多少資源，還要關(guān)心資源的使用效率。不是說資源隨便分配隨便用，好鋼用在刀刃上，因此，雖然私有云環(huán)境不進行計費，但要關(guān)心資源的使用效率。同時在用戶界面上要簡潔、一目了然。

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

總的來說，從用戶體驗角度，容器云平臺要盡可能提供完善的輔助能力，幫助用戶提高資源分配和使用效率。

二、 容器云平臺資源管理

我們討論過多集群的設(shè)計和管理及適用場景。在初始需求量不是很大時不適合搭建多個集群，當(dāng)然需要根據(jù)業(yè)務(wù)的要求來確定，比如需要多集群備份，就需要搭建至少兩個集群實現(xiàn)關(guān)鍵業(yè)務(wù)的備份部署。

從容器云平臺角度，一定要有全局的頂層的平臺資源視角。平臺的資源總量、使用量、分配量、可用量等，然后才是每個集群、每個分區(qū)、每個租戶甚至每個節(jié)點的資源總量、分配量和使用量等。在實現(xiàn)容器云平臺多集群不能只考慮kubernetes，不是實現(xiàn)Kubernetes集群聯(lián)邦就ok了，一定要從平臺的層次考慮，平臺設(shè)計一定要高于kubernetes。

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

三、 需求預(yù)測及容量規(guī)劃

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

（一） 計算資源

計算資源可能來自于多個集群甚至是多個云平臺?；A(chǔ)設(shè)施資源由云管來提供，容器云平臺只考慮使用資源。不過需要實現(xiàn)資源的自動擴容能力，這需要和云管集成。在設(shè)計實現(xiàn)時需要提前規(guī)劃考慮。

有一個問題可能需要注意，就是平臺的組件和kubernetes組件占用的資源。如果平臺設(shè)計的不好，可能平臺組件和kubernetes組件會占用很多資源，造成浪費。很多人追求微服務(wù)，把服務(wù)分拆成很多小服務(wù)。在容器云平臺，如果每個服務(wù)都部署成一個容器，就需要維護很多這樣的容器，會造成大量的資源浪費。所以平臺組件服務(wù)的設(shè)計和整合會是很關(guān)鍵的一個事項。

另外，容器基礎(chǔ)鏡像的優(yōu)化也非常重要。比如運行java微服務(wù)，是用jdk還是用jre鏡像，是用tomcat或別的應(yīng)用服務(wù)器鏡像，鏡像大小不同，所耗費的資源就不一樣。這樣的容器部署的量多了，就會帶來比較大的不同。

（二） 持久化存儲

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

（三） 網(wǎng)絡(luò)資源

容器云調(diào)研選型更多的是考慮選擇什么網(wǎng)絡(luò)模型，卻比較少提及網(wǎng)絡(luò)資源的規(guī)劃和管理。由于選擇不同的網(wǎng)絡(luò)模型，后期運維和管理可能會不一樣。比如用underlay網(wǎng)絡(luò)，就需要提前規(guī)劃分配網(wǎng)段及IP地址范圍，提前規(guī)劃業(yè)務(wù)p od 網(wǎng)段以及網(wǎng)絡(luò)地址類型（B類或C類地址）等，作為容器云平臺專用網(wǎng)段，不要和其它業(yè)務(wù)混用；如果用overlay網(wǎng)絡(luò)，則不需要考慮規(guī)劃業(yè)務(wù)網(wǎng)段。

如果使用underlay兩層網(wǎng)絡(luò)，則需要提前規(guī)劃獨立的業(yè)務(wù)網(wǎng)段。同時需要考慮部署的容器量，確定選擇網(wǎng)絡(luò)地址類型。不同類型的網(wǎng)絡(luò)地址可用IP數(shù)是不一樣的，我們通常使用的C類地址一個網(wǎng)段只有250來個可用地址。所以要提前規(guī)劃管理網(wǎng)段（也就是節(jié)點所在的網(wǎng)段）和業(yè)務(wù)網(wǎng)段（業(yè)務(wù)服務(wù)容器實例所使用的IP網(wǎng)段），并確定網(wǎng)絡(luò)地址類型。為了便于管理和維護，這些網(wǎng)段和IP最好是規(guī)劃預(yù)留給容器云平臺獨立使用，不要再分配給其他業(yè)務(wù)或應(yīng)用系統(tǒng)使用。如果使用overlay三層網(wǎng)絡(luò)，則容器網(wǎng)絡(luò)是虛擬的。相對來說所需要規(guī)劃的網(wǎng)段和IP會少些，但最好對虛擬網(wǎng)絡(luò)也進行統(tǒng)一規(guī)劃，選擇合適的虛擬網(wǎng)段和虛擬IP地址范圍。

不同的網(wǎng)絡(luò)類型各有優(yōu)缺點，在企業(yè)級容器云平臺場景下，不同的集群可能需要部署不同的網(wǎng)絡(luò)類型，以支持不同業(yè)務(wù)場景需求。比如一個集群使用underlay網(wǎng)絡(luò)，另外一個集群可能使用overlay網(wǎng)絡(luò)。使用underlay網(wǎng)絡(luò)的容器是全網(wǎng)可達的，對于需要通過固定IP訪問或者容器的維護則相對容易些。

四、 彈性擴容

在容器云平臺實踐過程中，容器的彈性伸縮是一個重要的能力。但由于廠商彈性伸縮設(shè)計的不合理，也導(dǎo)致彈性伸縮功能配置和使用復(fù)雜化，帶來了很多額外的管理工作。主要表現(xiàn)在namespaces資源限額，租戶擴容限制等方面。

（一） namespace資源限額

我們知道kubernetes的namespaces可以設(shè)置限額，但不是必須設(shè)置限額。但是廠商在實現(xiàn)容器平臺的時候，以namespaces對應(yīng)租戶下應(yīng)用，強制必須設(shè)置 namespaces 資源限額，也就是應(yīng)用的資源限額。這就導(dǎo)致到了應(yīng)用下的服務(wù)難以按需實現(xiàn)自動彈性擴展。因為分配的資源可能是不夠的，經(jīng)常導(dǎo)致擴容的服務(wù)實例無法啟動，不得不去修改namespaces限額。由于很多租戶下操作人員不是很熟悉，所以也就導(dǎo)致了很多額外的解釋和問題處理事情，給平臺管理和運維人員帶來了眾多不應(yīng)該有的額外工作量。

（二） 租戶自動擴容與限制

在Kubernetes中沒有租戶的概念，因此無法用kubernetes的特性來實現(xiàn)租戶的功能，這就需要在容器云平臺來實現(xiàn)。這也是我們一直強調(diào)容器云平臺一定要有自己的平臺層的原因，不能只是簡單封裝kubernetes就是冒充容器云平臺了。

對Kubernetes來說，租戶可以是一個邏輯概念。其是Kubernetes一些對象的集合，當(dāng)然也包括kubernetes之外的對象。比如說我們定義的“資源分區(qū)”，配置中心、日志中心等，這些共同來服務(wù)于租戶。所以一個kubernetes是遠遠不夠的。

那么如果租戶資源不足時，如何實現(xiàn)自動擴容？我們曾考慮過租戶自動擴容申請審批流程，和云管平臺來集成實現(xiàn)。但是從我考慮的角度來說，這依然帶來了很多的維護工作量。和云管平臺集成實現(xiàn)自動彈性資源擴容是正確的，不過要盡量實現(xiàn)自動化，減少人為的介入和干預(yù)。

這里有兩層的資源管理。一層是容器云平臺層資源，一層是云管平臺資源。容器云平臺資源是基于云管資源的，這也是容器云或者容器化PaaS和云管平臺的合理職責(zé)范圍劃分，不要混在一起使問題復(fù)雜化。租戶的資源擴容是由容器云平臺來分配的。容器云平臺資源不足時則由云管平臺自動分配。

在多集群環(huán)境下，租戶可能擁有多個集群的資源，每個集群的資源都可以基于云管來進行擴容。所有這些能力都需要容器云平臺層來實現(xiàn)。

（三） 平臺擴容方式

可能有個細(xì)節(jié)是云管往往是虛擬化的，資源管理相對容易些，所以用云管來支撐容器云平臺的彈性資源伸縮相對容易實現(xiàn)，可以快速創(chuàng)建虛擬機，增加節(jié)點，擴展資源等。但另外一種情況是容器云平臺可以直接基于物理服務(wù)器來部署容器，每臺物理服務(wù)器是一個節(jié)點。要擴展資源可能就需要增加物理務(wù)器節(jié)點。節(jié)點加入容器云平臺容易，但物理服務(wù)器的準(zhǔn)備通常需要時間，這就需要備份一些機器用于彈性擴容。這些機器可以由云管平臺來維護。所以理想的情況可能是由云管管理虛擬化和物理服務(wù)器和其他云資源共同為容器云平臺提供資源支持。

（四） 自動化、無人化運行

前面我們提到彈性擴容最好實現(xiàn)自動化、無人化，盡量不需要人為介入。這樣才能提升效率。雖然說私有云平臺體量相對較小，但長期節(jié)省的時間精力也可以做更多其他有意義的事情。

容器云平臺資源使用管理和優(yōu)化是一個不斷完善的過程。隨著實踐和認(rèn)知的提升，需要逐步來改進和完善一些不合理的地方，從而提升客戶體驗，提高資源利用效率，同時也提高業(yè)務(wù)效率。