今天這篇文章探討的是 JVM 於 Kubernetes 下的使用經驗，對於基於 JVM 的應用程式來說，其需要一點暖身時間，暖身完畢以前，這些應用程式沒有辦法發揮百分百的能力去處理流量與請求，這樣的概念導入到 Kubernetes 後就會使得事情惡化。當今天發現過多流量近來，需要動態產生新的 Pod 來分攤流量，然而這些 Pod 都還在慢慢暖身，這些暖身過程會導致對應的請求時間變得非常長，甚至 timeout。

因此作者要跟大家分享他們團隊是怎麼處理這個問題，嘗試過哪些手段，哪些有效，哪些無效以及這些過程中到底學到了什麼

1. 第一次遇到這個問題時，團隊沒有太多心力去研究，當下解法就是，那我就開更多的 Pod，繼續降低每個 Pod 可能要負責的請求數量 (RRM)。經過團隊測試，這種方式奏效但是帶來的資源浪費的問題，團隊最後部署的資源量是真正理想情況下的三倍之多，這意味者用三倍的金錢，來處理一倍的請求量。

2. 階段二中，團隊打算嘗試增加一個 Warm-up 的腳本去發送一些流量，期盼這種機制可以加速暖身機制。該做法同時也要修改 Readiness 來確保 Warm-up 完成前 Readiness 不會讓真實流量封包導入到 Pod裡面。結果來說，是個不管用的效果，有一點點的長進，但是帶來更多的問題，譬如一個 Pod要花三分鐘 才可以起來，結論就是弊大於利

3. 階段三中，決定從 JVM 本身開始研究起，發現提升 CPU 的資源量可以明顯地縮短暖身時間，讓這些 Pod 可以更快的加入戰場服務。根據作者團隊的觀察，過往使用 1000m 的 CPU 使用量，大概需要 5-7 分鐘的暖身時間，透過將 CPU 使用量提升到 3000m，能夠將整體時間縮短不到 4 秒，效果顯著。因此提升 CPU 使用量就是一個可行的解決方案。 然而因為過往採用的是 Guareanteed Class 的 QoS 設定 (limited == request)，這樣 3000m 的CPU 使用量反而會造成資源浪費，最後造成節點不夠觸發自動新增節點的機制，然後花更多的錢

4. 重新探索 CPU Resource 的用法，決定採取 Burstable Class 的概念，針對 Limit 設定 3000m, request 則是 1000m，這樣可以確保 Schedule 時會用 1000m 來找資源，系統上有足夠 CPU 時也可以讓 JVM 使用到 3000m.

詳細內容請參考下列全文:
原文: https://tech.olx.com/improving-jvm-warm-up-on-kubernetes-1b27dd8ecd58