Kubernetes是一個容器集群管理平臺碧浊，Kubernetes需要統(tǒng)計整體平臺的資源使用情況欧漱，合理地將資源分配給容器使用库继，并且要保證容器生命周期內(nèi)有足夠的資源來保證其運行退唠。 同時鹃锈，如果資源發(fā)放是獨占的，即資源已發(fā)放給了個容器瞧预，同樣的資源不會發(fā)放給另外一個容器屎债，對于空閑的容器來說占用著沒有使用的資源比如CPU是非常浪費的仅政，Kubernetes需要考慮如何在優(yōu)先度和公平性的前提下提高資源的利用率。為了實現(xiàn)資源被有效調(diào)度和分配同時提高資源的利用率盆驹，Kubernetes采用request和limit兩種限制類型來對資源進(jìn)行分配圆丹。

在中臺這邊的實踐中，多次遇到各種場景的容器資源限制等問題躯喇”璺猓基于此，特整理相關(guān)的知識點廉丽，供大家參閱倦微。

1 kuberneters中request和limit限制方式說明

request 容器使用的最小資源需求，創(chuàng)建容器的時候正压，是最小的資源要求欣福。只有當(dāng)節(jié)點上可分配資源量>=容器資源請求數(shù)時才允許將容器調(diào)度到該節(jié)點。

也就是說焦履，創(chuàng)建容器時候劣欢，分配資源是按照request指定的值進(jìn)行獨占的，容器至少要保留request指定的資源裁良。

request參數(shù)不限制容器的最大可使用資源凿将。

limit 表明容器能使用資源的最大值，設(shè)置為0表示使用資源無上限价脾。

2 request和limit的區(qū)別

request 能夠保證Pod有足夠的資源來運行牧抵，而limit 則是防止某個Pod無限制地使用資源，導(dǎo)致其他Pod崩潰侨把。

兩者之間必須滿足關(guān)系:

0<=request<=limit<=Infinity 

如果limit為0表示不對資源進(jìn)行限制犀变，這時可以小于request

3 request 和 limit的幾個使用場景

3.1 典型的資源分配示例

通過一個示例簡述request和limit參數(shù)的使用場景。

假設(shè)PaaS的一個節(jié)點有4U4G可用資源秋柄。已經(jīng)部署2個pod获枝，記為pod1, pod2。每個pod的資源設(shè)置為

（CPU Requst,CPU limit,Memory Requst, Memory limit）= (1U, 2U, 1G,1G).

節(jié)點上CPU和內(nèi)存的資源分配情況如下圖：
[圖片上傳失敗...(image-935055-1555552418778)]

已經(jīng)分配的CPU資源為：1U(分配Pod1)+1U(分配Pod2)=2U骇笔，剩余可以分配的CPU資源為2U

已經(jīng)分配的內(nèi)存資源為：1G(分配Pod1)+1G(分配Pod2)=2G省店，剩余可以分配的內(nèi)存資源為2G

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

在資源限制方面笨触，每個Pod1和Pod2使用資源的上限為(2U,1G)懦傍，即在資源空閑的情況下，Pod使用CPU的量最大能達(dá)到2U芦劣，使用內(nèi)存的最大量為1G粗俱。從CPU資源的角度，對于資源使用上線為2U的Pod虚吟，通過設(shè)置request為1U寸认，實現(xiàn)了2倍數(shù)量的Pod的部署签财，提高了資源的使用效率。

3.2 復(fù)雜場景

依然假設(shè)PaaS的一個節(jié)點有4U4G可用資源偏塞，節(jié)點上部署了4個pod唱蒸，記為pod1~4。每個Pod的資源設(shè)置為（CPU Requst,CPU limit,Memory Requst, Memory limit）= (1U, 2U, 512M,512M)烛愧。資源分配情況如下圖：

[圖片上傳失敗...(image-84aeaf-1555552418778)]

按照request的要求油宜，那么已經(jīng)沒有可以分配的CPU資源了掂碱。但是怜姿，由于Pod1~4業(yè)務(wù)負(fù)載比較低，造成了CPU的利用率較低疼燥，造成資源浪費沧卢。這個時候可以通過將request的值設(shè)置為0，實現(xiàn)對資源的進(jìn)一步利用醉者。

在此節(jié)點上部署4個pod5~8但狭， 資源限制為（CPU Requst,CPU limit,Memory Requst, Memory limit）= (0U, 0U, 512M,512M)。資源的使用情況如下圖所示：

[圖片上傳失敗...(image-78aeae-1555552418778)]

Pod5~8 能夠在Pod(1~4)空閑時撬即，使用節(jié)點上剩余的CPU資源立磁，從而進(jìn)一步提高資源的使用率。

4 kubenerters中資源的搶占

Kubernetes中資源通過request和limit的設(shè)置剥槐，能夠?qū)崿F(xiàn)容器對資源的更高效的使用唱歧。在如果多個容器同時對資源進(jìn)行充分利用，資源使用盡量的接近limit粒竖。 Node節(jié)點上的資源總量要小于所有Pod中l(wèi)imit的總和颅崩，就會發(fā)生資源搶占。

對于資源搶占的情況蕊苗，Kubernetes根據(jù)資源能不能進(jìn)行伸縮進(jìn)行分類沿后，分為可壓縮資源和不可以壓縮資源。

• CPU資源--是現(xiàn)在支持的一種可壓縮資源朽砰。
• 內(nèi)存資源和磁盤資源為現(xiàn)在支持的不可壓縮資源尖滚。

4.1 可壓縮資源的搶占策略---按照Requst的比值進(jìn)行分配

假設(shè)有pod1~4 分別占用（CPU Requst,CPU limit,Memory Requst, Memory limit）= (1U, 2U, 1G,1G)。當(dāng)四個pod的負(fù)載都很高瞧柔，CPU使用都超過1U的情況下熔掺，這個時候每個pod將按照request設(shè)置的CPU比例進(jìn)行時間片調(diào)度。由于4個Pod設(shè)置的request都為1U非剃，發(fā)生資源搶占時置逻，每個Pod分到的CPU時間片為1U/(1U)*4，實際占用的CPU核數(shù)為1U备绽。

這里涉及到docker關(guān)于CPU占用的策略券坞。CPU占用可以按照占用指定核或者占用時間片資源來區(qū)分鬓催。默認(rèn)情況下使用的是時間片。

4.2 不可壓縮資源的搶占策略---按照優(yōu)先級的不同恨锚，進(jìn)行Pod的驅(qū)逐

對于不可壓縮資源宇驾，如果發(fā)生資源搶占，則會按照優(yōu)先級的高低進(jìn)行Pod的驅(qū)逐猴伶。驅(qū)逐的策略為： 優(yōu)先驅(qū)逐request=limit=0的Pod课舍，其次驅(qū)逐0<request<limit<Infinity (limit為0的情況也包括在內(nèi))。 0<request==limit的Pod的會被保留他挎，除非出現(xiàn)刪除其他Pod后筝尾，節(jié)點上剩余資源仍然沒有達(dá)到Kubernetes需要的剩余資源的需求。

由于對于不可壓縮資源办桨，發(fā)生搶占的情況會出Pod被意外Kill掉的情況筹淫，所以建議對于不可以壓縮資源(Memory，Disk)的設(shè)置成0<request==limit呢撞。

參考資料

http://www.cnblogs.com/sparkdev/p/8032330.html
https://www.cnblogs.com/sparkdev/p/8052522.html
https://cloud.tencent.com/developer/article/1004976