云原生運維中，可能會經常遇到某個集群看起來明明有很多資源卻遭遇調度失敗的情況。私有云原生環境，資源總是有限的，提升資源利用率以降低成本始終是需要考慮的問題，減少資源碎片、優化調度配置是提升資源利用率的有效手段。

云原生運維實踐過程中，可能會經常遇到某個集群看起來明明有很多資源卻遭遇調度失敗問題。比如說，有個容器request 4C8G 的資源，整個集群剩余的資源可能有幾十C上百G，但容器調度卻失敗了。

什么原因呢?一個集群就是一個資源池，但這個資源池最終還由若干個獨立的節點(不管虛擬或物理節點)組成，每個節點都是有一定配置量的資源。所以具體到某個節點時，其資源是有限的，其剩余的資源不足以部署和運行容器服務時，這些剩余的資源就成了資源碎片。節點越多，資源碎片就越多，其累計的量就越大。所以雖然看起來集群有很多資源，卻無法成功調度某些容器(資源需求小的容器有可能調度成功，取決于資源碎片大小和容器對資源需求大小)。

這也產生了一個需求，是否可以動態進行資源碎片整理或優化?類似Windows 磁盤的資源碎片整理一樣，通過動態調整和遷移容器到合適的節點上，以更有效的使用基礎設施資源，提升資源利用率。

資源碎片產生原因

資源碎片是在某些環境中，所有節點或服務器中，每個節點或服務器所剩余的資源不足以部署或調度當前服務或不滿足當前服務的資源調度需求，但整體剩余資源總量看起來還很充裕，這些每個節點或服務器所剩余的不足以部署或調度服務的資源，就是資源碎片。

資源充足的情況下，不需要考慮資源碎片問題。但大量的資源空閑，本身就是極大的浪費，因此，通常會使資源使用率達到一定的要求。不過實際的環境中，各種場景需求和各種規格的節點資源配置，會導致大量的資源無法充分利用。特別對GPU資源的使用，如果不合理調度導致大量閑置，其本身的成本就非常高昂，也影響智能化應用的處理效率。因此，通過對資源碎片的關注和分析，是有效優化資源調度和提升資源利用率的前提。

資源碎片產生的原因包括不合理的節點資源配比、碎片化的資源隔離、不合理的服務資源配額、調度算法未能優化等。因此可以關注這幾個方面：

1、容器節點的資源配比

容器的重要特性是輕量化、無狀態，因此微服務化應用適合在容器中運行。不過，在實際的環境中，業務應用的資源需求規格各不相同，有的Pod 運行需要很少的資源，有的需要很多的資源，有的還需要GPU資源，比如一些模型服務等。而節點資源的配置通常是滿足通用需求的，私有化很少會像公有云服務一樣配置不同類型和特性的資源以滿足特定場景的需求。如果節點資源配比不合理，比如16C 16G 這樣一個虛擬節點資源配比，很可能只能運行一個大的Pod 實例( 4C 12G) ，或者調度了幾個實例(合計4C 8G)之后，看起來還有不少資源，卻無法再調度一個大的P od 實例(3C 10G)。如果一個集群中所有節點都是這樣的情況，那么在遇到部署一個大的實例時，就會出現調度失敗。因此，節點的資源配比是首先需要考慮的問題。

在具體實踐中，通用節點資CPU 和內存源配比大概在1:4-1:5 就好。每個節點不宜配置太低，32C 128G 或 64C 256G 的虛擬配置或96 C 512G的物理服務配置應該是比較合適的。另外，每個容器或容器中的微服務不宜太小，否則 Pod 數會很多，每個節點部署的容器理論上不超過110 個，小Pod 多，資源往往也無法充分利用，特別對于物理機節點，會很浪費。此外，也可能需要考慮不同配置規格的節點，類似不同大小、長短的箱子，方便打包(調度)不同的貨物(Pod)。

節點的磁盤空間配置同樣很重要。需要考慮日志量、加載鏡像文件、可運行的Pod 量等。CPU、內存大的節點，磁盤也需要更大。實際環境中，物理節點可配置2 -4T ssd 盤，虛擬節點800G-1.5T左右磁盤。如果磁盤空間不足，會導致Pod 頻繁被驅逐。

此外，在GPU資源管理中，需要實現以GPU卡、虛擬v GPU 為單位的資源隔離方式。GPU節點的GPU 卡數量、配置和其CPU 、內存配置也需要合理。CPU +GPU 異構計算架構是目前的主要方式，如果CPU 和內存配置不合理，也會影響GPU的利用效率。

2 、資源隔離

資源隔離有多種不同的實現方式，比如說租戶隔離、Namesapce隔離、資源分區(資源組)隔離、集群隔離等。理論上，資源池越大，資源碎片就相對會少，資源使用率相對比較高，不過理論上安全性會降低。隔離的越細，理論上安全性越高，但資源浪費往往就越嚴重。從云共享的角度考慮，資源不應該隔離，而可以從租戶端或應用層進行軟隔離。

租戶隔離是通過租戶賬戶體系實現的一種虛擬資源隔離方式，租戶有自己的獨立的系統空間，但底層資源可能是共享的。理論上，租戶不用關注自己的服務或應用部署或運行在哪里。不過云原生環境和虛擬化 IaaS 層環境隔離還是不一樣，IaaS環境可以通過虛擬機實現安全的隔離，而云原生環境的資源隔離更復雜些，安全性挑戰也更大。比如說，兩個租戶的服務可以運行在一張GPU卡上，但是租戶只能看到自己的服務的運行狀況，不能看到其他租戶的信息，資源的隔離、故障隔離、數據隔離和安全隔離要求就高很多，資源調度管理也復雜很多。如果資源隔離隔離過細，則會導致很多資源無法有效被調度和利用，從而造成浪費。

Namespace 是 K8s 的命名空間，是一種邏輯軟隔離方式。命令空間屬于K8s 集群，不能跨集群。如果要是實現跨集群管理Namespace ，就需要PaaS 平臺能力的擴展和抽象。在實際應用中，Namespace通常映射為租戶或應用，從而實現租戶層或應用層資源的隔離。分配給Namespace 的空間相當于預留空間，其他租戶或應用不能占用已分配的資源。因此Namespace的資源分配通常是根據需求動態調整的，不能一次分配大量的資源閑置。

資源分區是邏輯資源組，在K8s 通常是以節點為單位的資源分組方式。可以定義共享分區和獨享分區等，是一種可以實現從節點物理隔離資源的方式。通常盡可能不定義獨享分區，除非業務特別重要，否則可能會導致獨享分區的資源不好共享，利用效率就相對低。

多集群場景通常是多環境、災備、高可用等部署需求，以隔離不同的環境。由于集群資源比較多，因此集群往往會部署于不同的數據中心或網絡域。

資源碎片調度優化

云原生環境我們關注節點CPU 、內存、磁盤、GPU等的合理配比，以更高效的利用資源。不過合理的資源配比只是第一步，還需要實現動態的資源調度和優化。要實現動態調度和優化，資產資源梳理和調整、優化節點配置是前提，選擇指標實現動態監控是就緒準備，然后才能實現資源的動態優化調度。

1、資產資源梳理，查漏補缺

首先需要對云原生環境的資產和資源進行梳理，知道有什么資產、有多少資產，每項資產有多少資源。比如說，傳統x86 有幾個集群，多少節點，每個節點的CPU 、內存、磁盤、GPU算力、顯存等配置，信創x86 、信創ARM等的資產資源等。還需要知道節點的OS、版本、內核版本、節點型號、IP、主機名等信息，以及節點的系統配置如節點最大文件描述符配置、網絡端口范圍、最大連接數、進程數等。這些配置參數等是進行優化調度的基礎。

2、節點配置合理優化

有些節點配置可能不合理，比如利舊的機器配置是64C 64G，對于容器環境來說，內存配置就顯的低了。在云原生容器環境，雖然不同的業務對資源需求不一樣，但基于實際的資源需求情況看，CPU 和內存1:1的規格配置明顯就不是很合理。或者有些機器的磁盤非常小，或者磁盤分區劃分不合理，比如/var 分區只有20G ( 容器默認使用/ var/lib/docker 目錄 ) ，或根/分區只有50G，這些不合理的配置不但會使容器被驅逐而導致不穩定和業務錯誤，也無法有效利用資源，因此可能需要適當做些調整。

3、選擇指標、動態監控和計算

資產資源實現可見、可觀測，并且合理調整完節點配置是有效資源利用的前提。然后需要對資源的使用情況進行監控，需要實時、準確地知道資源的分配、使用和余量及資源使用特點等。比如說節點分配出去的CPU 、內存、GPU 、顯存，CPU /內存分配比、CPU 、GPU 、顯存實際使用、內存實際使用，DISK剩余空間、節點的TCP 連接數、進程數、Pod 數等等，這些都可以作為優化調度的指標。確定了指標，需要對這些指標進行采集并計算處理。指標數據采集時間間隔很重要，間隔短太頻繁會產生性能壓力等，間隔太長達不到優化調控的目的，不過還是要基于實際的環境來設定，比如5分鐘或者30 分鐘。在獲取指標數據時，盡可能采用可觀測思想，由源端主動發布，目標端監聽接收指標數據(這樣目標端可以是多個)。也可以使用已采集的數據，例如從prometheus 中獲取指標數據，進行二次計算。

這些獲取的指標數據需要保存，最好用內存數據庫在內存中維護資產資源的運行狀況，并對這些指標進行權重設置，動態地統計、排序等。排序是以節點為粒度的，因為pod 的調度是調度到節點上的。同時可能需要維護多個序列，比如按CPU余量節點排序、按內存余量排序、CPU/內存使用均衡比等，從而可以知道節點資源的使用情況。另外需要對節點上運行的服務的資源分配和使用情況進行計算分析，這可能需要至少一周或數周的運行數據，能夠比較獲得相對規律的統計數據，從而可以設置合適的資源配額，可以動態知曉節點上服務的資源使用和排序，從而在資源不足以調度新pod 時，可以選擇合適的pod進行熱遷移。

最后可能需要考慮是否啟用資源超分機制，如果啟用，超分機制如何實現等。超分是提升資源利用率的一種方式，不過也可能會帶來一些問題，所以需要謹慎使用。其實總的來說應用服務、資產資源的可觀測能力非常重要。

4、調度優化、動態調整

有了響應的指標實時運行數據，就可以動態掌握平臺資源的使用狀況，按需實現動態調整和優化。資源調度優化是一個并不輕松的工作，資源調度算法有很多種。K8s 提供了兩階段調度策略，但k8s 無法實現動態的資源調度調整，比如說，有一個大的pod 需要調度，但所有節點都不滿足這個pod 的資源需求，這就需要平臺能夠根據節點資源配置、資源使用、節點上的pod 等情況來調度(或熱遷移)某個pod到另外的節點以空出足夠的資源來調度這個大的pod，從而實現了資源碎片的整理，提升了資源的利用率。

在資源充足的情況下，資源的調度策略也可以設置為均衡調度策略，也是k8s 默認的調度策略。在可分配資源比較緊張時，可以優先采用節點緊湊調度策略，一個節點資源占滿后，再調度使用另外一個節點。這樣，可以比較好的避免過多的資源碎片。

不過實際的環境需求往往要復雜很多，比如說，應用服務的優先級問題，高優先級服務具備優先使用資源或高性能資源權限，那么低優先級的服務就需要被熱遷移或調度到其他資源上運行或peng ding 運行，所以資源的調度策略和算法可能需要根據實際運行狀況不斷改進和優化。實際生產中，總會遇到這樣那樣的問題，舉例說，節點的tcp 連接未關閉，連接數可能達到最大值了，出現超時、消息丟失等問題，需要不斷的總結和持續的改進，才能更好地利用資源，提升資源的利用率。

總結

云作為底座提供基礎設施服務，但私有云原生環境，資源總是有限的，提升資源利用率以降低成本始終是需要考慮的問題。減少資源碎片、優化調度配置是提升資源利用率的有效手段。雖然實際的環境要復雜很多，實現起來并不是很容易，不過逐步優化和提升，對云原生環境的資源利用可以提升到一個比較高的程度。