如何為容器配置 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
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
