這篇文章主要講解了“如何優(yōu)化Kubernetes上的JVM Warm-up”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“如何優(yōu)化Kubernetes上的JVM Warm-up”吧！
創(chuàng)新互聯(lián)公司專注于嘉興網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供嘉興營銷型網(wǎng)站建設(shè)，嘉興網(wǎng)站制作、嘉興網(wǎng)頁設(shè)計、嘉興網(wǎng)站官網(wǎng)定制、重慶小程序開發(fā)服務(wù)，打造嘉興網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供嘉興網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
幾年前，我們從單體架構(gòu)逐步轉(zhuǎn)為微服務(wù)架構(gòu)，并且部署到Kubernetes中。大多數(shù)新服務(wù)都是用Java開發(fā)的。當(dāng)我們啟用Java服務(wù)時，我們首先遇到了這個問題。通過負(fù)載測試執(zhí)行了正常的容量規(guī)劃過程，并確定N個容器足以處理超出預(yù)期的峰值流量。
盡管該服務(wù)可以毫不費力地處理高峰流量，但我們開始在部署過程中發(fā)現(xiàn)問題。我們的每個Pod在高峰時間處理的RPM都超過10k，而我們使用的是Kubernetes滾動更新機制。在部署期間，服務(wù)的響應(yīng)時間會激增幾分鐘，然后再穩(wěn)定到通常的穩(wěn)定狀態(tài)。在我們的NewRelic儀表板中，我們將看到類似于以下的圖形：
同時，依賴于我們該部署的其他服務(wù)在相關(guān)時間段內(nèi)也發(fā)生了高響應(yīng)時間和超時錯誤。
我們很快意識到該問題與JVM預(yù)熱階段有關(guān)，但是由于正在進(jìn)行其他重要事情，因此沒有太多時間進(jìn)行排查。因此，我們嘗試了最簡單的解決方案--增加容器的數(shù)量，以減少每個容器的吞吐量。我們將Pod的數(shù)量增加了幾乎三倍，因此每個Pod在高峰時處理的吞吐量約為4k RPM。我們還調(diào)整了部署策略，以確保一次最多25％的部署（使用maxSurge和maxUnavailable參數(shù)）。這樣就解決了問題，盡管我們的運行速度是穩(wěn)態(tài)所需容量的3倍，但我們能夠在我們的服務(wù)或任何相關(guān)服務(wù)中毫無問題地進(jìn)行部署。
在接下來的幾個月中，隨著我們遷移更多服務(wù)，我們也開始在其他服務(wù)中頻繁注意到該問題。然后，我們決定花一些時間來排查問題并找到更好的解決方案。
閱讀各種文章之后，我們決定嘗試一下熱身腳本。我們的想法是運行一個預(yù)熱腳本，該腳本將綜合請求發(fā)送給該服務(wù)幾分鐘，以期預(yù)熱JVM，然后才允許實際流量通過。
為了創(chuàng)建預(yù)熱腳本，我們從生產(chǎn)流量中抓取了實際的URL。然后，我們創(chuàng)建了一個Python腳本，該腳本使用這些URL發(fā)送并行請求。我們相應(yīng)地配置了就緒探針的initialDelaySeconds，以確保預(yù)熱腳本在Pod準(zhǔn)備就緒并開始接受流量之前完成。
令我們驚訝的是，盡管我們看到了一些改進(jìn)，但這并不重要。我們?nèi)匀挥^察到響應(yīng)時間和錯誤。另外，預(yù)熱腳本引入了新問題。之前，我們的Pod可以在40-50秒內(nèi)準(zhǔn)備就緒，但是使用腳本，它們大約需要3分鐘，這在部署過程中成為一個問題，但更重要的是在自動伸縮過程中。我們對熱身機制進(jìn)行了一些調(diào)整，例如在熱身腳本和實際流量之間進(jìn)行短暫的重疊，并在腳本本身中進(jìn)行更改，但并沒有看到明顯的改進(jìn)。最后，我們認(rèn)為熱身策略所帶來的小收益是不值得的，因此完全放棄了。
既然我們的熱身腳本想法破滅了，決定嘗試一些啟發(fā)式技術(shù)：
GC (G1, CMS, and Parallel) and various GC parameters
Heap memory
CPU allocated
經(jīng)過幾輪實驗，我們終于取得了突破。我們正在測試的服務(wù)配置了Kubernetes資源限制：
resources: requests: cpu: 1000m memory: 2000Mi limits: cpu: 1000m memory: 2000Mi
我們增加了CPU請求并將其限制為2000m，并部署了該服務(wù)以查看影響。與預(yù)熱腳本相比，我們在響應(yīng)時間和錯誤方面看到了巨大的進(jìn)步。
為了進(jìn)一步測試，我們將配置升級到3000m CPU，令人驚訝的是，問題完全消失了。如下所示，響應(yīng)時間沒有峰值。
很快就發(fā)現(xiàn)問題出在CPU節(jié)流。顯然，在預(yù)熱階段，JVM需要比平均穩(wěn)態(tài)更多的CPU時間，但是Kubernetes資源處理機制（CGroup）正在按照配置的限制來限制CPU。
有一種直接的方法可以驗證這一點。 Kubernetes公開了每個容器的度量標(biāo)準(zhǔn) container_cpu_cfs_throttled_seconds_total ，它表示自此容器啟動以來已為它節(jié)流了多少秒的CPU。如果我們在1000m配置下遵守此指標(biāo)，則應(yīng)該在開始時看到很多節(jié)流，然后在幾分鐘后穩(wěn)定下來。我們使用此配置進(jìn)行了部署，這是Prometheus中所有Pod的 container_cpu_cfs_throttled_seconds_total 圖表：
正如預(yù)期的那樣，在容器啟動的前5到7分鐘內(nèi)會有很多節(jié)流--通常在500秒到1000秒之間，但是隨后它穩(wěn)定下來，證實了我們的假設(shè)。
當(dāng)我們使用3000m CPU配置進(jìn)行部署時，我們觀察到下圖：
CPU節(jié)流幾乎可以忽略不計（幾乎所有Pod不到4秒），這就是部署順利進(jìn)行的原因。
盡管我們發(fā)現(xiàn)了造成此問題的瓶頸，但從成本方面來看，該解決方案（增加CPU請求/限制三倍）并不可行。此解決方案實際上可能比運行更多的Pod更糟糕，因為Kubernetes根據(jù)請求調(diào)度Pod，這可能會導(dǎo)致集群自動伸縮器頻繁觸發(fā)，從而向集群添加更多節(jié)點。
再次思考這個問題：
在最初的預(yù)熱階段（持續(xù)幾分鐘），JVM需要比配置的限制（1000m）更多的CPU（?3000m）。預(yù)熱后，即使CPU限制為1000m，JVM也可以充分發(fā)揮其潛力。 Kubernetes使用“請求”而不是“限制”來調(diào)度Pod。
一旦我們以清晰，平靜的心態(tài)閱讀問題陳述，答案就會出現(xiàn)：Kubernetes Burstable QoS。
Kubernetes根據(jù)配置的資源請求和限制將QoS類分配給Pod。
到目前為止，我們一直在通過使用相等值（最初都是1000m，然后都是3000m）指定請求和限制來使用保證的QoS類。盡管QoS保證有其好處，但在整個Pod生命周期的整個周期中，我們不需要3個CPU的全部功能，我們只需要在最初的幾分鐘內(nèi)使用它即可。 Burstable QoS類就是這樣做的。它允許我們指定小于限制的請求，例如
resources: requests: cpu: 1000m memory: 2000Mi limits: cpu: 3000m memory: 2000Mi
由于Kubernetes使用請求中指定的值來調(diào)度Pod，因此它將找到具有1000m備用CPU容量的節(jié)點來調(diào)度此Pod。但是，由于此限制在3000m處要高得多，因此，如果應(yīng)用程序在任何時候都需要超過1000m的CPU，并且該節(jié)點上有可用的CPU備用容量，則不會在CPU上限制應(yīng)用程序。如果可用，它可以使用長達(dá)3000m。
最后，是時候檢驗假設(shè)了。我們更改了資源配置并部署了應(yīng)用程序。而且有效！我們再進(jìn)行了幾次部署，以測試我們是否可以重復(fù)結(jié)果，并且該結(jié)果始終如一。此外，我們監(jiān)控了 container_cpu_cfs_throttled_seconds_total 指標(biāo)，這是其中一種部署的圖表：
如我們所見，此圖與3000m CPU的“保證的QoS”設(shè)置非常相似。節(jié)流幾乎可以忽略不計，它證實了具有Burstable QoS的解決方案有效。
Kubernetes資源限制是一個重要的概念，我們在所有基于Java的服務(wù)中實施了該解決方案，并且部署和自動擴展都可以正常工作，沒有任何問題。
以下三個關(guān)鍵點需要大家注意：
container_cpu_cfs_throttled_seconds_total
感謝各位的閱讀，以上就是“如何優(yōu)化Kubernetes上的JVM Warm-up”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對如何優(yōu)化Kubernetes上的JVM Warm-up這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！
重慶分公司
重慶分公司
