我正在使用带有 composer (GCP) 的气流从云 sql 中提取数据以用于 gcs，在 gcs 用于 bigquery 之后，我有一些介于 100 Mb 和 10 Gb 之间的表。我的 dag 有两个任务要做我之前提到的事情。对于较小的表，dag 运行顺利，但对于稍微大一点的表，云 sql 提取任务会在几秒钟内结束，但失败，但除了“negsignal.sigkill”之外没有带来任何日志，我已经尝试增加作曲家的容量，除其他外，但还没有任何效果。 我正在使用 mysql_to_gcs 和 gcs_to_bigquery 运算符
【问题讨论】：
标签： google-cloud-composer airflow
当您收到negsinal.SIGKILL 时，首先应该检查的是您的 Kubernetes 资源。这肯定是资源限制的问题。
我认为您应该监控您的 Kubernetes 集群节点。在 GCP 中，转到 Kubernetes Engine > 集群。您应该有一个包含 Cloud Composer 使用的环境的集群。
现在，前往集群的节点。每个节点都为您提供有关 CPU、内存和磁盘使用情况的指标。您还将看到每个节点使用的资源的限制。此外，您将看到每个节点具有的 pod。
如果你对 K8s 不是很熟悉，让我简单解释一下。 Airflow 在节点内使用 Pod 来运行您的 Airflow 任务。这些 pod 被称为 airflow-worker-[id]。这样您就可以识别 Node 内的工作 pod。
检查您的 pod 列表。如果您有驱逐气流工作者 pod，那么 Kubernetes 会出于某种原因停止您的工作者。由于 Composer 使用 CeleryExecutor，被驱逐的气流工作人员指出了一个问题。如果您使用 KubernetesExecutor，则情况并非如此，但 Composer 中尚不可用。
如果您点击某个被驱逐的 pod，您将看到驱逐的原因。那应该会给你答案。
如果您的 pod 驱逐没有问题，请不要惊慌，您还有一些选择。从那时起，你最好的朋友就是日志。请务必按顺序检查您的 pod 日志、节点日志和集群日志。
【讨论】：