老司機和你深聊Kubenertes 資源分配之 Request 和 Limit 解析

關鍵字標籤： 騰訊雲， ，  ， 

說明：該文轉載自騰訊雲技術社群騰雲閣，已徵求作者本人同意。

Kubernetes是一個容器叢集管理平臺，Kubernetes需要統計整體平臺的資源使用情況，合理地將資源分配給容器使用，並且要保證容器生命週期內有足夠的資源來保證其執行。 同時，如果資源發放是獨佔的，即資源已發放給了個容器，同樣的資源不會發放給另外一個容器，對於空閒的容器來說佔用著沒有使用的資源比如CPU是非常浪費的，Kubernetes需要考慮如何在優先度和公平性的前提下提高資源的利用率。為了實現資源被有效排程和分配同時提高資源的利用率，騰訊雲容器服務工程師和大家來分享一下，Kubernetes如何採用Request和Limit兩種限制型別來對資源進行分配。

一、kubenerters中Request和Limit限制方式說明

Request: 容器使用的最小資源需求，作為容器排程時資源分配的判斷依賴。只有當節點上可分配資源量>=容器資源請求數時才允許將容器排程到該節點。但Request引數不限制容器的最大可使用資源。

Limit: 容器能使用資源的資源的最大值，設定為0表示使用資源無上限。

Request能夠保證Pod有足夠的資源來執行，而Limit則是防止某個Pod無限制地使用資源，導致其他Pod崩潰。兩者之間必須滿足關係: 0<=Request<=Limit<=Infinity (如果Limit為0表示不對資源進行限制，這時可以小於Request)

在騰訊雲容器服務(CCS)中，可以在建立服務，在容器編輯欄中點選顯示高階設定，在高階設定中進行CPU和Memory的Request和Limit設定。目前CPU支援設定Request和Limit，使用者可以根據業務的特點動態的調整Request和Limit的比例關係。Memory目前只支援設定Request，Limit必須強制等於Request，這樣確保容器不會因為記憶體的使用量超過了Request但沒有超過Limit的情況下被意外的Kill掉。

二、kubenerters中Request和Limit使用示例

一個簡單的示例說明Request和Limit的作用，測試叢集包括一個4U4G的節點。已經部署的兩個Pod(1,2)，每個Pod的資源設定為（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 2U, 1G,1G).
節點上CPU和記憶體的資源使用情況如下圖所示：

已經分配的CPU資源為：1U(分配Pod1)+1U(分配Pod2)=2U，剩餘可以分配的CPU資源為2U

已經分配的記憶體資源為：1G(分配Pod1)+1G(分配Pod2)=2G，剩餘可以分配的記憶體資源為2G

所以該節點可以再部署一個(CPU Requst, Memory Requst)=(2U,2G)的Pod部署，或者部署2個(CPU Requst, Memory Requst)=(1U,1G)的Pod部署

在資源限制方面，每個Pod1和Pod2使用資源的上限為(2U,1G)，即在資源空閒的情況下，Pod使用CPU的量最大能達到2U，使用記憶體的最大量為1G。從CPU資源的角度，對於資源使用上線為2U的Pod，透過設定Request為1U，實現了2倍數量的Pod的部署，提高了資源的使用效率。

另外一個複雜一點的例子來進一步說明Request和Limit的作用，主要說明Request和Limit都為0的Pod對提高資源使用率的作用。測試叢集仍然包含有一個4U4G的Pod。叢集中已經部署了四個Pod(1~4)，每個Pod的資源設定為（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 2U, 512M,512M)。

此時節點上CPU和記憶體的資源使用情況如下圖所示：

此時按照Request的需求，已經沒有可以供分配的CPU資源。但由於Pod1~4業務負載比較低，造成節點上CPU使用率較低，造成了資源的浪費。這的時候可以透過將Request設定為0來實現對資源使用率的進一步提高。在此節點上部署4個資源限制為（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (0U, 0U, 512M,512M)。資源的使用情況如下圖所示：

Pod(5~8)能夠在Pod(1~4)空閒時，使用節點上剩餘的CPU資源，從而進一步提高資源的使用率。

三、kubenerters中資源的搶佔

Kubernetes中資源透過Request和Limit的設定，能夠實現容器對資源的更高效的使用。在如果多個容器同時對資源進行充分利用，資源使用盡量的接近Limit。這個時候Node節點上的資源總量要小於所有Pod中Limit的總會，就會發生資源搶佔。

對於資源搶佔的情況，Kubernetes根據資源能不能進行伸縮排行分類，分為可壓縮資源和不可以壓縮資源。CPU資源--是現在支援的一種可壓縮資源。記憶體資源和磁碟資源為現在支援的不可壓縮資源。

可壓縮資源的搶佔策略---按照Requst的比值進行分配

例如在示例一種，假設在部署了Pod(1,2)的基礎上，又部署了資源限制和Pod1相同的兩個容器Pod(3,4)。這個時候，節點上的資源模型為。

假設四個Pod同時負載變高，CPU使用量超過1U，這個時候每個Pod將會按照各自的Request設定按比例分佔CPU排程的時間片。在示例中，由於4個Pod設定的Request都為1U，發生資源搶佔時，每個Pod分到的CPU時間片為1U/(1U×4)，實際佔用的CPU核數為1U。在搶佔發生時，Limit的值對CPU時間片的分配為影響，在本例中如果條件容器Limit值的設定，搶佔情況下CPU分配的比例保持不變。

不可壓縮資源的搶佔策略---按照優先順序的不同，進行Pod的驅逐

對於不可壓縮資源，如果發生資源搶佔，則會按照優先順序的高低進行Pod的驅逐。驅逐的策略為： 優先驅逐Request=Limit=0的Pod，其次驅逐0<Request<Limit<Infinity (Limit為0的情況也包括在內)。 0<Request==Limit的Pod的會被保留，除非出現刪除其他Pod後，節點上剩餘資源仍然沒有達到Kubernetes需要的剩餘資源的需求。

由於對於不可壓縮資源，發生搶佔的情況會出Pod被意外Kill掉的情況，所以建議對於不可以壓縮資源(Memory，Disk)的設定成0<Request==Limit。

針對記憶體搶佔，本文進行了一次小的測試，示例中依次部署了Pod(1~3)單個Pod。節點中資源的示例圖為：

步驟1: 部署Pod1，資源引數為（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (2U, 2U, 2G,2G)，此時Pod1中程式使用1.9G記憶體，Pod1執行依然正常。

步驟2: 部署Pod2，資源引數為（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 1U, 1G,2G)，此時Pod2中程式使用0.9G記憶體，程式執行正常。超過1G，小於2G時程式執行正常，但超過2G程式異常。

步驟3: 部署Pod3，資源引數為（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 1U, 0G,0)。此時保持Pod1中程式使用記憶體為1.9G，Pod2中記憶體使用為0.9G，pod3搶佔記憶體，搶佔記憶體大小為2G。這時，Pod3最先會出現因記憶體不足異常的情況。同時Pod2有時也會出現記憶體不足異常的情況。但Pod1一直能夠正常執行

步驟4：修改Pod2的引數為（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 1U, 1G,1G)，仍然保持步驟3中資源的使用量。這時Pod3仍然最先出現記憶體不足而異常的情況，但Pod1和Pod2一直執行正常。