google-kubernetes-engine - 由于主机名不匹配，长时间运行的 Airflow 任务被错误地标记为失败

Question

我有一个长时间运行的 Cloud Composer Airflow 任务，它使用 KubernetesPodOperator 启 Action 业。有时，它会在大约两个小时后成功完成，但更常见的是，它会被标记为失败，并在 Airflow 工作日志中显示以下错误:

[2019-06-24 18:49:34,718] {jobs.py:2685} WARNING - The recorded hostname airflow-worker-xxxxxxxxxx-aaaaa does not match this instance's hostname airflow-worker-xxxxxxxxxx-bbbbb
Traceback (most recent call last):
  File "/usr/local/bin/airflow", line 7, in <module>
    exec(compile(f.read(), __file__, 'exec'))
...

  File "/usr/local/lib/airflow/airflow/jobs.py", line 2686, in heartbeat_callback
    raise AirflowException("Hostname of job runner does not match")
airflow.exceptions.AirflowException: Hostname of job runner does not match

任务被标记为失败后，实际的 KubernetesPodOperator 作业仍然成功完成，没有任何错误。日志中引用的两个工作线程 airflow-worker-xxxxxxxxxx-aaaaa 和 airflow-worker-xxxxxxxxxx-bbbbb 仍然正常运行。

这个Airflow PR使得覆盖主机名成为可能，但我无法判断在这种情况下这是否是合适的解决方案，因为在任务运行期间似乎没有一个工作人员死亡或发生变化。将正在运行的任务重新分配给不同的工作人员是否正常？如果是这样，为什么Airflow source如果主机名不匹配，任务会失败吗？

Answer 1

我认为根本原因可能是已知的 Airflow 问题，该问题使调度程序在一段时间后尝试重新交付任务。如果任务转到其他工作人员，任务的主机名将更新为新的工作人员，如果前一个工作人员完成任务，主机名将不同并且会出现错误。如果集群很忙(考虑到任务很可能需要 2 个小时)，您的任务可能会排队很长时间才能被工作人员接收。

一些可以解决这个问题的想法:

• 增加 visibility_timeout
• 增加worker_concurrency，以便工作线程可以处理更多任务
• 增加节点数量以拥有更多工作人员

无论如何，在不检查日志和环境的情况下解决这个问题有点困难，所以如果这种情况仍然发生，请随时联系GCP support .