運維攻堅之kubernetes pod無端重啓問題排查

背景

某項目kubernetes環境某個應用每隔20分鐘左右就會重啓一次，時間不固定，但在容器事件裏面沒有任何記錄。

排查

首先懷疑是健康檢查沒過致使容器自動重啓，如下是健康檢查的配置

按照該配置，檢查間隔30s，不健康閾值60，也就是1800s=30分鐘後會標記爲不健康，但很快就排除該猜想，理由是

• 手動調用健康檢查是ok的
• 後臺有健康檢查的記錄，記錄顯示也都是經過的
• 若是是健康檢查不過的話，事件裏面會有記錄，這裏找不到記錄

正常狀況下若是kubernetes重啓pod那會在事件裏記錄重啓的緣由，但事件裏面沒有任何記錄，因此可能不是kubernetes重啓的，那麼很容易想到一個可能性就是OOM，也就是進程由於內存使用超過限制觸發OOM操做系統將其kill掉，查看操做系統日誌/var/log/messages發現如下日誌

May 11 15:01:36 k8s-node-prod-3 kernel: [17094.020710]  oom_kill_process.cold.30+0xb/0x1cf
May 11 15:01:36 k8s-node-prod-3 kernel: [17094.020788] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
May 11 15:01:36 k8s-node-prod-3 kernel: [17094.109707] oom_reaper: reaped process 25929 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
May 11 15:29:12 k8s-node-prod-3 kernel: [18750.337581] java invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=969
May 11 15:29:12 k8s-node-prod-3 kernel: [18750.337621]  oom_kill_process.cold.30+0xb/0x1cf
May 11 15:29:12 k8s-node-prod-3 kernel: [18750.337709] [  pid  ]   uid  tgid total_

果真有OOM的記錄，並且幾回kill的事件也正符合應用重啓的時間，再查看其餘java進程的oom_score，居然高達1000多有很大風險會被再次kill掉，所以罪魁禍首就是OOM，那爲何會致使OOM呢，此時操做系統的剩餘內存仍是很充足，注意到容器應用的啓動參數配置的內存是4096M

JAVA_OPTS="$JAVA_OPTS -server -Xms4096M -Xmx4096M -Xss512k ..."

而容器給的內存限額是4500M，也就是說一臺4500M的主機運行了一臺須要4096M的程序，程序佔了大比例主機內存，固然很容易被系統kill掉

OOM killer是Linux內核的一個特性，會檢查佔用內存過大的進程將其殺掉，操做系統會根據進程的內存使用狀況打分，分數保存在/proc/{進程PID}/oom_score中，分數越大越容易被kill掉

解決

由於在啓動命令裏限制了內存，就不必在kubernetes上再對內存進行限制，所以去掉kubernetes的內存限制問題解決。

經驗總結

問題雖小，但形成的影響很是大，由於該客戶爲跨國集團，業務涉及多個國家，所以全天的交易量都很是大，從該問題能夠總結如下經驗

• 若是kubernetes沒有事件記錄，極可能是操做系統級別的問題，應該從操做系統入手排查
• 實踐纔是檢驗真理的惟一標準，在出事以前，全部人都以爲這麼配置很合理，都沒想到會被OOM，出了問題才煥然大悟