关于kubernetes:运维攻坚之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，出了问题才焕然大悟