背景

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

本文就此問題介紹了Linux內存不足原因以及為什么特定進程會被殺死。并提供了Kubernetes集群環境故障排除指南教程。

tomcat進程被殺死原因分析

當這個應用程序被kill問題進行故障排除時，很大程度上確定是操作系統殺死的， 因為整個過程確認沒有進行kill操作。當我查看tomcat日志時發現，tomcat只是簡單的提示了killd， 至于原因， 日志中沒有給出詳盡的提示。緊接著我查看了syslog日志grep -i kill /var/log/messages*， syslog給出比較詳細的提示， 大概意思是該應用占用內存超過cgroup限制， 直接被Kill。如下所示:

Oct 1 20:37:21 k8swork kernel: Memory cgroup out of memory: Kill process 13547 (java) score 1273 or sacrifice child

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

[root@k8swork log]# free -lm
             total       used       free     shared    buffers     cached
Mem:           498         93        405          0         15         32
Low:           498         93        405
High:            0          0          0
-/+ buffers/cache:         44        453
Swap:         1023          0       1023

但是Linux vmstat可以使用以下命令將的輸出重定向到文件。我們甚至可以調整持續時間和次數以監控更長的時間。當命令運行時，我們可以隨時查看輸出文件以查看結果。我們每120秒查看內存1000次。該&行末尾的允許我們將其作為一個進程運行并重新獲得終端。

vmstat -SM 120 1000 > 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證書過期問題 它不僅詳細介紹了整個故障排除和解決方式， 另外給出了集群環境證書認證體系流程介紹， 非常贊!