Gunicorn 工作人员在气流 Web 服务器中退出并收到信号：15。关闭 Gunicorn

Question

Gunicorn 工作人员在气流 Web 服务器中退出，并收到信号：15。关闭 Gunicorn。在 kubernetes 上安装 Airflow 时。

调度程序和其他数据库迁移以及用户同步 Pod 运行良好，仅 Web 服务器 Pod 重新启动时出现以下错误。

这里有一些细节：

气流版本：2.6.3 气流图版本：8.8.0 执行器：KubernetesExecutor 气流图像：apache/airflow:2.6.3-python3.10 图表存储库：https://github.com/airflow-helm/charts.git

问题可能是什么，我们只更改了一些配置，例如将 Executor 更改为 KubernetesExecutor 和数据库详细信息。在相同的环境中，气流版本 2.2.3 使用相同的配置。

[2023-09-13 10:48:36 +0000] [46] [INFO] Listening at: https://0.0.0.0:8080 (46)
[2023-09-13 10:48:36 +0000] [46] [INFO] Using worker: sync
[2023-09-13 10:48:36 +0000] [154] [INFO] Booting worker with pid: 154
[2023-09-13 10:48:36 +0000] [155] [INFO] Booting worker with pid: 155
[2023-09-13 10:48:36 +0000] [156] [INFO] Booting worker with pid: 156
[2023-09-13 10:48:36 +0000] [157] [INFO] Booting worker with pid: 157
[2023-09-13 10:49:04 +0000] [157] [INFO] Worker exiting (pid: 157)
[2023-09-13 10:49:04 +0000] [155] [INFO] Worker exiting (pid: 155)
[2023-09-13 10:49:04 +0000] [156] [INFO] Worker exiting (pid: 156)
[2023-09-13 10:49:04 +0000] [154] [INFO] Worker exiting (pid: 154)
[2023-09-13 10:49:04 +0000] [46] [INFO] Handling signal: term
  ____________       _____________
 ____    |__( )_________  __/__  /________      __
____  /| |_  /__  ___/_  /_ __  /_  __ \_ | /| / /
___  ___ |  / _  /   _  __/ _  / / /_/ /_ |/ |/ /
 _/_/  |_/_/  /_/    /_/    /_/  \____/____/|__/
Running the Gunicorn Server with:
Workers: 4 sync
Host: 0.0.0.0:8080
Timeout: 120
Logfiles: - -
Access Logformat: 
=================================================================
[2023-09-13T10:49:04.697+0000] {webserver_command.py:432} INFO - Received signal: 15. Closing gunicorn.
[2023-09-13 10:49:07 +0000] [46] [INFO] Shutting down: Master

问题可能是什么，我们只更改了一些配置，例如将 Executor 更改为 KubernetesExecutor 和数据库详细信息。在相同的环境中，气流版本 2.2.3 使用相同的配置。

Answer 1

我也遇到了同样的问题。

所有镜像已更新至2.7.3-python3.8

为资源添加了 7Gi 内存，并增加了 Liveness 的initialDelaySeconds。

Answer 2

我遇到了同样的问题，但使用的是 Apache 的 Airflow Helm Chart（Airflow 2.8.2 和 Chart 1.3.0）。我在开发部署中随机出现此问题，但在生产部署中却没有。我相信这个问题与 Kubernetes 杀死 Webserver pod 有关，因为它未通过活性检查，就像这里提到的。

Apache 的 Airflow Helm Chart 在 Webserver pod 上有一个 Kubernetes Startup Probe，这样 Kubernetes 就不会在 pod 仍在启动时启动活性检查，然后删除该 pod，因为它由于仍处于启动状态而未能通过检查。启动过程。对于我的开发部署，我必须增加启动探针的延迟，以便 Webserver pod 在活动检查开始之前有更多时间启动。

我不相信社区图表包含启动探针，因此在网络服务器容器的

spec.containers

下，您可以添加：

spec:
  containers:
    - startupProbe:
         failureThreshold: 30
         httpGet:
           path: /health
           port: 8080
           scheme: HTTP
         periodSeconds: 10
         successThreshold: 1
         timeoutSeconds: 20

periodSeconds 将乘以 failureThreshold 以确定启动探针将延迟活性检查多少秒。这里是 300 秒。