Kubernetes 服務部署最佳實踐(一) ——如何更好地設置 Request 與 Limit

如何爲容器配置 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

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！