K8s环境下Airflow DAG接收SIGTERM问题排查求助

在Kubernetes环境中运行一个需多次调用API（该API从数据库获取数据）的Airflow DAG，调用数次后DAG返回SIGTERM错误。已排查API日志未发现异常，通过Grafana确认Pod及节点的CPU、内存均在限制范围内，需定位该SIGTERM的来源及排查方向。

已排查情况 #

• API服务日志无异常，调用逻辑本身未报错
• 通过Grafana监控确认Pod及节点的CPU、内存使用率均在配置的限制范围内

错误日志 #

[2024-06-29, 23:46:39 UTC] {local_task_job_runner.py:115} ERROR - 收到SIGTERM信号，正在终止子进程
[2024-06-29, 23:46:39 UTC] {process_utils.py:131} INFO - 向进程组28发送信号15，该组所有进程PID：[28]
[2024-06-29, 23:46:39 UTC] {process_utils.py:86} INFO - 向进程组28发送信号15
[2024-06-29, 23:46:39 UTC] {taskinstance.py:1630} ERROR - 收到SIGTERM信号，正在终止子进程
[2024-06-29, 23:46:39 UTC] {test_driver_airflow.py:648} WARNING - 正在重试测试
[2024-06-29, 23:47:39 UTC] {process_utils.py:149} WARNING - 进程psutil.Process(pid=28, name='airflow task runner:test test manual__2024-06-21T11:04:44+00:00 11476', status='sleeping', started='18:36:37') 未响应SIGTERM，尝试发送SIGKILL
[2024-06-29, 23:47:39 UTC] {process_utils.py:86} INFO - 向进程组28发送信号9
[2024-06-29, 23:47:39 UTC] {process_utils.py:79} INFO - 进程psutil.Process(pid=28, name='airflow task runner: test test manual__2024-06-21T11:04:44+00:00 11476', status='terminated', exitcode=<Negsignal.SIGKILL: -9>, started='18:36:37') (28) 已终止，退出码-9
[2024-06-29, 23:47:39 UTC] {standard_task_runner.py:172} ERROR - 任务11476未完成即被终止（可能是内存不足）
[2024-06-29, 23:47:39 UTC] {local_task_job_runner.py:228} INFO - 任务退出，返回码143

SIGTERM来源分析及排查方向 #

来源分析 #

1. Kubernetes Pod驱逐/资源压力：虽然监控显示内存在限制内，但可能存在瞬时内存尖峰未被捕捉，或节点磁盘IO、网络带宽耗尽触发驱逐；另外Pod的终止宽限期设置过短，可能导致任务未处理完就被强制终止。
2. Airflow任务超时机制：DAG或Task配置的execution_timeout可能过短，任务运行时间超出限制后Airflow主动发送SIGTERM；Scheduler或Worker的生命周期配置也可能触发任务终止。
3. 进程阻塞导致信号处理失效：日志显示进程收到SIGTERM后无响应，最后被SIGKILL，说明任务进程可能在API调用时进入不可中断阻塞状态（如网络IO卡住、数据库连接未释放），无法处理终止信号。
4. 资源限制细节遗漏：Pod的requests设置过低，节点内存碎片化可能触发OOM Killer；另外CPU节流、文件句柄数限制等非内存资源也可能导致进程异常。

排查方向 #

• 查看Kubernetes事件：执行kubectl describe pod <目标Pod名称>或kubectl get events，检查是否有Pod驱逐、节点资源压力相关事件。
• 增强任务日志粒度：在DAG代码中添加详细日志，记录每次API调用的时间、请求参数、返回状态，定位是否某一次调用后进程卡住。
• 检查Airflow配置：确认core.dag_run_timeout、core.task_execution_timeout等超时参数，以及Worker的worker_timeout、worker_autoscale配置是否合理。
• 监控进程级资源：在Pod内实时查看进程资源占用（如top -p <进程PID>），或配置cAdvisor监控进程级资源变化，捕捉瞬时异常。
• 单独测试API调用逻辑：模拟任务中的API循环调用场景，排查是否客户端存在连接泄漏、资源未释放等问题。
• 检查Pod终止流程：查看Airflow Worker Pod的preStop钩子配置，确认是否有自定义逻辑干扰信号处理。

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