如何優(yōu)化生產(chǎn)環(huán)境下的Kubernetes資源分配

譯文
作者：布加迪編譯 2018-12-18 09:00:26

開發(fā)

前端

云計(jì)算 我在使用Kubernetes的頭一天將應(yīng)用程序Docker容器化，并部署到生產(chǎn)集群。我將Buffer的其中一個最高吞吐量(和低風(fēng)險)端點(diǎn)從整體式應(yīng)用程序遷移出來。這個端點(diǎn)造成了越來越大的麻煩，偶爾會影響優(yōu)先級更高的其他流量。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供通榆網(wǎng)站建設(shè)、通榆做網(wǎng)站、通榆網(wǎng)站設(shè)計(jì)、通榆網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、通榆企業(yè)網(wǎng)站模板建站服務(wù)，十余年通榆做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

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

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

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

一、請求vs限制

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

1.限制

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

2.請求

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

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

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

圖1

4.保證的QoS

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

圖2

5.可突發(fā)式QoS

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

圖3

6.盡力式QoS

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

圖4

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

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

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

  
 
 
 

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

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

1.Ramp-up測試

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

圖5

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

圖6

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

圖7

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

2.持續(xù)時間測試

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

圖8

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

圖9

3.保留失效日志

進(jìn)行測試階段時，記錄服務(wù)失敗時的執(zhí)行情況至關(guān)重要。可以將故障模式添加到運(yùn)行手冊(run book)和說明文檔，排查生產(chǎn)環(huán)境中的問題時很有用。我們在測試時發(fā)現(xiàn)了一些觀察到的故障模式：

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

將日志保存起來，以備不時之需，因?yàn)橛幸惶焖鼈兛梢詾槟慊蛲略谂挪閱栴}時幫大忙。

三、實(shí)用的工具

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

1.Loader.IO

Loader.io是一種托管的負(fù)載測試服務(wù)。它讓你可以配置ramp-up測試和持續(xù)時間測試，測試運(yùn)行時直觀地顯示應(yīng)用程序的性能和負(fù)載，并迅速開始和停止測試。測試結(jié)果歷史記錄存儲起來，因此資源限制變化時很容易比較結(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秒，你在測試期間大有時間錯過瓶頸。若使用cAdvisor，你得為每次測試尋找新的pod，因?yàn)镵ubernetes在超過資源限制時終止pod。Kubescope CLI直接從Docker收集指標(biāo)(可以設(shè)置自己的間隔)，并使用正則表達(dá)式來選擇和過濾想要直觀顯示的容器，從而解決了這個問題。

圖11

結(jié)論

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

當(dāng)前標(biāo)題：如何優(yōu)化生產(chǎn)環(huán)境下的Kubernetes資源分配
網(wǎng)站URL：http://fisionsoft.com.cn/article/dhjjosi.html