背景

最近線上環境上出現了一個問題， k8s叢集環境Pod中的tomcat容器執行一段時間後直接被killd，但有時一切看起來正常，不能準確判斷在什麼時機出現被Killd問題。

本文就此問題介紹了Linux記憶體不足原因以及為什麼特定程序會被殺死。並提供了Kubernetes叢集環境故障排除指南教程。

tomcat程序被殺死原因分析

當這個應用程式被kill問題進行故障排除時，很大程度上確定是作業系統殺死的， 因為整個過程確認沒有進行kill操作。當我檢視tomcat日誌時發現，tomcat只是簡單的提示了killd， 至於原因， 日誌中沒有給出詳盡的提示。緊接著我查看了syslog日誌grep -i kill /var/log/messages*

Oct120:37:21k8sworkkernel:Memorycgroupoutofmemory:Killprocess13547(java)score1273orsacrificechild

如果當服務已經掛掉， 使用free檢視記憶體佔用， 對我們排除問題不會有太大幫助， 因為這個時候服務佔用記憶體已經隨著服務的掛掉而釋放。如下所示:

[root@k8sworklog]#free-lm
totalusedfreesharedbufferscached
Mem:4989340501532
Low:49893405
High:000
-/+buffers/cache:44453
Swap:102301023
 

但是Linux vmstat可以使用以下命令將的輸出重定向到檔案。我們甚至可以調整持續時間和次數以監控更長的時間。當命令執行時，我們可以隨時檢視輸出檔案以檢視結果。我們每120秒檢視記憶體1000次。該&行末尾的允許我們將其作為一個程序執行並重新獲得終端。

vmstat-SM1201000>memoryuse.out&

通過如上資訊可以判定罪魁禍首是這個Java程序佔用記憶體超過資源限制， 直接被系統殺死。為什麼會出現這個問題呢?

首先第一點，已經在編排檔案中限制資源最大使用量為4G，理論上Pod中容器是不可能佔用這麼多資源， 預設情況下Java佔用物理資源的1/4左右， 但是既然出現了這個問題，說明Java程序佔用資源超過了這個限制。

於是在網上找到了如下資訊，大概意思是說，jdk從131版本之後開始通過選項支援對容器對記憶體和CPU 的限制，如下圖所示:

當我開啟131版本更新資訊之後，沒有看到任何關於容器相關的更新， 於是開始查詢之後的版本， 最後找到191版本， 可以看到Java對容器做出了支援。

核對了目前出現問題的Java版本， 明顯是低於這個版本的， 確定了問題所在。

“

Java虛擬機器感知不到Pod中資源限制，所以直接佔用了宿主機1/4左右記憶體(宿主機是32G記憶體)， cgroup檢測到Pod佔用記憶體超過限制(Pod限制為4G)，進行了Kill操作。

”

解決方式也很簡單，直接在tomcat服務中配置最大最小記憶體佔用， 在Java層面限制其記憶體佔用。但是具體Java程序為什麼佔用這麼高的記憶體就需要業務開發人員排查解決了。

總結

通過本文可以看出基於Java虛擬機器構建專案， 在容器化過程中要儘量適配高版本或者對docker容器有親和性的Jdk版本， 如果沒有， 一定要在虛擬機器層面限制Java服務佔用記憶體大小。另外一定要在服務上新增存活探針，如果沒有新增存活探針，類似於tomcat這種容器類服務，即使內部服務掛了了， Kubernetes不會自動幫你拉起的，原因很簡單，它無法感知到你的服務是否存活。所以服務一定要新增Http存活探針(基於TCP層面的探針只是檢測埠是否存活，大多數情況下，服務會出現假死問題，但埠依然可以正常訪問)。

問題故障排查指南教程推薦

首先這本書是阿里雲同學總結的<<深入淺出Kubernetes>>， 裡面不僅用通俗易懂語言介紹了Kubernetes核心概念， 而且介紹了Kubernetes叢集出現問題解決思路，值得借鑑。比如其中一個案例半夜兩點Ca證書過期問題它不僅詳細介紹了整個故障排除和解決方式， 另外給出了叢集環境證書認證體系流程介紹， 非常贊!

如果需要請在公眾號後臺回覆[k8s]獲取下載地址。

推薦

雲原生時代Java面臨的不適與挑戰

Kubernetes入門培訓（內含PPT）

從Ice到Kubernetes容器技術，微服務架構經歷了什麼？

原創不易，隨手關注或者”在看“，誠摯感謝！

本文分享自微信公眾號 - 雲原生技術愛好者社群（programmer_java）。
如有侵權，請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。

來源：金門一日遊多少錢