如何為容器配置 Request 與 Limit? 這是一個即常見又棘手的問題，這個根據服務型別，需求與場景的不同而不同，沒有固定的答案，這里結合生產經驗總結了一些最佳實踐，可以作為參考，
所有容器都應該設定 request
request 的值并不是指給容器實際分配的資源大小，它僅僅是給調度器看的，調度器會 "觀察" 每個節點可以用于分配的資源有多少，也知道每個節點已經被分配了多少資源，被分配資源的大小就是節點上所有 Pod 中定義的容器 request 之和，它可以計算出節點剩余多少資源可以被分配(可分配資源減去已分配的 request 之和)，如果發現節點剩余可分配資源大小比當前要被調度的 Pod 的 reuqest 還小，那么就不會考慮調度到這個節點，反之，才可能調度，所以，如果不配置 request，那么調度器就不能知道節點大概被分配了多少資源出去，調度器得不到準確資訊，也就無法做出合理的調度決策，很容易造成調度不合理，有些節點可能很閑，而有些節點可能很忙，甚至 NotReady，
所以，建議是給所有容器都設定 request，讓調度器感知節點有多少資源被分配了，以便做出合理的調度決策，讓集群節點的資源能夠被合理的分配使用，避免陷入資源分配不均導致一些意外發生，
老是忘記設定怎么辦
有時候我們會忘記給部分容器設定 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
重要的線上應用改如何設定
節點資源不足時，會觸發自動驅逐，將一些低優先級的 Pod 洗掉掉以釋放資源讓節點自愈，沒有設定 request，limit 的 Pod 優先級最低，容易被驅逐；request 不等于 limit 的其次； request 等于 limit 的 Pod 優先級較高，不容易被驅逐，所以如果是重要的線上應用，不希望在節點故障時被驅逐導致線上業務受影響，就建議將 request 和 limit 設成一致，
怎樣設定才能提高資源利用率
如果給給你的應用設定較高的 request 值，而實際占用資源長期遠小于它的 request 值，導致節點整體的資源利用率較低，當然這對時延非常敏感的業務除外，因為敏感的業務本身不期望節點利用率過高，影響網路包收發速度，所以對一些非核心，并且資源不長期占用的應用，可以適當減少 request 以提高資源利用率，
如果你的服務支持水平擴容，單副本的 request 值一般可以設定到不大于 1 核，CPU 密集型應用除外，比如 coredns，設定到 0.1 核就可以，即 100m，
盡量避免使用過大的 request 與 limit
如果你的服務使用單副本或者少量副本，給很大的 request 與 limit，讓它分配到足夠多的資源來支撐業務，那么某個副本故障對業務帶來的影響可能就比較大，并且由于 request 較大，當集群內資源分配比較碎片化，如果這個 Pod 所在節點掛了，其它節點又沒有一個有足夠的剩余可分配資源能夠滿足這個 Pod 的 request 時，這個 Pod 就無法實作漂移，也就不能自愈，加重對業務的影響，
相反，建議盡量減小 request 與 limit，通過增加副本的方式來對你的服務支撐能力進行水平擴容，讓你的系統更加靈活可靠，
避免測驗 namespace 消耗過多資源影響生產業務
若生產集群有用于測驗的 namespace，如果不加以限制，可能導致集群負載過高，從而影響生產業務，可以使用 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
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/701.html
標籤：其他