眾所周知,Kubernetes QOS 分為三個(gè)級(jí)別：

• Guaranteed：Pod 里的每個(gè)容器都必須有內(nèi)存/CPU 限制和請(qǐng)求，而且值必須相等。如果一個(gè)容器只指明limit而未設(shè)定request，則request的值等于limit值。
• Burstable：Pod 里至少有一個(gè)容器有內(nèi)存或者 CPU 請(qǐng)求且不滿(mǎn)足 Guarantee 等級(jí)的要求，即內(nèi)存/CPU 的值設(shè)置的不同。
• BestEffort：容器必須沒(méi)有任何內(nèi)存或者 CPU 的限制或請(qǐng)求。

谷歌的最佳實(shí)踐告訴你，重要服務(wù)一定要配置 Guaranteed 的，這樣在資源不足的時(shí)候可以保證你的重要服務(wù)不被驅(qū)逐。

最佳實(shí)踐要求你這樣配置是從運(yùn)維和后期運(yùn)營(yíng)的角度來(lái)說(shuō)的，團(tuán)隊(duì)剛起步，不設(shè)置資源請(qǐng)求和限制的情況下基本可以正常工作，但隨著團(tuán)隊(duì)和項(xiàng)目的增長(zhǎng)，您將開(kāi)始遇到穩(wěn)定性問(wèn)題。服務(wù)之間相互影響，這時(shí)候可能需要為服務(wù)添加限制，并且可以讓您免于遇到許多令人頭疼的問(wèn)題。

這里我們應(yīng)該已經(jīng)清楚，通過(guò)遵循最佳實(shí)踐，使整個(gè)集群具有更大的靈活性和可靠性。

但是當(dāng)涉及到 CPU 限制時(shí)，事情就變得有趣了。CPU 是可壓縮資源。如果您的應(yīng)用開(kāi)始達(dá)到 CPU 限制，Kubernetes 就會(huì)開(kāi)始限制您的容器。這意味著 CPU 將受到人為限制，使您的應(yīng)用程序性能可能更差！

1. 為什么會(huì)這樣呢？

因?yàn)楫?dāng)你在容器編排器中設(shè)置硬 CPU 限制時(shí)，內(nèi)核使用完全公平調(diào)度程序 (CFS) Cgroup來(lái)強(qiáng)制執(zhí)行這些限制。CFS Cgroup 機(jī)制使用兩個(gè)設(shè)置來(lái)管理 CPU 分配：配額和周期。當(dāng)應(yīng)用程序在給定時(shí)間段內(nèi)使用超過(guò)其分配的 CPU 配額時(shí)，它會(huì)受到限制，直到下一個(gè)時(shí)間段。

cgroup 的所有 CPU 指標(biāo)都位于??/sys/fs/cgroup/cpu,cpuacct/<container>??. 配額和期間設(shè)置位于??cpu.cfs_quota_us??和中??cpu.cfs_period_us??。

您還可以查看限制指標(biāo) cpu.stat。在里面 cpu.stat 你會(huì)發(fā)現(xiàn)：

• nr_periods– cgroup 任何線程可運(yùn)行的周期數(shù)
• nr_throttled– 應(yīng)用程序使用其全部配額并受到限制的可運(yùn)行周期數(shù)
• throttled_time– 控制 cgroup 中各個(gè)線程的總時(shí)間

2. 舉個(gè)簡(jiǎn)單的例子

單線程應(yīng)用程序在具有 cgroup 約束的 CPU 上運(yùn)行。此應(yīng)用程序需要 200 毫秒的處理時(shí)間來(lái)完成一個(gè)請(qǐng)求。不受約束，它的響應(yīng)看起來(lái)如下圖。

沒(méi)有配置限制的請(qǐng)求

現(xiàn)在，假設(shè)我們?yōu)閼?yīng)用程序分配了 0.4 CPU 的 CPU 限制。這意味著應(yīng)用程序每 100 毫秒周期獲得 40 毫秒的運(yùn)行時(shí)間——即使這些時(shí)間 CPU 沒(méi)有其他工作要做。200 毫秒的請(qǐng)求現(xiàn)在需要 440 毫秒才能完成。

配置限制的請(qǐng)求

這個(gè)時(shí)候你查看下所在容器路徑下的 cpu.stat throttled_time 你會(huì)發(fā)現(xiàn)被限制了 240ms（對(duì)于每 100 毫秒的周期，應(yīng)用程序只能運(yùn)行 40 毫秒，并被限制 60 毫秒。它已被限制了 4 個(gè)周期，因此 4 * 60 = 240 毫秒。）

換一個(gè)通俗點(diǎn)的說(shuō)法，當(dāng)您要求 1 個(gè) CPU 時(shí)，這意味著您的應(yīng)用程序每秒可以使用 1 個(gè) CPU 內(nèi)核。如果它是一個(gè)單線程，它將能夠一直使用一個(gè)內(nèi)核。但是，如果它有 2 個(gè)線程，則每秒可以無(wú)限制地使用 2 個(gè)核心秒。因此，有了這個(gè)限制，它可以在 1/2 秒內(nèi)完全使用 2 個(gè)核心，然后會(huì)受到限制。（雖然這并不是真正以秒為單位來(lái)衡量的，實(shí)際是us，但我發(fā)現(xiàn)這樣更容易理解）。

看到這里，你可能會(huì)說(shuō)，這只是一種約束，超出范圍的資源，就是不能使用，否則將被限制。

3. 是否存在不必要的限制

并沒(méi)有這么簡(jiǎn)單，很多人反饋遭到了不必要的 cgroup 限制，甚至還沒(méi)有 CPU 上限，這里有激烈的討論：

1. ????https://github.com/kubernetes/kubernetes/issues/67577????
2. ????https://github.com/kubernetes/kubernetes/issues/51135????
3. ????https://github.com/kubernetes/kubernetes/issues/70585????
4. ????https://github.com/kubernetes/kubernetes/pull/75682????

運(yùn)行容器時(shí)要檢查的關(guān)鍵指標(biāo)是throttling. 這表明您的容器被限制的次數(shù)。我們發(fā)現(xiàn)很多容器無(wú)論 CPU 使用率是否接近極限都會(huì)受到限制。如下一個(gè)熱心網(wǎng)友反饋的案例：

在動(dòng)畫(huà)中可以看到 CPU 限制設(shè)置為800m（0.8 個(gè)核心，80% 的核心），峰值使用率最高為200m（20% 的核心）?？吹街?，我們可能會(huì)認(rèn)為我們有足夠的 CPU 讓服務(wù)在它節(jié)流之前運(yùn)行，對(duì)吧？. 現(xiàn)在看看這個(gè)：

即使 CPU 使用率低于 CPU 限制，您也會(huì)注意到發(fā)生了 CPU 限制。最大 CPU 使用率甚至沒(méi)有接近 CPU 限制。

限制就意味著服務(wù)性能下降和延遲增高。

4. 什么原因?qū)е碌哪兀?/span>

本質(zhì)上來(lái)說(shuō)，這個(gè)問(wèn)題是 linux 內(nèi)核導(dǎo)致，具體可以看下這個(gè)視頻：????https://www.youtube.com/watch?v=UE7QX98-kO0????

這個(gè)視頻大概意思是這樣的。

這里有一個(gè)多線程守護(hù)進(jìn)程的例子，它有兩個(gè)工作線程，每個(gè)工作線程都固定在自己的核心上。如下圖，第一個(gè)圖顯示了 cgroup 在一段時(shí)間內(nèi)的全局配額。這從 20ms 的配額開(kāi)始，這與 0.2 CPU 相關(guān)。中間的圖表顯示分配給每個(gè) CPU 隊(duì)列的配額，底部的圖表顯示實(shí)際工作線程在其 CPU 上運(yùn)行的時(shí)間。

在 10 毫秒：

• Worker 1 收到了一個(gè)請(qǐng)求。
• 一部分配額從全局配額轉(zhuǎn)移到 CPU 1 的每個(gè) CPU 隊(duì)列。
• Worker 1 需要 5ms 來(lái)處理和響應(yīng)請(qǐng)求。

在 17 毫秒：

• Worker 2 收到了一個(gè)請(qǐng)求。
• 一部分配額從全局配額轉(zhuǎn)移到 CPU 2 的每個(gè) CPU 隊(duì)列。

Worker 1 需要精確 5 毫秒來(lái)響應(yīng)請(qǐng)求的機(jī)會(huì)是非常不現(xiàn)實(shí)的。如果請(qǐng)求需要其他一些處理時(shí)間會(huì)發(fā)生什么？

在 30 毫秒：

• Worker 1 收到了一個(gè)請(qǐng)求。
• Worker 1 只需要 1 毫秒來(lái)處理請(qǐng)求，而 CPU 1 的每個(gè) CPU 存儲(chǔ)桶上還剩下 4 毫秒。
• 由于每個(gè) CPU 運(yùn)行隊(duì)列上還有剩余時(shí)間，但 CPU 1 上沒(méi)有更多可運(yùn)行線程，因此設(shè)置了一個(gè)計(jì)時(shí)器以將 slack 配額返回給全局存儲(chǔ)桶。這個(gè)定時(shí)器在worker 1停止運(yùn)行后設(shè)置為7ms。

在 38 毫秒：

• CPU 1 上設(shè)置的 slack 計(jì)時(shí)器觸發(fā)并將除 1 ms 之外的所有配額返回到全局配額池。
• 這會(huì)在 CPU 1 上留下 1 毫秒的配額。

在 41 毫秒：

• Worker 2 收到一個(gè)長(zhǎng)請(qǐng)求。
• 所有剩余時(shí)間都從全局存儲(chǔ)桶轉(zhuǎn)移到 CPU 2 的 per-CPU 存儲(chǔ)桶，Worker 2 使用所有時(shí)間。

在 49 毫秒：

• CPU 2 上的 Worker 2 現(xiàn)在在未完成請(qǐng)求的情況下受到限制。
• 盡管 CPU 1 仍有 1ms 的配額，但仍會(huì)發(fā)生這種情況。

雖然 1 毫秒可能對(duì)雙核機(jī)器沒(méi)有太大影響，但這些毫秒在高核數(shù)機(jī)器上加起來(lái)。如果我們?cè)?88 核 (n) 機(jī)器上遇到此行為，我們可能會(huì)在每個(gè)周期內(nèi)耗費(fèi) 87 (n-1) 毫秒。那可能無(wú)法使用的 87 毫秒或 0.87 CPU（每個(gè)Container）。這就是我們通過(guò)過(guò)度節(jié)流來(lái)達(dá)到低配額使用的方式。在最好的情況下，如果修復(fù)，使受影響的應(yīng)用程序的每個(gè)實(shí)例的可用 CPU 增加 0.87，或者所需的 CPU 配額相應(yīng)減少。這些優(yōu)勢(shì)將在我們的集群中提高應(yīng)用程序密度并縮短應(yīng)用程序響應(yīng)時(shí)間。

當(dāng) 8 核和 10 核機(jī)器這個(gè)問(wèn)題基本上沒(méi)有引起注意?，F(xiàn)在核心數(shù)量風(fēng)靡一時(shí)，這個(gè)問(wèn)題變得更加明顯。這就是為什么我們注意到在更高核心數(shù)的機(jī)器上運(yùn)行同一應(yīng)用程序時(shí)會(huì)增加限制。

總結(jié)來(lái)說(shuō)，時(shí)鐘偏差限制問(wèn)題，這導(dǎo)致每個(gè)時(shí)期的配額都受到嚴(yán)格限制。這個(gè)問(wèn)題一直是存在的，至少自提交 512ac999 和內(nèi)核 v4.18 以來(lái)，它就是這樣工作的。

5. linux 內(nèi)核是如何解決這個(gè)問(wèn)題

當(dāng)且僅當(dāng)每個(gè) CPU 的過(guò)期時(shí)間與全局過(guò)期時(shí)間匹配時(shí)，預(yù)補(bǔ)丁代碼才會(huì)在運(yùn)行時(shí)過(guò)期??cfs_rq->runtime_expires != cfs_b->runtime_expires??。通過(guò)檢測(cè)內(nèi)核，我證明了這種情況在我的節(jié)點(diǎn)上幾乎從未出現(xiàn)過(guò)。因此，那 1 毫秒永不過(guò)期。該補(bǔ)丁將此邏輯從基于時(shí)鐘時(shí)間更改為周期序列計(jì)數(shù)，解決了內(nèi)核中長(zhǎng)期存在的錯(cuò)誤。代碼如下：

- if (cfs_rq->runtime_expires != cfs_b->runtime_expires) { 
+ if (cfs_rq->expires_seq == cfs_b->expires_seq) { 
               /* 延長(zhǎng)本地期限，漂移以 2 個(gè)滴答為界 */ 
                cfs_rq->runtime_expires + = TICK_NSEC; 
       } else { 
                /* 全局截止日期提前，過(guò)期已過(guò) */ 
                cfs_rq->runtime_remaining = 0; 
        }

修改問(wèn)題 5.4+ 主線內(nèi)核的一部分。它們已被反向移植到許多可用的內(nèi)核中：

1. RHEL 7: 3.10.0–1062.8.1.el7+
2. RHEL 8: 4.18.0–147.2.1.el8_1+

• Linux-stable: 4.14.154+, 4.19.84+, 5.3.9+
• Ubuntu: 4.15.0–67+, 5.3.0–24+
• Redhat Enterprise Linux:
• CoreOS: v4.19.84+

該錯(cuò)誤????https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=763a9ec06c4????已被修復(fù)并合并到運(yùn)行 4.19 或更高版本的 Linux 發(fā)行版的內(nèi)核中。

但是，在閱讀kubernetes issue時(shí)????https://github.com/kubernetes/kubernetes/issues/67577????，我們可以看到各種 Linux 項(xiàng)目一直在引用這個(gè) issue，所以我猜一些 Linux 發(fā)行版仍然存在這個(gè) bug，并且正在努力整合修復(fù)。

如果你的 Linux 發(fā)行版的內(nèi)核版本低于 4.19，我建議你為你的節(jié)點(diǎn)升級(jí)到最新的 Linux 發(fā)行版，但無(wú)論如何，你應(yīng)該嘗試移除 CPU 限制并查看是否有任何限制.

6. 總結(jié)

監(jiān)控你的容器，是否因?yàn)?throttle 而導(dǎo)致的性能不佳，如果確實(shí)發(fā)生了，最好通過(guò)分批升級(jí)內(nèi)核版本解決，如果無(wú)法升級(jí)，可以通過(guò)方式解決：

解除限制（個(gè)人覺(jué)得這個(gè)并不是一個(gè)好主意）

• 有性能要求的 Pod 調(diào)度到帶特定污點(diǎn)的節(jié)點(diǎn)；
• 對(duì)這些 Pod 刪除 CPU 限制，可以考慮在 namespace 級(jí)別添加限制。

增加資源

另外 CPU throttle 節(jié)流主要是因?yàn)?CPU 限制較低。它的限制影響 Cgroup 的行為。因此，一個(gè)快速解決該問(wèn)題的方法是根據(jù)監(jiān)控將限值提高 10-25%，以確保降低峰值或完全避免峰值。

自動(dòng)擴(kuò)容

因?yàn)閷?CPU 請(qǐng)求和限制設(shè)置為相同的值通常會(huì)給人們他們所期望的行為，解決此問(wèn)題的簡(jiǎn)單方法是將 CPU 請(qǐng)求和限制設(shè)置為相同的值并添加 HPA。讓 Pod 根據(jù)負(fù)載進(jìn)行自動(dòng)擴(kuò)縮容。