是谁杀死了kube-apiserver

问题描述

组里大佬联系我，客户k8s环境无法部署hadoop等大数据应用组件，每次服务刚起来，进程就被杀死了。

调查

登录客户系统以后，首先查看了集群状态，kubectl get pods -n kube-apiserver。
发现apiserver 也一直在重启的过程中，而且重启成功没多久，也同样被杀死。和同事形容的业务进程hadoop的表现相同。

首先想到用strace判断一下，进程是因何被杀死的。
登录kube-apiserver所在节点，并使用如下命令，查询kube-apiserver进程号

[root@sphere32-master-1 ~]# ps -ef|grep kube-apiserver|grep -v 'color'|awk '{print $2}'
9485

使用strace命令监听，进程因何被杀死

[root@sphere32-master-1 ~]# strace -p 9485

发现strace最后输出 killed by SIGKILL，证明kube-apiserver是接收到了SIGKILL信号，并推出的。SIGKILL信号的特点是无法被进程捕获，进程无法做善后的操作就退出了，执行kill -9就是发送的SIGKILL信号。通常来说SIGKILL信号不是进程本身发出的，也就是说有另外一个进程发送了SIGKILL杀死了kube-apiserver。

下面就该想办法揪出杀死kube-apiserver的凶手
在https://stackoverflow.com/questions/26285133/who-sends-a-sigkill-to-my-process-mysteriously-on-ubuntu-server中，提到了简单的方法来找到发出信号的进程，那就是使用audit

安装很简单：

sudo apt-get install auditd

启动服务并查看状态：

service auditd start & service auditd status

然后通过auditctrl添加规则：

auditctl -a exit,always -F arch=b64 -S kill -F a1=9

下面用一个python进程做实验，启动并杀死进程

$ python run_forever.py &[1] 24067$ kill -9 24067

time->Mon Dec 25 19:52:55 2017type=PROCTITLE msg=audit(1514202775.088:351): proctitle="bash"type=OBJ_PID msg=audit(1514202775.088:351): opid=24067 日uid=-1 ouid=3010 oses=-1 ocomm="python"type=SYSCALL msg=audit(1514202775.088:351): arch=c000003e syscall=62 success=yes exit=0 a0=5e03 a1=9 a2=0 a3=7ffc0d9f7b90 items=0 ppid=1349 pid=1350  uid=3010 gid=3010 euid=3010 suid=3010 fsuid=3010 egid=3010 sgid=3010 fsgid=3010 tty=pts0 comm="bash" exe="/bin/bash" key=(null)

可以看到，信号的目标进程是一个python程序，pid是24067，启动该进程的用户的id是3010。kil进程的信号被用户3010在pid为1350的bash中发出。

使用以上方法，在生产机器上进行了监控，发现杀死kube-apiserver的是一个bash脚本。且查询这个脚本的进程id时，脚本已经结束，进程id不存在了。大佬提醒可能是有定时任务在定期执行。使用crontab -l果然找到了一个定时任务。

crontab -l

并且使用top命令的时候，看到有一个名为python的进程cpu使用率异常的高。
种种表现都和这篇文章中讲的挖矿木马相似
https://blog.sciencenet.cn/blog-3379275-1289743.html

结论

最终结论是生产机器中了挖矿木马。木马首先会占用整个服务器一半的cpu，同时会定期清理其他cpu占用超过1核的进程。找到原因后就交给运维处理了……