原文：https://cloud.tencent.com/developer/article/1004976
Kubernetes是一個容器集群管理平台，Kubernetes需要統計整體平台的資源使用情況，合理地將資源分配給容器使用，並且要保證容器生命周期內有足夠的資源來保證其運行。 同時，如果資源發放是獨占的，即資源已發放給了個容器，同樣的資源不會發放給另外一個容器，對於空閑的容器來說占用着沒有使用的資源比如CPU是非常浪費的，Kubernetes需要考慮如何在優先度和公平性的前提下提高資源的利用率。為了實現資源被有效調度和分配同時提高資源的利用率，Kubernetes采用Request和Limit兩種限制類型來對資源進行分配。
一、kuberneters中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一直運行正常。
更多關於不可壓縮資源搶占時的資源回收策略，可以參考：Kubernetes 針對資源緊缺處理方式的配置