IBM Cloud Kubernetes集群发送kill信号终止MongoDB Pod的原因

用户场景：在IBM Cloud上新建Kubernetes集群，仅部署MongoDB应用，Pod启动就绪可连接后，收到kill信号终止，日志如下：

{"t":{"$date":"2022-11-22T12:39:03.999+00:00"},"s":"I",  "c":"CONTROL",  "id":23378,   "ctx":"SignalHandler","msg":"Signal was sent by kill(2)","attr":{"pid":0,"uid":0}}
{"t":{"$date":"2022-11-22T12:39:03.999+00:00"},"s":"I",  "c":"CONTROL",  "id":23381,   "ctx":"SignalHandler","msg":"will terminate after current cmd ends"}

日志中uid:0说明kill信号由root用户发送，结合Kubernetes环境，大概率是kubelet或集群层面的操作触发，以下是常见原因及排查方向：

可能原因 #

1. 资源不足触发OOMKilled #

MongoDB对内存需求较高，若Pod未配置足够的资源请求/限制，或节点剩余资源不足，kubelet会因内存压力发送kill信号终止Pod。

• 排查：执行kubectl describe pod <mongodb-pod-name>，查看Events中是否有OOMKilled记录；查看Pod资源配置：kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].resources}'。

2. 存活/就绪探针失败 #

若部署中配置了Liveness/Readiness探针，当探针检测失败次数超过阈值，kubelet会重启Pod并发送kill信号。

• 排查：检查部署yaml中的探针配置，确认initialDelaySeconds是否足够MongoDB完成初始化，探针执行命令（如mongosh --eval "db.adminCommand('ping')"）是否能正常执行；查看Pod Events中的探针失败记录。

3. 节点维护或自动缩放操作 #

IBM Cloud Kubernetes集群会定期进行节点维护（如系统更新），或开启Cluster Autoscaler后触发节点缩容，此时kubelet会驱逐Pod并发送kill信号。

• 排查：执行kubectl get nodes -o wide查看节点状态，是否有节点处于NotReady或正在被删除；登录IBM Cloud控制台查看集群事件记录，确认是否有节点维护、缩容操作。

4. Kubelet配置或版本兼容性问题 #

新搭建的集群可能存在kubelet配置错误，或Kubernetes版本与MongoDB镜像版本不兼容，导致kubelet异常终止Pod。

• 排查：查看kubelet日志：kubectl logs -n kube-system kubelet-<node-name>，搜索与目标Pod相关的错误信息；确认MongoDB镜像版本与集群K8s版本的兼容性。

快速排查步骤 #

1. 优先查看Pod事件：kubectl describe pod <mongodb-pod-name>，定位直接触发终止的原因；
2. 检查Pod资源配置，确保内存/CPU配额满足MongoDB运行需求；
3. 验证探针配置的合理性，调整初始化延迟时间或检测命令；
4. 确认集群节点是否有维护、缩容等操作记录。

内容的提问来源于stack exchange，提问作者Zheng Xie