本篇內(nèi)容主要講解“Kubernetes 中的 requests 和 limits 的概念是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“Kubernetes 中的 requests 和 limits 的概念是什么”吧!
成都創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站制作、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)額濟納,十余年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18982081108
在 K8s 集群中部署資源的時候，你是否經(jīng)常遇到以下情形：
經(jīng)常在 Kubernetes 集群種部署負(fù)載的時候不設(shè)置 CPU requests 或?qū)?CPU requests 設(shè)置得過低（這樣“看上去”就可以在每個節(jié)點上容納更多 Pod ）。
在業(yè)務(wù)比較繁忙的時候，節(jié)點的 CPU 全負(fù)荷運行。業(yè)務(wù)延遲明顯增加，有時甚至機器會莫名其妙地進入 CPU 軟死鎖等“假死”狀態(tài)。
類似地，部署負(fù)載的時候，不設(shè)置內(nèi)存 requests 或者內(nèi)存 requests 設(shè)置得過低，這時會發(fā)現(xiàn)有些 Pod 會不斷地失敗重啟。
而不斷重啟的這些 Pod 通常跑的是 Java 業(yè)務(wù)應(yīng)用。但是這些 Java 應(yīng)用本地調(diào)試運行地時候明明都是正常的。
在 Kubernetes 集群中，集群負(fù)載并不是完全均勻地在節(jié)點間分配的，通常內(nèi)存不均勻分配的情況較為突出，集群中某些節(jié)點的內(nèi)存使用率明顯高于其他節(jié)點。
Kubernetes 作為一個眾所周知的云原生分布式容器編排系統(tǒng)，一個所謂的事實上標(biāo)準(zhǔn)，其調(diào)度器不是應(yīng)該保證資源的均勻分配嗎？
如果在業(yè)務(wù)高峰時間遇到上述問題，并且機器已經(jīng) hang 住甚至無法遠程 ssh 登陸，那么通常留給集群管理員的只剩下重啟集群這一個選項。
如果你遇到過上面類似的情形，想了解如何規(guī)避相關(guān)問題或者你是 Kubernetes 運維開發(fā)人員，想對這類問題的本質(zhì)一探究竟，那么請耐心閱讀下面的章節(jié)。
我們會先對這類問題做一個定性分析，并給出避免此類問題的最佳實踐，最后如果你對 Kubernetes requests 和 limits 的底層機制感興趣，我們可以從源碼角度做進一步地分析，做到“知其然也知其所以然”。
對于情形 1
首先我們需要知道對于 CPU 和內(nèi)存這 2 類資源，他們是有一定區(qū)別的。 CPU 屬于可壓縮資源，其中 CPU 資源的分配和管理是 Linux 內(nèi)核借助于完全公平調(diào)度算法（ CFS ）和 Cgroup 機制共同完成的。
簡單地講，如果 Pod 中服務(wù)使用 CPU 超過設(shè)置的 CPU limits， Pod 的 CPU 資源會被限流（ throttled ）。對于沒有設(shè)置limit的 Pod ，一旦節(jié)點的空閑 CPU 資源耗盡，之前分配的 CPU 資源會逐漸減少。
不管是上面的哪種情況，最終的結(jié)果都是 Pod 已經(jīng)越來越無法承載外部更多的請求，表現(xiàn)為應(yīng)用延時增加，響應(yīng)變慢。
對于情形 2
內(nèi)存屬于不可壓縮資源， Pod 之間是無法共享的，完全獨占的，這也就意味著資源一旦耗盡或者不足，分配新的資源一定是會失敗的。有的 Pod 內(nèi)部進程在初始化啟動時會提前開辟出一段內(nèi)存空間。
比如 JVM 虛擬機在啟動的時候會申請一段內(nèi)存空間。如果內(nèi)存 requests 指定的數(shù)值小于 JVM 虛擬機向系統(tǒng)申請的內(nèi)存，導(dǎo)致內(nèi)存申請失?。?oom-kill ），從而 Pod 出現(xiàn)不斷地失敗重啟。
對于情形 3
實際上在創(chuàng)建 Pod 的過程中，一方面， Kubernetes 需要撥備包含 CPU 和內(nèi)存在內(nèi)的多種資源，這里的資源均衡是包含 CPU 和內(nèi)存在內(nèi)的所有資源的綜合考量。
另一方面， Kubernetes 內(nèi)置的調(diào)度算法不僅僅涉及到“最小資源分配節(jié)點”，還會把其他諸如 Pod 親和性等因素考慮在內(nèi)。并且 Kubernetes 調(diào)度基于的是資源的 requests 數(shù)值，而之所以往往觀察到的是內(nèi)存分布不夠均衡，是因為對于應(yīng)用來說，相比于其他資源，內(nèi)存一般是更緊缺的一類資源。
Kubernetes 的調(diào)度機制是基于當(dāng)前的狀態(tài)。比如當(dāng)出現(xiàn)新的 Pod 進行調(diào)度時，調(diào)度程序會根據(jù)其當(dāng)時對 Kubernetes 集群的資源描述做出最佳調(diào)度決定。
但是 Kubernetes 集群是非常動態(tài)的。比如一個節(jié)點為了維護，我們先執(zhí)行了驅(qū)逐操作，這個節(jié)點上的所有 Pod 會被驅(qū)逐到其他節(jié)點去，當(dāng)我們維護完成后，之前的 Pod 并不會自動回到該節(jié)點上來，因為 Pod 一旦被綁定了節(jié)點是不會觸發(fā)重新調(diào)度的。
由上面的分析我們可以看到，集群的穩(wěn)定性直接決定了其上運行的業(yè)務(wù)應(yīng)用的穩(wěn)定性。而臨時性的資源短缺往往是導(dǎo)致集群不穩(wěn)定的主要因素。集群一旦不穩(wěn)定，輕則業(yè)務(wù)應(yīng)用的性能下降，重則出現(xiàn)相關(guān)結(jié)點不可用。
那么如何提高集群的穩(wěn)定性呢？
一方面，可以通過編輯 Kubelet 配置文件來預(yù)留一部分系統(tǒng)資源，從而保證當(dāng)可用計算資源較少時 kubelet 所在節(jié)點的穩(wěn)定性。這在處理如內(nèi)存和硬盤之類的不可壓縮資源時尤為重要。
另一方面，通過合理地設(shè)置 Pod 的 QoS 可以進一步提高集群穩(wěn)定性：不同 QoS 的 Pod 具有不同的 OOM 分?jǐn)?shù)，當(dāng)出現(xiàn)資源不足時，集群會優(yōu)先 Kill 掉 Best-Effort 類型的 Pod ，其次是 Burstable 類型的 Pod ，最后是Guaranteed 類型的 Pod 。
因此，如果資源充足，可將 QoS pods 類型均設(shè)置為 Guaranteed 。用計算資源換業(yè)務(wù)性能和穩(wěn)定性，減少排查問題時間和成本。同時如果想更好的提高資源利用率，業(yè)務(wù)服務(wù)也可以設(shè)置為 Guaranteed ，而其他服務(wù)根據(jù)重要程度可分別設(shè)置為 Burstable 或 Best-Effort 。
下面我們會以 Kubesphere 平臺為例，演示如何方便優(yōu)雅地配置 Pod 相關(guān)的資源。
前面我們已經(jīng)了解到 Kubernetes 中requests、limits這 2 個參數(shù)的合理設(shè)置對整個集群的穩(wěn)定性至關(guān)重要。而作為 Kubernetes 的發(fā)行版，KubeSphere 極大地降低了 Kubernetes 的學(xué)習(xí)門檻，配合簡潔美觀的 UI 界面，你會發(fā)現(xiàn)有效運維原來是一件如此輕松的事情。下面我們將演示如何在 KubeSphere 平臺中配置容器的相關(guān)資源配額與限制。
在進行演示之前，讓我們再回顧一下 Kubernetes 相關(guān)概念。
為了實現(xiàn) Kubernetes 集群中資源的有效調(diào)度和充分利用， Kubernetes 采用requests和limits兩種限制類型來對資源進行容器粒度的分配。每一個容器都可以獨立地設(shè)定相應(yīng)的requests和limits。這 2 個參數(shù)是通過每個容器 containerSpec 的 resources 字段進行設(shè)置的。一般來說，在調(diào)度的時候requests比較重要，在運行時limits比較重要。
resources: requests: cpu: 50m memory: 50Mi limits: cpu: 100m memory: 100Mi
requests定義了對應(yīng)容器需要的最小資源量。這句話的含義是，舉例來講，比如對于一個 Spring Boot 業(yè)務(wù)容器，這里的requests必須是容器鏡像中 JVM 虛擬機需要占用的最少資源。如果這里把 Pod 的內(nèi)存requests指定為 10Mi ，顯然是不合理的，JVM 實際占用的內(nèi)存 Xms 超出了 Kubernetes 分配給 Pod 的內(nèi)存，導(dǎo)致 Pod 內(nèi)存溢出，從而 Kubernetes 不斷重啟 Pod 。
limits定義了這個容器最大可以消耗的資源上限，防止過量消耗資源導(dǎo)致資源短缺甚至宕機。特別的，設(shè)置為 0 表示對使用的資源不做限制。值得一提的是，當(dāng)設(shè)置limits而沒有設(shè)置requests時，Kubernetes 默認(rèn)令requests等于limits。
進一步可以把requests和limits描述的資源分為 2 類：可壓縮資源（例如 CPU ）和不可壓縮資源（例如內(nèi)存）。合理地設(shè)置limits參數(shù)對于不可壓縮資源來講尤為重要。
前面我們已經(jīng)知道requests參數(shù)會對最終的 Kubernetes 調(diào)度結(jié)果起到直接的顯而易見的影響。借助于 Linux 內(nèi)核 Cgroup 機制，limits參數(shù)實際上是被 Kubernetes 用來約束分配給進程的資源。對于內(nèi)存參數(shù)而言，實際上就是告訴 Linux 內(nèi)核什么時候相關(guān)容器進程可以為了清理空間而被殺死（ oom-kill ）。
總結(jié)一下：
對于 CPU，如果 Pod 中服務(wù)使用 CPU 超過設(shè)置的limits，Pod 不會被 kill 掉但會被限制。如果沒有設(shè)置 limits ，pod 可以使用全部空閑的 CPU 資源。
對于內(nèi)存，當(dāng)一個 Pod 使用內(nèi)存超過了設(shè)置的limits，Pod 中 container 的進程會被 kernel 因 OOM kill 掉。當(dāng) container 因為 OOM 被 kill 掉時，系統(tǒng)傾向于在其原所在的機器上重啟該 container 或本機或其他重新創(chuàng)建一個 Pod。
0 <= requests <=Node Allocatable, requests <= limits <= Infinity
Kubernetes 創(chuàng)建 Pod 時就給它指定了下列一種 QoS 類：Guaranteed，Burstable，BestEffort。
Guaranteed：Pod 中的每個容器，包含初始化容器，必須指定內(nèi)存和 CPU 的requests和limits，并且兩者要相等。
Burstable：Pod 不符合 Guaranteed QoS 類的標(biāo)準(zhǔn)；Pod 中至少一個容器具有內(nèi)存或 CPU requests。
BestEffort：Pod 中的容器必須沒有設(shè)置內(nèi)存和 CPU requests或limits。
結(jié)合結(jié)點上 Kubelet 的 CPU 管理策略，可以對指定 Pod 進行綁核操作，參見官方文檔。
您需要創(chuàng)建一個企業(yè)空間、一個項目和一個帳戶 ( ws-admin )，務(wù)必邀請該帳戶到項目中并賦予 admin 角色。有關(guān)更多信息，請參見創(chuàng)建企業(yè)空間、項目、帳戶和角色。
進入項目基本信息界面，依次直接點擊“項目管理 -> 編輯配額”進入項目的配額設(shè)置頁面。
進入項目配額頁面，為該項目分別指定requests和limits配額。
設(shè)置項目配額的有 2 方面的作用:
限定了該項目下所有 pod 指定的requests和limits之和分別要小于等與這里指定的項目的總requests和limits。
如果在項目中創(chuàng)建任何一個容器沒有指定requests或者limits，那么相應(yīng)的資源會創(chuàng)建報錯，并會以事件的形式給出報錯提示。
可以看到，設(shè)定項目配額以后，在該項目中創(chuàng)建任何容器都需要指定requests和limits，隱含實現(xiàn)了所謂的“code is law”，即人人都需要遵守的規(guī)則。
Kubesphere 中的項目配額等價于 Kubernetes 中的 resource quotas ，項目配額除了能夠以項目為單位管理 CPU 和內(nèi)存的使用使用分配情況，還能夠管理其他類型的資源數(shù)目等，詳細(xì)信息參見資源配額。
上面我們已經(jīng)討論過項目中開啟了配額以后，那么之后創(chuàng)建的 Pod 必須明確指定相應(yīng)的 requests 和 limits 。事實上，在實際的測試或者生產(chǎn)環(huán)境當(dāng)中，大部分 Pod 的 requests 和 limits 是高度相近甚至完全相同的。
有沒有辦法在項目中，事先設(shè)定好默認(rèn)的缺省 requests 和 limits ，當(dāng)用戶沒有指定容器的 requests 和 limits 時，直接應(yīng)用默認(rèn)值，若 Pod 已經(jīng)指定 requests 和 limits 是否直接跳過呢？答案是肯定的。
進入項目基本信息界面，依次直接點擊“項目管理 -> 編輯資源默認(rèn)請求”進入項目的默認(rèn)請求設(shè)置頁面。
進入項目配額頁面，為該項目分別指定 CPU 和內(nèi)存的默認(rèn)值。
KubeSphere 中的項目容器資源默認(rèn)請求是借助于 Kubernetes 中的 Limit Ranges ，目前 KubeSphere 支持 CPU 和內(nèi)存的
requests和limits的默認(rèn)值設(shè)定。
前面我們已經(jīng)了解到，對于一些關(guān)鍵的業(yè)務(wù)容器，通常其流量和負(fù)載相比于其他 Pod 都是比較高的，對于這類容器的requests和limits需要具體問題具體分析。
分析的維度是多個方面的，例如該業(yè)務(wù)容器是 CPU 密集型的，還是 IO 密集型的。是單點的還是高可用的，這個服務(wù)的上游和下游是誰等等。
另一方面，在生產(chǎn)環(huán)境中這類業(yè)務(wù)容器的負(fù)載從時間維度看的話，往往是具有周期性的。因此，業(yè)務(wù)容器的歷史監(jiān)控數(shù)據(jù)可以在參數(shù)設(shè)置方面提供重要的參考價值。
而 KubeSphere 在最初的設(shè)計中，就已經(jīng)在架構(gòu)層面考慮到了這點，將 Prometheus 組件無縫集成到 KubeSphere 平臺中，并提供縱向上至集群層級，下至 Pod 層級的完整的監(jiān)控體系。橫向涵蓋 CPU ，內(nèi)存，網(wǎng)絡(luò)，存儲等。
一般，requests值可以設(shè)定為歷史數(shù)據(jù)的均值，而limits要大于歷史數(shù)據(jù)的均值，最終數(shù)值還需要結(jié)合具體情況做一些小的調(diào)整。
前面我們從日常 Kubernetes 運維出發(fā)，描述了由于 requests 和 limits參數(shù)配置不當(dāng)而引起的一系列問題，闡述了問題產(chǎn)生的原因并給出的最佳實踐。
下面我們將深入到 Kubernetes 內(nèi)部，從代碼里表征的邏輯關(guān)系來進一步分析和驗證上面給出的結(jié)論。
我們知道在 Kubernetes 中 Pod 是最小的調(diào)度單位，Pod 的requests與 Pod 內(nèi)容器的requests關(guān)系如下：
重慶分公司
重慶分公司
func computePodResourceRequest(pod *v1.Pod) *preFilterState {
result := &preFilterState{}
for _, container := range pod.Spec.Containers {
result.Add(container.Resources.Requests)
}
// take max_resource(sum_pod, any_init_container)
for _, container := range pod.Spec.InitContainers {
result.SetMaxResource(container.Resources.Requests)
}
// If Overhead is being utilized, add to the total requests for the pod
if pod.Spec.Overhead != nil && utilfeature.DefaultFeatureGate.Enabled(features.PodOverhead) {
result.Add(pod.Spec.Overhead)
}
return result
}
...
func (f *Fit) PreFilter(ctx context.Context, cycleState *framework.CycleState, pod *v1.Pod) *framework.Status {
cycleState.Write(preFilterStateKey, computePodResourceRequest(pod))
return nil
}
...
func getPreFilterState(cycleState *framework.CycleState) (*preFilterState, error) {
c, err := cycleState.Read(preFilterStateKey)
if err != nil {
// preFilterState doesn't exist, likely PreFilter wasn't invoked.
return nil, fmt.Errorf("error reading %q from cycleState: %v", preFilterStateKey, err)
}
s, ok := c.(*preFilterState)
if !ok {
return nil, fmt.Errorf("%+v convert to NodeResourcesFit.preFilterState error", c)
}
return s, nil
}
...
func (f *Fit) Filter(ctx context.Context, cycleState *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status {
s, err := getPreFilterState(cycleState)
if err != nil {
return framework.NewStatus(framework.Error, err.Error())
}
insufficientResources := fitsRequest(s, nodeInfo, f.ignoredResources, f.ignoredResourceGroups)
if len(insufficientResources) != 0 {
// We will keep all failure reasons.
failureReasons := make([]string, 0, len(insufficientResources))
for _, r := range insufficientResources {
failureReasons = append(failureReasons, r.Reason)
}
return framework.NewStatus(framework.Unschedulable, failureReasons...)
}
return nil
}從上面的源碼中不難看出，調(diào)度器（實際上是 Schedule thread ）首先會在 Pre filter 階段計算出待調(diào)度 Pod 所需要的資源，具體講就是從 Pod Spec 中分別計算初始容器和工作容器requests之和，并取其較大者，特別地，對于像 Kata-container 這樣的微虛機，其自身的虛擬化開銷相比于容器來說是不能忽略不計的，所以還需要加上虛擬化本身的資源開銷，計算出的結(jié)果存入到緩存中，在緊接著的 Filter 階段，會遍歷所有節(jié)點過濾出符合條件的節(jié)點。
在過濾出所有符合條件的節(jié)點以后，如果當(dāng)前滿足的條件的節(jié)點只有一個，那么該 Pod 隨后將被調(diào)度到該節(jié)點。但是更多的情況下，此時過濾之后符合條件的節(jié)點往往有多個，這時候就需要進入 Score 階段，依次對這些節(jié)點進行打分（ Score ）。而打分本身也是包括多個維度，通過內(nèi)置 plugin 的形式綜合評判的。值得注意的是，前面我們定義的 Pod 的requests和limits參數(shù)也會直接影響到NodeResourcesLeastAllocated算法最終的計算結(jié)果。源碼如下：
func leastResourceScorer(resToWeightMap resourceToWeightMap) func(resourceToValueMap, resourceToValueMap, bool, int, int) int64 {
return func(requested, allocable resourceToValueMap, includeVolumes bool, requestedVolumes int, allocatableVolumes int) int64 {
var nodeScore, weightSum int64
for resource, weight := range resToWeightMap {
resourceScore := leastRequestedScore(requested[resource], allocable[resource])
nodeScore += resourceScore * weight
weightSum += weight
}
return nodeScore / weightSum
}
}
...
func leastRequestedScore(requested, capacity int64) int64 {
if capacity == 0 {
return 0
}
if requested > capacity {
return 0
}
return ((capacity - requested) * int64(framework.MaxNodeScore)) / capacity
}可以看到在NodeResourcesLeastAllocated算法中，對于同一個 Pod ，目標(biāo)節(jié)點的資源越充裕，那么該節(jié)點的得分也就越高。換句話說，同一個 Pod 更傾向于調(diào)度到資源充足的節(jié)點。
需要注意的是，實際上在創(chuàng)建 Pod 的過程中，一方面， Kubernetes 需要撥備包含 CPU 和內(nèi)存在內(nèi)的多種資源。每種資源都會對應(yīng)一個權(quán)重（對應(yīng)源碼中的 resToWeightMap 數(shù)據(jù)結(jié)構(gòu)），所以這里的資源均衡是包含 CPU 和內(nèi)存在內(nèi)的所有資源的綜合考量。另一方面，在 Score 階段，除了NodeResourcesLeastAllocated算法以外，調(diào)用器還會使用到其他算法（例如InterPodAffinity）進行分?jǐn)?shù)的評定。
注：在 Kubernetes 調(diào)度器中，會把調(diào)度過程分為若干個階段，即 Pre filter, Filter, Post filter, Score 等。在 Pre filter 階段，用于選擇符合 Pod Spec 描述的 Nodes 。
QOS 作為 Kubernetes 中一種資源保護機制，主要是針對不可壓縮資源的一種控制技術(shù)。比如在內(nèi)存中其通過為不同的 Pod 和容器構(gòu)造 OOM 評分，并且通過內(nèi)核的策略的輔助，從而實現(xiàn)當(dāng)節(jié)點內(nèi)存資源不足的時候，內(nèi)核可以按照策略的優(yōu)先級，優(yōu)先 kill 掉優(yōu)先級比較低（分值越高優(yōu)先級越低）的 Pod。相關(guān)源碼如下:
func GetContainerOOMScoreAdjust(pod *v1.Pod, container *v1.Container, memoryCapacity int64) int {
if types.IsCriticalPod(pod) {
// Critical pods should be the last to get killed.
return guaranteedOOMScoreAdj
}
switch v1qos.GetPodQOS(pod) {
case v1.PodQOSGuaranteed:
// Guaranteed containers should be the last to get killed.
return guaranteedOOMScoreAdj
case v1.PodQOSBestEffort:
return besteffortOOMScoreAdj
}
// Burstable containers are a middle tier, between Guaranteed and Best-Effort. Ideally,
// we want to protect Burstable containers that consume less memory than requested.
// The formula below is a heuristic. A container requesting for 10% of a system's
// memory will have an OOM score adjust of 900. If a process in container Y
// uses over 10% of memory, its OOM score will be 1000. The idea is that containers
// which use more than their request will have an OOM score of 1000 and will be prime
// targets for OOM kills.
// Note that this is a heuristic, it won't work if a container has many small processes.
memoryRequest := container.Resources.Requests.Memory().Value()
oomScoreAdjust := 1000 - (1000*memoryRequest)/memoryCapacity
// A guaranteed pod using 100% of memory can have an OOM score of 10. Ensure
// that burstable pods have a higher OOM score adjustment.
if int(oomScoreAdjust) < (1000 + guaranteedOOMScoreAdj) {
return (1000 + guaranteedOOMScoreAdj)
}
// Give burstable pods a higher chance of survival over besteffort pods.
if int(oomScoreAdjust) == besteffortOOMScoreAdj {
return int(oomScoreAdjust - 1)
}
return int(oomScoreAdjust)
}Kubernetes 是一個具有良好移植和擴展性的開源平臺，用于管理容器化的工作負(fù)載和服務(wù)。 Kubernetes 擁有一個龐大且快速增長的生態(tài)系統(tǒng)，已成為容器編排領(lǐng)域的事實標(biāo)準(zhǔn)。但是也不可避免地引入許多復(fù)雜性。
而 KubeSphere 作為國內(nèi)唯一一個開源的 Kubernetes 發(fā)行版，極大地降低了使用 Kubernetes 的門檻。借助于 KubeSphere 平臺，原先需要通過后臺命令行和 yaml 文件管理的系統(tǒng)配置，現(xiàn)在只需要在簡潔美觀的 UI 界面上輕松完成。
到此，相信大家對“Kubernetes 中的 requests 和 limits 的概念是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！
