建站
咨詢
售后
建站咨詢
新聞中心
Kubernetes是一個容器集群管理平臺，Kubernetes需要統(tǒng)計整體平臺的資源使用情況，合理地將資源分配給容器使用，并且要保證容器生命周期內有足夠的資源來保證其運行。 同時，如果資源發(fā)放是獨占的，即資源已發(fā)放給了個容器，同樣的資源不會發(fā)放給另外一個容器，對于空閑的容器來說占用著沒有使用的資源比如CPU是非常浪費的，Kubernetes需要考慮如何在優(yōu)先度和公平性的前提下提高資源的利用率。為了實現(xiàn)資源被有效調度和分配同時提高資源的利用率，Kubernetes采用Request和Limit兩種限制類型來對資源進行分配。
創(chuàng)新互聯(lián)公司是一家專注于成都網(wǎng)站設計、網(wǎng)站制作與策劃設計,大興安嶺網(wǎng)站建設哪家好?創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設10年,網(wǎng)設計領域的專業(yè)建站公司;建站業(yè)務涵蓋:大興安嶺等地區(qū)。大興安嶺做網(wǎng)站價格咨詢:13518219792
一、kubenerters中Request和Limit限制方式說明
Request: 容器使用的最小資源需求，作為容器調度時資源分配的判斷依賴。只有當節(jié)點上可分配資源量>=容器資源請求數(shù)時才允許將容器調度到該節(jié)點。但Request參數(shù)不限制容器的***可使用資源。
Limit: 容器能使用資源的資源的***值，設置為0表示使用資源無上限。
Request能夠保證Pod有足夠的資源來運行，而Limit則是防止某個Pod***制地使用資源，導致其他Pod崩潰。兩者之間必須滿足關系: 0<=Request<=Limit<=Infinity (如果Limit為0表示不對資源進行限制，這時可以小于Request)
在騰訊云容器服務(CCS)中，可以在創(chuàng)建服務，在容器編輯欄中點擊顯示高級設置，在高級設置中進行CPU和Memory的Request和Limit設置。目前CPU支持設置Request和Limit，用戶可以根據(jù)業(yè)務的特點動態(tài)的調整Request和Limit的比例關系。Memory目前只支持設置Request，Limit必須強制等于Request，這樣確保容器不會因為內存的使用量超過了Request但沒有超過Limit的情況下被意外的Kill掉。
二、kubenerters中Request和Limit使用示例
一個簡單的示例說明Request和Limit的作用，測試集群包括一個4U4G的節(jié)點。已經(jīng)部署的兩個Pod(1,2)，每個Pod的資源設置為(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 2U, 1G,1G).
節(jié)點上CPU和內存的資源使用情況如下圖所示：
已經(jīng)分配的CPU資源為：1U(分配Pod1)+1U(分配Pod2)=2U，剩余可以分配的CPU資源為2U
已經(jīng)分配的內存資源為：1G(分配Pod1)+1G(分配Pod2)=2G，剩余可以分配的內存資源為2G
所以該節(jié)點可以再部署一個(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，實現(xiàn)了2倍數(shù)量的Pod的部署，提高了資源的使用效率。
另外一個復雜一點的例子來進一步說明Request和Limit的作用，主要說明Request和Limit都為0的Pod對提高資源使用率的作用。測試集群仍然包含有一個4U4G的Pod。集群中已經(jīng)部署了四個Pod(1~4)，每個Pod的資源設置為(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 2U, 512M,512M)。
此時節(jié)點上CPU和內存的資源使用情況如下圖所示：
此時按照Request的需求，已經(jīng)沒有可以供分配的CPU資源。但由于Pod1~4業(yè)務負載比較低，造成節(jié)點上CPU使用率較低，造成了資源的浪費。這的時候可以通過將Request設置為0來實現(xiàn)對資源使用率的進一步提高。在此節(jié)點上部署4個資源限制為(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (0U, 0U, 512M,512M)。資源的使用情況如下圖所示：
Pod(5~8)能夠在Pod(1~4)空閑時，使用節(jié)點上剩余的CPU資源，從而進一步提高資源的使用率。
三、kubenerters中資源的搶占
Kubernetes中資源通過Request和Limit的設置，能夠實現(xiàn)容器對資源的更高效的使用。在如果多個容器同時對資源進行充分利用，資源使用盡量的接近Limit。這個時候Node節(jié)點上的資源總量要小于所有Pod中Limit的總會，就會發(fā)生資源搶占。
對于資源搶占的情況，Kubernetes根據(jù)資源能不能進行伸縮進行分類，分為可壓縮資源和不可以壓縮資源。CPU資源--是現(xiàn)在支持的一種可壓縮資源。內存資源和磁盤資源為現(xiàn)在支持的不可壓縮資源。
可壓縮資源的搶占策略---按照Requst的比值進行分配
例如在示例一種，假設在部署了Pod(1,2)的基礎上，又部署了資源限制和Pod1相同的兩個容器Pod(3,4)。這個時候，節(jié)點上的資源模型為。
假設四個Pod同時負載變高，CPU使用量超過1U，這個時候每個Pod將會按照各自的Request設置按比例分占CPU調度的時間片。在示例中，由于4個Pod設置的Request都為1U，發(fā)生資源搶占時，每個Pod分到的CPU時間片為1U/(1U×4)，實際占用的CPU核數(shù)為1U。在搶占發(fā)生時，Limit的值對CPU時間片的分配為影響，在本例中如果條件容器Limit值的設置，搶占情況下CPU分配的比例保持不變。
不可壓縮資源的搶占策略---按照優(yōu)先級的不同，進行Pod的驅逐
對于不可壓縮資源，如果發(fā)生資源搶占，則會按照優(yōu)先級的高低進行Pod的驅逐。驅逐的策略為： 優(yōu)先驅逐Request=Limit=0的Pod，其次驅逐0 由于對于不可壓縮資源，發(fā)生搶占的情況會出Pod被意外Kill掉的情況，所以建議對于不可以壓縮資源(Memory，Disk)的設置成0 針對內存搶占，本文進行了一次小的測試，示例中依次部署了Pod(1~3)單個Pod。節(jié)點中資源的示例圖為： 步驟1: 部署Pod1，資源參數(shù)為(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (2U, 2U, 2G,2G)，此時Pod1中進程使用1.9G內存，Pod1運行依然正常。 步驟2: 部署Pod2，資源參數(shù)為(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 1U, 1G,2G)，此時Pod2中進程使用0.9G內存，程序運行正常。超過1G，小于2G時程序運行正常，但超過2G程序異常。 步驟3: 部署Pod3，資源參數(shù)為(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 1U, 0G,0)。此時保持Pod1中進程使用內存為1.9G，Pod2中內存使用為0.9G，pod3搶占內存，搶占內存大小為2G。這時，Pod3***會出現(xiàn)因內存不足異常的情況。同時Pod2有時也會出現(xiàn)內存不足異常的情況。但Pod1一直能夠正常運行 步驟4：修改Pod2的參數(shù)為(CPU Requst,CPU Limit,Memory Requst, Memory Limit)= (1U, 1U, 1G,1G)，仍然保持步驟3中資源的使用量。這時Pod3仍然***出現(xiàn)內存不足而異常的情況，但Pod1和Pod2一直運行正常。
網(wǎng)頁題目：老司機和你深聊Kubenertes資源分配之Request和Limit解析
URL標題：http://m.5511xx.com/article/ccccooj.html
