Kubernetes是壹個容器集群管理平臺，Kubernetes需要統計整體平臺的資源使用情況，合理地將資源分配給容器使用，並且要保證容器生命周期內有足夠的資源來保證其運行。 同時，如果資源發放是獨占的，即資源已發放給了個容器，同樣的資源不會發放給另外壹個容器，對於空閑的容器來說占用著沒有使用的資源比如CPU是非常浪費的，Kubernetes需要考慮如何在優先度和公平性的前提下提高資源的利用率。為了實現資源被有效調度和分配同時提高資源的利用率，Kubernetes采用request和limit兩種限制類型來對資源進行分配。
在中臺這邊的實踐中，多次遇到各種場景的容器資源限制等問題。基於此，特整理相關的知識點，供大家參閱。
request 容器使用的最小資源需求，創建容器的時候，是最小的資源要求。 只有當節點上可分配資源量>=容器資源請求數時才允許將容器調度到該節點。
也就是說，創建容器時候，分配資源是按照 request 指定的值進行獨占的，容器至少要保留request指定的資源。
limit 表明容器能使用資源的最大值，設置為0表示使用資源無上限。
request 能夠保證Pod有足夠的資源來運行，而 limit 則是防止某個Pod無限制地使用資源，導致其他Pod崩潰。
兩者之間必須滿足關系:
通過壹個示例簡述request和limit參數的使用場景。
假設PaaS的壹個節點有 4U4G 可用資源。已經部署2個pod，記為pod1, pod2。每個pod的資源設置為
節點上CPU和內存的資源分配情況如下圖：
[圖片上傳失敗...(image-935055-1555552418778)]
已經分配的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的部署，提高了資源的使用效率。
依然假設PaaS的壹個節點有 4U4G 可用資源，節點上部署了4個pod，記為pod1~4。每個Pod的資源設置為（CPU Requst,CPU limit,Memory Requst, Memory limit）= (1U, 2U, 512M,512M)。資源分配情況如下圖：
[圖片上傳失敗...(image-84aeaf-1555552418778)]
按照request的要求，那麽已經沒有可以分配的CPU資源了。但是，由於Pod1~4業務負載比較低，造成了CPU的利用率較低，造成資源浪費。這個時候可以通過將request的值設置為0，實現對資源的進壹步利用。
在此節點上部署4個pod5~8， 資源限制為（CPU Requst,CPU limit,Memory Requst, Memory limit）= (0U, 0U, 512M,512M)。資源的使用情況如下圖所示：
[圖片上傳失敗...(image-78aeae-1555552418778)]
Pod5~8 能夠在Pod(1~4)空閑時，使用節點上剩余的CPU資源，從而進壹步提高資源的使用率。
Kubernetes中資源通過 request 和 limit 的設置，能夠實現容器對資源的更高效的使用。在如果多個容器同時對資源進行充分利用，資源使用盡量的接近limit。 Node節點上的資源總量要小於所有Pod中limit的總和，就會發生資源搶占。
對於資源搶占的情況，Kubernetes根據資源能不能進行伸縮進行分類，分為可壓縮資源和不可以壓縮資源。
假設有pod1~4 分別占用（CPU Requst,CPU limit,Memory Requst, Memory limit）= (1U, 2U, 1G,1G)。當四個pod的負載都很高，CPU使用都超過1U的情況下，這個時候每個pod將按照request設置的CPU比例進行時間片調度。由於4個Pod設置的request都為1U，發生資源搶占時，每個Pod分到的CPU時間片為1U/(1U)*4，實際占用的CPU核數為1U。
對於不可壓縮資源，如果發生資源搶占，則會按照優先級的高低進行Pod的驅逐。驅逐的策略為： 優先驅逐request=limit=0的Pod，其次驅逐 0<request<limit<Infinity (limit為0的情況也包括在內)。 0<request==limit 的Pod的會被保留，除非出現刪除其他Pod後，節點上剩余資源仍然沒有達到Kubernetes需要的剩余資源的需求。
由於對於不可壓縮資源，發生搶占的情況會出Pod被意外Kill掉的情況，所以建議對於不可以壓縮資源(Memory，Disk)的設置成 0<request==limit 。
blogs.com/sparkdev/p/8032330.html
blogs.com/sparkdev/p/8052522.html
/developer/article/1004976