背景
前段時間業務研發反饋說是他的應用記憶體使用率很高，導致頻繁的重啟，讓我排查下是怎麼回事；
在這之前我也沒怎麼在意過這個問題，正好這次排查分析的過程做一個記錄。
首先我檢視了監控皮膚裡的 Pod 監控：
發現確實是快滿了，而此時去檢視應用的 JVM 佔用情況卻只有30%左右；說明並不是應用記憶體滿了導致 JVM 的 OOM，而是 Pod 的記憶體滿了，導致 Pod 的記憶體溢位，從而被 k8s 殺掉了。
而 k8s 為了維持應用的副本數量就得重啟一個 Pod，所以看起來就是應用執行一段時間後就被重啟。
而這個應用配置的是 JVM 8G，容器申請的記憶體是16G，所以 Pod 的記憶體佔用看起來也就 50% 左右。
容器的原理
在解決這個問題之前還是先簡單瞭解下容器的執行原理，因為在 k8s 中所有的應用都是執行在容器中的，而容器本質上也是執行在宿主機上的一個個經常而已。
但我們使用 Docker 的時候會感覺每個容器啟動的應用之間互不干擾，從檔案系統、網路、CPU、記憶體這些都能完全隔離開來，就像兩個執行在不同的伺服器中的應用。
其實這一點也不是啥黑科技，Linux 早就支援 2.6.x 的版本就已經支援 namespace 隔離了，使用 namespace 可以將兩個程式完全隔離。
僅僅將資源隔離還不夠，還需要限制對資源的使用，比如 CPU、記憶體、磁碟、頻寬這些也得做限制；這點也可以使用 cgroups 進行配置。
它可以限制某個程式的資源，比如宿主機是 4 核 CPU，8G 記憶體，為了保護其他容器，必須給這個容器配置使用上限：1核 CPU，2G記憶體。
這張圖就很清晰的表示了 namespace 和 cgroups 在容器技術中的作用，簡單來說就是：
- namespace 負責隔離
- cgroups 負責限制
在 k8s 中也有對應的提現：
resources:
requests:
memory: 1024Mi
cpu: 0.1
limits:
memory: 1024Mi
cpu: 4這個資源清單表示該應用至少需要為一個容器分配一個 0.1 核和 1024M 的資源，CPU 的最高上限為 4 個核心。
不同的OOM
回到本次的問題，可以確認是容器發生了 OOM 從而導致被 k8s 重啟，這也是我們配置 limits 的作用。
k8s 記憶體溢位導致容器退出會出現 exit code 137 的一個 event 日誌。
因為該應用的 JVM 記憶體配置和容器的配置大小是一樣的，都是8GB，但 Java 應用還有一些非 JVM 管理的記憶體，比如堆外記憶體之類的，這樣很容易就導致容器記憶體大小超過了限制的 8G 了，也就導致了容器記憶體溢位。
雲原生背景的最佳化
因為這個應用本身使用的記憶體不多，所以建議將堆記憶體限制到 4GB，這樣就避免了容器記憶體超限，從而解決了問題。
當然之後我們也會在應用配置欄里加上建議：推薦 JVM 的配置小於容器限制的 2/3，預留一些記憶體。
其實本質上還是開發模式沒有轉變過來，以傳統的 Java 應用開發模式甚至都不會去了解容器的記憶體大小，因為以前大家的應用都是部署在一個記憶體較大的虛擬機器上，所以感知不到容器記憶體的限制。
從而誤以為將兩者畫了等號，這一點可能在 Java 應用中尤為明顯，畢竟多了一個 JVM；甚至在老版本的 JDK 中如果沒有設定堆記憶體大小，無法感知到容器的記憶體限制，從而自動生成的 Xmx 大於了容器的記憶體大小，以致於 OOM。