【51CTO.com快譯】我在使用Kubernetes的頭一天將應(yīng)用程序Docker容器化，并部署到生產(chǎn)集群。我將Buffer的其中一個(gè)***吞吐量(和低風(fēng)險(xiǎn))端點(diǎn)從整體式應(yīng)用程序遷移出來(lái)。這個(gè)端點(diǎn)造成了越來(lái)越大的麻煩，偶爾會(huì)影響優(yōu)先級(jí)更高的其他流量。

[[252635]]

我們用curl進(jìn)行一番手動(dòng)測(cè)試之后，決定開(kāi)始將流量轉(zhuǎn)移到Kubernetes上的新服務(wù)。負(fù)載為1%時(shí)，一切看起來(lái)很棒;然后提高到10%，依然很棒;之后提高到50%，服務(wù)突然開(kāi)始陷入崩潰循環(huán)。我的***反應(yīng)是，將服務(wù)從4個(gè)副本增加到20個(gè)。這有點(diǎn)幫助，服務(wù)處理流量，但pod仍然陷入崩潰循環(huán)。

我使用kubectl describe進(jìn)行一些調(diào)查后了解到，由于OOMKilled即內(nèi)存不足，Kubelet在終止pod。我深入探究后意識(shí)到，我從另一個(gè)部署復(fù)制粘貼YAML時(shí)，設(shè)置了一些限制性過(guò)強(qiáng)的內(nèi)存限制。這段經(jīng)歷讓我開(kāi)始思考如何有效地設(shè)置請(qǐng)求和限額。

一、請(qǐng)求vs限制

Kubernetes允許對(duì)CPU、內(nèi)存和本地短暫存儲(chǔ)(v1.12中的測(cè)試版功能)之類的資源設(shè)置可配置的請(qǐng)求和限制。CPU等資源是可壓縮的，這意味著可以使用CPU管理策略來(lái)限制容器。內(nèi)存等其他資源由Kubelet監(jiān)控，如果超過(guò)限制就被終止。使用請(qǐng)求和限制的不同配置，就可以針對(duì)每個(gè)工作負(fù)載實(shí)現(xiàn)不同的服務(wù)質(zhì)量。

1.限制

限制是允許工作負(fù)載消耗的上限。超過(guò)請(qǐng)求的限制閾值將觸發(fā)Kubelet終止pod。如果未設(shè)置限制，工作負(fù)載就會(huì)消耗某個(gè)節(jié)點(diǎn)上的所有資源。如果運(yùn)行的多個(gè)工作負(fù)載沒(méi)有限制，將按照盡力原則分配資源。

2.請(qǐng)求

調(diào)度程序使用請(qǐng)求為工作負(fù)載分配資源。工作負(fù)載可以使用所有請(qǐng)求的資源，無(wú)需Kubernetes的干預(yù)。如果未設(shè)置限制且超過(guò)請(qǐng)求閾值，容器將受限制，只能使用請(qǐng)求的資源。如果設(shè)置了限制但未設(shè)置任何請(qǐng)求，請(qǐng)求的資源將與請(qǐng)求的限制相匹配。

3.服務(wù)質(zhì)量

有三種基本的服務(wù)質(zhì)量(QoS)可通過(guò)資源和限制來(lái)實(shí)現(xiàn)――***的QoS配置取決于工作負(fù)載的要求。

圖1

4.保證的QoS

保證的QoS可通過(guò)僅設(shè)置限制來(lái)實(shí)現(xiàn)。這意味著容器可以使用調(diào)度程序?yàn)槠渑渲玫乃匈Y源。對(duì)于受CPU限制且相對(duì)可預(yù)測(cè)的工作負(fù)載來(lái)說(shuō)，比如處理請(qǐng)求的Web服務(wù)器，這是很好的QoS。

圖2

5.可突發(fā)式QoS

可突發(fā)式QoS通過(guò)同時(shí)設(shè)置請(qǐng)求和限制(請(qǐng)求低于設(shè)置)來(lái)配置。這意味著可以保證容器使用最多是配置請(qǐng)求的資源，如果某個(gè)節(jié)點(diǎn)上有，可以使用資源的全部配置限額。這對(duì)于短暫使用資源或需要密集初始化過(guò)程的工作負(fù)載來(lái)說(shuō)很有用。一個(gè)例子就是構(gòu)建Docker容器的worker節(jié)點(diǎn)或運(yùn)行未經(jīng)過(guò)優(yōu)化的JVM進(jìn)程的容器。

圖3

6.盡力式QoS

盡力式QoS通過(guò)既不設(shè)置請(qǐng)求也不設(shè)置限制來(lái)配置。這意味著容器可以使用計(jì)算機(jī)上的任何可用資源。從調(diào)度程序的角度來(lái)看，這是優(yōu)先級(jí)***的任務(wù)，會(huì)在突發(fā)式QoS和保證式QoS配置之前被終止。這對(duì)于可中斷、低優(yōu)先級(jí)的工作負(fù)載(比如迭代運(yùn)行的冪等優(yōu)化過(guò)程)來(lái)說(shuō)很有用。

圖4

二、設(shè)置請(qǐng)求和限制

要設(shè)置合理的請(qǐng)求和限制，關(guān)鍵是找到單個(gè)pod的斷點(diǎn)(breaking point)。若使用幾種不同的負(fù)載測(cè)試方法，可以在應(yīng)用程序進(jìn)入到生產(chǎn)環(huán)境之前了解其不同的故障模式。被推向極限時(shí)，幾乎每個(gè)應(yīng)用程序都有各自的一組故障模式。

要準(zhǔn)備測(cè)試，確保將副本計(jì)數(shù)設(shè)為1，并從一組保守的限制開(kāi)始，比如：

# limits might look something like  
replicas: 1  
...  
cpu: 100m # ~1/10th of a core  
memory: 50Mi # 50 Mebibytes 

注意，在此過(guò)程中使用限制很重要，以便清楚地看到結(jié)果(內(nèi)存使用率高時(shí)遏制CPU和終止pod)。測(cè)試迭代完成后，一次更改一個(gè)資源限制(CPU或內(nèi)存)。

1.Ramp-up測(cè)試

ramp-up測(cè)試逐漸增加負(fù)載，直到服務(wù)在不堪重負(fù)而失效或測(cè)試完成。

圖5

如果ramp-up測(cè)試突然失敗，這表明資源限制過(guò)于苛嚴(yán)。觀察到性能突然變化時(shí)，將資源限制增加一倍、重復(fù)測(cè)試，直到測(cè)試成功完成。

圖6

資源限制接近***時(shí)(至少對(duì)于Web風(fēng)格的服務(wù)來(lái)說(shuō))，性能會(huì)逐漸穩(wěn)定地下降。

圖7

如果負(fù)載增加時(shí)性能沒(méi)有變化，可能為工作負(fù)載分配了太多的資源。

2.持續(xù)時(shí)間測(cè)試

運(yùn)行ramp-up測(cè)試并調(diào)整限制后，可以進(jìn)行持續(xù)時(shí)間測(cè)試了。持續(xù)時(shí)間測(cè)試是指在一段延長(zhǎng)的時(shí)間內(nèi)(至少10分鐘，但越長(zhǎng)越好)添加一致的負(fù)載，但又恰好在斷點(diǎn)之下。

圖8

該測(cè)試的目的是識(shí)別在短暫的ramp-up測(cè)試中發(fā)現(xiàn)不了的內(nèi)存泄漏和隱藏的隊(duì)列機(jī)制。如果在此階段進(jìn)行調(diào)整，它們應(yīng)該很小(變化>105)。好的結(jié)果將表明性能在測(cè)試持續(xù)期間保持穩(wěn)定。

圖9

3.保留失效日志

進(jìn)行測(cè)試階段時(shí)，記錄服務(wù)失敗時(shí)的執(zhí)行情況至關(guān)重要?？梢詫⒐收夏Ｊ教砑拥竭\(yùn)行手冊(cè)(run book)和說(shuō)明文檔，排查生產(chǎn)環(huán)境中的問(wèn)題時(shí)很有用。我們?cè)跍y(cè)試時(shí)發(fā)現(xiàn)了一些觀察到的故障模式：

• 內(nèi)存慢慢增加
• CPU固定在100%
• 500s
• 響應(yīng)時(shí)間長(zhǎng)
• 請(qǐng)求丟棄
• 響應(yīng)時(shí)間差異大

將日志保存起來(lái)，以備不時(shí)之需，因?yàn)橛幸惶焖鼈兛梢詾槟慊蛲略谂挪閱?wèn)題時(shí)幫大忙。

三、實(shí)用的工具

雖然可以使用Apache Bench之類的工具添加負(fù)載、使用cAdvisor之類的工具直觀地顯示資源利用率，但一些工具更適合設(shè)置資源限制。

1.Loader.IO

Loader.io是一種托管的負(fù)載測(cè)試服務(wù)。它讓你可以配置ramp-up測(cè)試和持續(xù)時(shí)間測(cè)試，測(cè)試運(yùn)行時(shí)直觀地顯示應(yīng)用程序的性能和負(fù)載，并迅速開(kāi)始和停止測(cè)試。測(cè)試結(jié)果歷史記錄存儲(chǔ)起來(lái)，因此資源限制變化時(shí)很容易比較結(jié)果。

圖10

2.Kubescope CLI

Kubescope CLI這款工具在Kubernetes中(或本地)運(yùn)行，可直接從Docker收集和直觀顯示容器度量指標(biāo)。它使用cAdvisor之類的工具或另一項(xiàng)集群指標(biāo)收集服務(wù)，每秒(而不是每隔10秒至15秒)收集一次指標(biāo)。由于間隔10秒至15秒，你在測(cè)試期間大有時(shí)間錯(cuò)過(guò)瓶頸。若使用cAdvisor，你得為每次測(cè)試尋找新的pod，因?yàn)镵ubernetes在超過(guò)資源限制時(shí)終止pod。Kubescope CLI直接從Docker收集指標(biāo)(可以設(shè)置自己的間隔)，并使用正則表達(dá)式來(lái)選擇和過(guò)濾想要直觀顯示的容器，從而解決了這個(gè)問(wèn)題。

圖11

結(jié)論

只有在你知道一項(xiàng)服務(wù)何時(shí)壞掉、如何壞掉，它才準(zhǔn)備好用于生產(chǎn)環(huán)境，對(duì)此我深有體會(huì)。希望你能從我的錯(cuò)誤中吸取教訓(xùn)，利用其中一些方法對(duì)部署的環(huán)境設(shè)置資源限制和請(qǐng)求。這將為你的系統(tǒng)增添彈性和可預(yù)測(cè)性，從而使客戶滿意，但愿幫助你高枕無(wú)憂。

原文標(biāo)題：Optimizing Kubernetes resource allocation in production，作者：Harrison Harnisch

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】