Kubenertes資源分配之Request和Limit解析

收錄待用，修改轉載已取得騰訊雲受權

---

Kubernetes是一個容器集羣管理平臺，Kubernetes須要統計總體平臺的資源使用狀況，合理地將資源分配給容器使用，而且要保證容器生命週期內有足夠的資源來保證其運行。 同時，若是資源發放是獨佔的，即資源已發放給了個容器，一樣的資源不會發放給另一個容器，對於空閒的容器來講佔用着沒有使用的資源好比CPU是很是浪費的，Kubernetes須要考慮如何在優先度和公平性的前提下提升資源的利用率。爲了實現資源被有效調度和分配同時提升資源的利用率，Kubernetes採用Request和Limit兩種限制類型來對資源進行分配。

1、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掉。

2、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,2G)的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資源，從而進一步提升資源的使用率。

3、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一直運行正常。

更多關於不可壓縮資源搶佔時的資源回收策略，能夠參考：

https://www.kubernetes.org.cn/1150.html (Kubernetes 針對資源緊缺處理方式的配置)

---

原文連接：https://www.qcloud.com/community/article/905142