Kubernetes服務部署中如何更好地設置Request與Limit

今天就跟大家聊聊有關Kubernetes服務部署中如何更好地設置 Request 與 Limit，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

企業(yè)建站必須是能夠以充分展現(xiàn)企業(yè)形象為主要目的，是企業(yè)文化與產(chǎn)品對外擴展宣傳的重要窗口，一個合格的網(wǎng)站不僅僅能為公司帶來巨大的互聯(lián)網(wǎng)上的收集和信息發(fā)布平臺，創(chuàng)新互聯(lián)建站面向各種領域：陽光房等網(wǎng)站設計、全網(wǎng)營銷推廣解決方案、網(wǎng)站設計等建站排名服務。

如何為容器配置 Request 與 Limit? 這是一個即常見又棘手的問題，這個根據(jù)服務類型，需求與場景的不同而不同，沒有固定的答案，這里結合生產(chǎn)經(jīng)驗總結了一些最佳實踐。

所有容器都應該設置 request

request 的值并不是指給容器實際分配的資源大小，它僅僅是給調(diào)度器看的，調(diào)度器會 "觀察" 每個節(jié)點可以用于分配的資源有多少，也知道每個節(jié)點已經(jīng)被分配了多少資源。被分配資源的大小就是節(jié)點上所有 Pod 中定義的容器 request 之和，它可以計算出節(jié)點剩余多少資源可以被分配(可分配資源減去已分配的 request 之和)。如果發(fā)現(xiàn)節(jié)點剩余可分配資源大小比當前要被調(diào)度的 Pod 的 reuqest 還小，那么就不會考慮調(diào)度到這個節(jié)點，反之，才可能調(diào)度。所以，如果不配置 request，那么調(diào)度器就不能知道節(jié)點大概被分配了多少資源出去，調(diào)度器得不到準確信息，也就無法做出合理的調(diào)度決策，很容易造成調(diào)度不合理，有些節(jié)點可能很閑，而有些節(jié)點可能很忙，甚至 NotReady。

所以，建議是給所有容器都設置 request，讓調(diào)度器感知節(jié)點有多少資源被分配了，以便做出合理的調(diào)度決策，讓集群節(jié)點的資源能夠被合理的分配使用，避免陷入資源分配不均導致一些意外發(fā)生。

老是忘記設置怎么辦

有時候我們會忘記給部分容器設置 request 與 limit，其實我們可以使用 LimitRange 來設置 namespace 的默認 request 與 limit 值，同時它也可以用來限制最小和最大的 request 與 limit。 示例:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
  namespace: test
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 500m
    defaultRequest:
      memory: 256Mi
      cpu: 100m
    type: Container

重要的線上應用改如何設置

節(jié)點資源不足時，會觸發(fā)自動驅(qū)逐，將一些低優(yōu)先級的 Pod 刪除掉以釋放資源讓節(jié)點自愈。沒有設置 request，limit 的 Pod 優(yōu)先級最低，容易被驅(qū)逐；request 不等于 limit 的其次； request 等于 limit 的 Pod 優(yōu)先級較高，不容易被驅(qū)逐。所以如果是重要的線上應用，不希望在節(jié)點故障時被驅(qū)逐導致線上業(yè)務受影響，就建議將 request 和 limit 設成一致。

怎樣設置才能提高資源利用率

如果給給你的應用設置較高的 request 值，而實際占用資源長期遠小于它的 request 值，導致節(jié)點整體的資源利用率較低。當然這對時延非常敏感的業(yè)務除外，因為敏感的業(yè)務本身不期望節(jié)點利用率過高，影響網(wǎng)絡包收發(fā)速度。所以對一些非核心，并且資源不長期占用的應用，可以適當減少 request 以提高資源利用率。

如果你的服務支持水平擴容，單副本的 request 值一般可以設置到不大于 1 核，CPU 密集型應用除外。比如 coreDNS，設置到 0.1 核就可以，即 100m。

盡量避免使用過大的 request 與 limit

如果你的服務使用單副本或者少量副本，給很大的 request 與 limit，讓它分配到足夠多的資源來支撐業(yè)務，那么某個副本故障對業(yè)務帶來的影響可能就比較大，并且由于 request 較大，當集群內(nèi)資源分配比較碎片化，如果這個 Pod 所在節(jié)點掛了，其它節(jié)點又沒有一個有足夠的剩余可分配資源能夠滿足這個 Pod 的 request 時，這個 Pod 就無法實現(xiàn)漂移，也就不能自愈，加重對業(yè)務的影響。

相反，建議盡量減小 request 與 limit，通過增加副本的方式來對你的服務支撐能力進行水平擴容，讓你的系統(tǒng)更加靈活可靠。

避免測試 namespace 消耗過多資源影響生產(chǎn)業(yè)務

若生產(chǎn)集群有用于測試的 namespace，如果不加以限制，可能導致集群負載過高，從而影響生產(chǎn)業(yè)務。可以使用 ResourceQuota 來限制測試 namespace 的 request 與 limit 的總大小。 示例:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: quota-test
  namespace: test
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

看完上述內(nèi)容，你們對Kubernetes服務部署中如何更好地設置 Request 與 Limit有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

分享名稱：Kubernetes服務部署中如何更好地設置Request與Limit
本文網(wǎng)址：http://bm7419.com/article16/igopgg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、標簽優(yōu)化、服務器托管、營銷型網(wǎng)站建設、網(wǎng)站設計、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)