Kubernetes 如何更好地設定 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