排查Kubelet向Pod发送SIGTERM信号的未知原因

1. 深挖Pod的终止细节 #

• 用kubectl get pod <pod-name> -n <namespace> -o json查看Pod完整状态，重点关注status.reason、status.message、status.terminated字段，这里会记录终止的直接原因（比如Evicted、NodeShutdown等）
• 执行kubectl get events -n <namespace> --sort-by='.metadata.creationTimestamp'，按时间顺序遍历Namespace下所有事件，可能发现kubectl describe pod遗漏的前置触发记录（比如节点资源预警、滚动更新启动日志）

2. 查看节点Kubelet日志 #

Kubelet是发送SIGTERM的核心组件，直接查看节点日志能获取最直接的触发逻辑：

• 通过kubectl get pod <pod-name> -n <namespace> -o wide获取Pod所在节点名，登录该节点
• 执行journalctl -u kubelet -f（systemd环境）或查看/var/log/kubelet.log，搜索Pod名称/UID，会找到发送SIGTERM的具体原因（比如节点资源压力触发驱逐、滚动更新指令、节点维护迁移）

3. 检查容器运行时日志 #

容器运行时会记录容器终止的底层细节：

• 若使用containerd：先通过crictl ps -a找到对应容器ID，再执行crictl logs <container-id>，或查看/var/log/containerd/containerd.log
• 若使用Docker：执行docker logs <container-id>，或查看/var/log/docker.log

4. 排查控制器层面的触发因素 #

Pod终止常由上层控制器触发，需检查对应控制器的事件和配置：

• 针对Deployment/StatefulSet：执行kubectl describe deployment <deploy-name> -n <namespace>查看滚动更新记录；用kubectl rollout history deployment <deploy-name> -n <namespace>确认更新历史
• 针对DaemonSet/Job/CronJob：查看控制器的事件和状态，确认是否有调度或执行逻辑导致Pod终止
• 检查HPA（水平Pod自动扩缩容）：执行kubectl describe hpa <hpa-name> -n <namespace>，确认是否触发了缩容操作

5. 检查节点层面异常 #

• 查看节点状态：kubectl describe node <node-name>，确认是否存在MemoryPressure、DiskPressure、PIDPressure或NotReady状态，这些都会触发Kubelet驱逐Pod
• 查看节点系统日志：journalctl -xe，检查是否有节点重启、硬件故障、资源耗尽等异常记录

6. 其他排查方向 #

• 检查Pod的preStop钩子配置：若定义了该钩子，可能是钩子执行异常导致提前触发终止，需查看钩子执行日志
• 确认是否有运维操作触发：比如手动执行kubectl delete pod、kubectl rollout restart等，可通过集群审计日志（若开启）查看操作记录
• 检查Namespace资源配额：kubectl describe resourcequota <quota-name> -n <namespace>，确认是否因CPU/内存配额不足导致Pod被终止

内容的提问来源于stack exchange，提问作者Prabath M