已知问题

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

本页面列出了已知的 Cloud Composer 问题。正在针对这些问题进行一些修复,并将在未来版本中提供。

有些问题会影响旧版本,您可以通过升级环境来解决。

Pod 和服务部分支持非 RFC 1918 地址范围

Cloud Composer 依赖 GKE 为 Pod 和服务提供对非 RFC 1918 地址的支持。目前,Cloud Composer 仅支持以下非 RFC 1918 范围列表:

  • 100.64.0.0/10
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 240.0.0.0/4

在 Composer 1.10.2 和 Composer 1.10.3 中启用 DAG 序列化时,Airflow 界面不显示任务日志

在使用 Composer 版本 1.10.2 和 1.10.3 的环境中启用 DAG 序列化时,可防止日志显示在 Airflow 网络服务器上。要解决此问题,请升级到版本 1.10.4(或更高版本)。

在 Cloud Composer 中安排期间出现间歇性任务失败

在任务执行期间,该问题出现在任务实例的 Airflow 调度器中。但是,日志没有说明任务失败的原因,并且 Airflow 工作器和 Airflow 调度器看起来运行状况相对良好。

Airflow 调度器上的错误消息可能类似于以下错误:

Executor reports task instance <TaskInstance: xx.xxxx scheduled__2022-04-21T06:00:00+00:00 [queued]> finished (failed) although the task says its queued. (Info: None) Was the task killed externally?

或者,Airflow 工作器上可能存在一些类似以下错误的错误:

Log file is not found: gs://$BUCKET_NAME/logs/$DAG_NAME/$TASK_NAME/2023-01-25T05:01:17.044759+00:00/1.log.
The task might not have been executed or worker executing it might have finished abnormally (e.g. was evicted).

为确保稳健性能够防范源自 Airflow 的长期问题的各种错误,强烈建议您在任务和 DAG 级别主动实施适当的重试策略。通过结合这些措施,系统可以有效地减轻这些错误的影响,从而提高工作流的整体可靠性和弹性。

不支持 GKE Workload Identity

此问题仅适用于 Cloud Composer 1 环境。Cloud Composer 2 环境使用 Workload Identity。

您无法为 Cloud Composer 环境集群启用 Workload Identity。因此,您可能会在 Security Command Center 中看到 WORKLOAD_IDENTITY_DISABLED 发现结果。

更新期间添加的环境标签不会完全传播

更新后的环境标签不会应用于 Compute Engine 虚拟机。解决方法之一是,您可以手动应用这些标签。

发生 CVE-2020-14386 问题时的 GKE 升级

我们正努力修复所有 Cloud Composer 环境的 CVE-2020-14386 漏洞。作为此修复的一部分,所有现有 Cloud Composer 的 GKE 集群都将更新到较新版本。

决定立即解决此漏洞的客户可以按照这些说明升级 Composer GKE 集群,但需要注意以下事项:

第 1 步:如果您运行的 Cloud Composer 版本低于 1.7.2,请升级到更高版本的 Cloud Composer。如果您已使用 1.7.2 或更高版本,请转到下一个点。

第 2 步:将 GKE 集群(主服务器和节点)升级到包含此漏洞修复的最新 1.15 补丁程序版本。

从 Airflow 1.9.0 升级到 Airflow 1.10.x 之后,Airflow 任务日志将在 Airflow 网络服务器中不可用

Airflow 1.10.x 对日志文件的命名惯例引入了向后不兼容的更改。可用区信息现在已添加到 Airflow 任务的日志名称中。

Airflow 1.9.0 会存储日志名称,并要求采用以下格式: BUCKET/logs/DAG/2020-03-30T10:29:06/1.log Airflow 1.10.x 会存储日志名称,并要求采用以下格式: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

因此,如果您从 Airflow 1.9.0 升级到 Airflow 1.10.x,并且想要读取使用 Airflow 1.9.0 执行的任务的日志,则 Airflow 网络服务器将显示以下错误消息: Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

解决方法:使用以下格式,重命名 Cloud Storage 存储桶中由 Airflow 1.9.0 生成的日志:BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log

无法创建执行组织政策 constraints/compute.disableSerialPortLogging 的 Cloud Composer 环境

如果对目标项目强制执行 constraints/compute.disableSerialPortLogging,Cloud Composer 环境创建将失败。

诊断

要确定您是否受到此问题影响,请按以下步骤操作:

转到 Google Cloud 控制台中的 GKE 菜单。访问 GKE 菜单

然后,选择新创建的集群。检查是否存在以下错误:

Not all instances running in IGM after 123.45s.
Expect <number of desired instances in IGM>. Current errors:

Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.

解决方法

  1. 在将创建 Cloud Composer 环境的项目中停用组织政策。

    即使父资源(组织或文件夹)启用了组织政策,您也始终可以在项目级层停用组织政策。如需了解详情,请参阅为布尔值限制条件自定义政策页面

  2. 使用排除过滤器

    使用串行端口日志的排除过滤器可以实现与停用组织政策同样的目标,因为 Logging 中将会有串行控制台日志。如需了解详情,请参阅排除过滤器页面。

使用 Deployment Manager 管理受 VPC Service Controls 保护的 Google Cloud 资源

Composer 使用 Deployment Manager 创建 Cloud Composer 环境的组件。

2020 年 12 月,您可能收到相关信息,告知您可能需要执行其他 VPC Service Controls 配置,以便能够使用 Deployment Manager 来管理受 VPC Service Controls 保护的资源。

谨在此澄清,如果您使用的是 Composer 并且直接使用 Deployment Manager 来管理 Deployment Manager 公告中提及的 Google Cloud 资源,则无需执行任何操作

在环境的 GKE 集群被删除后无法删除环境

如果您在删除环境之前删除环境的集群,则尝试删除环境会导致以下错误:

 Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]

如需删除其 GKE 集群已被删除的环境,请执行以下操作:

  1. 在 Google Cloud 控制台中打开 Deployment Manager 页面。

    打开 Deployment Manager 页面

  2. 查找所有带有以下标签的部署:

    • goog-composer-environment:<environment-name>
    • goog-composer-location:<environment-location>.

    您应该会看到两个部署带有所述标签:

    • 名为 <environment-location>-<environment-name-prefix>-<hash>-sd 的部署
    • 名为 addons-<uuid> 的部署
  3. 手动删除仍在这两个部署中列出和存在于项目中的资源(例如,Pub/Sub 主题和订阅)。为此,请执行以下操作:

    1. 选择部署。

    2. 点击删除

    3. 选择删除这 2 个部署及其创建的虚拟机、负载平衡器和磁盘等所有资源选项,然后点击全部删除

    删除操作失败,但剩余资源将被删除。

  4. 使用以下任一选项删除部署:

    • 在 Google Cloud 控制台中,再次选择这两个部署。 点击删除,然后选择删除这 2 个部署,但保留其创建的资源选项。

    • 运行 gcloud 命令以删除具有 ABANDON 政策的部署:

      gcloud deployment-manager deployments delete addons-<uuid> \
          --delete-policy=ABANDON
      
      gcloud deployment-manager deployments delete <location>-<env-name-prefix>-<hash>-sd \
          --delete-policy=ABANDON
      
  5. 删除 Cloud Composer 环境

Deployment Manager 显示有关不受支持的功能的信息

您可能会在 Deployment Manager 标签页中看到以下警告:

The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.

对于 Cloud Composer 拥有的 Deployment Manager 部署,您可以忽略此警告。

属于“echo-airflow_monitoring”DAG 的“echo”任务条目的警告

您可能会在 Airflow 日志中看到以下条目:

in _query db.query(q) File "/opt/python3.6/lib/python3.6/site-packages/MySQLdb/
connections.py", line 280, in query _mysql.connection.query(self, query)
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'echo-airflow_monitoring-2020-10-20 15:59:40.000000' for key 'PRIMARY'")

您可以忽略这些日志条目,因为此错误不会影响 Airflow DAG 和任务处理。

我们正在努力改进 Cloud Composer 服务,以从 Airflow 日志中移除这些警告。

在将 Identity-Aware Proxy API 添加到 VPC Service Controls 边界的项目中,环境创建失败

在启用了 VPC Service Controls 的项目中,cloud-airflow-prod@system.gserviceaccount.com 帐号需要在安全边界内获得明确访问权限才能创建环境。

如需创建环境,您可以使用以下解决方案之一:

  • 请勿将 Cloud Identity-Aware Proxy APIIdentity-Aware Proxy TCP API 添加到安全边界。

  • 通过在 YAML 条件文件中使用以下配置,将 cloud-airflow-prod@system.gserviceaccount.com 服务帐号添加为安全边界的成员

     - members:
        - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com
    

启用 compute.requireOsLogin 政策后,Cloud Composer 1 环境创建失败

如果您在项目中将 compute.requireOsLogin 政策设置为 true,则 Cloud Composer 1 v1 环境创建操作将失败。

如需创建 Cloud Composer 1 环境,请在项目中停用此政策。

如需详细了解此组织政策,请参阅组织政策限制条件

停用 compute.vmExternalIpAccess 后,Cloud Composer 环境创建或升级失败

在公共 IP 模式下配置的 Cloud Composer 拥有的 GKE 集群需要其虚拟机的外部连接。因此,compute.vmExternalIpAccess 政策不能禁止创建具有外部 IP 地址的虚拟机。如需详细了解此组织政策,请参阅组织政策限制条件

停用 compute.vmCanIpForward 政策时 Cloud Composer 环境创建失败

在非 VPC 原生(使用别名 IP)模式下创建的 Cloud Composer 1 环境需要此政策允许创建启用了“IP 转发”功能的虚拟机。如需详细了解此组织政策,请参阅组织政策限制条件

对于上传的 DAG 文件,首次运行 DAG 时有几个失败的任务

当您上传某个 DAG 文件时,有时针对该文件的首次 DAG 运行的前几个任务会失败,并显示 Unable to read remote log... 错误。出现此问题的原因是 DAG 文件在环境的存储桶、Airflow 工作器和环境的 Airflow 调度器之间同步。这些同步操作是单独完成的。如果调度器获取 DAG 文件并安排其由工作器执行,并且工作器还没有 DAG 文件,则任务执行将失败。

要解决此问题,默认情况下,Cloud Composer 1.17.0-preview.9 及更高versions的 Airflow 2 环境配置为对失败的任务执行两次重试。如果任务失败,系统会按 5 分钟的时间间隔重试任务两次。

如需在 Airflow 1 中使用此问题的解决方法,请替换 core-default_task_retries Airflow 配置选项并将其设置为大于或等于 2 的数字。

在 Airflow 1.10.15 或更早版本中,任务失败并显示“OSError: [Errno 5] Input/output error”

Airflow 1 版本中的一个错误会导致在极少数情况下将任务放入 Redis 队列两次。

有时,这可能会导致日志文件出现竞态条件,进而造成任务失败。任务失败并在 Cloud Logging 中显示 OSError: [Errno 5] Input/output error,在任务尝试日志中显示 Task is in the 'running' state which is not a valid state for execution.

此错误在 Airflow 2 中得到了解决。如果您在执行长时间运行的任务时,在 Airflow 1 中遇到此问题,请增加 [celery_broker_transport_options]visibility_timeout Airflow 配置选项的值(Composer 1.17.0 的默认值为 604800,旧版环境的默认值为 21600)。对于短时间运行的任务,请考虑向受影响的任务添加更多重试次数,或将环境迁移到 Airflow 2。

Dataproc/Dataflow 运算符失败并显示 Negsignal.SIGSEGV

通过 Celery 工作器使用 grcpio 库时会出现这个间歇性问题。此问题会影响 Airflow 1.10.14 及更高版本。

解决方法是向您的环境添加以下环境变量,以更改 grpcio 轮询策略:GRPC_POLL_STRATEGY=epoll1。 Cloud Composer 1.17.1 及更高版本中已经应用此解决方法。

关于从 GKE 版本中移除对已弃用 Beta 版 API 的支持的公告

Cloud Composer 管理 Cloud Composer 拥有的底层 GKE 集群。除非您在 DAG 和代码中显式使用此类 API,否则可以忽略有关 GKE API 弃用的公告。如有必要,Cloud Composer 会负责处理任何迁移。

发生 CVE-2021-25741 安全问题时的 GKE 升级

通过修复 CVE-2021-25741 中描述的问题,所有 Cloud Composer 的现有 GKE 集群都将自动升级到较新的 GKE 版本。

如果您要立即解决此漏洞,请按照升级集群的说明升级您的环境的 GKE 集群。

  • 如果您使用的是 Cloud Composer 1 环境和 GKE 1.18.x 版或更早版本,请升级到 1.18.20-gke.4501。

  • 如果您使用的是 Cloud Composer 1 环境和 GKE 1.19.x 版,请升级到 1.19.14-gke.301。

  • 如果您使用的是 Cloud Composer 2 环境和 GKE 1.21.x 版,请升级到 1.21.4-gke.301。

Cloud Composer 不应受 Apache Log4j 2 漏洞 (CVE-2021-44228) 影响

针对 Apache Log4j 2 漏洞 (CVE-2021-44228),Cloud Composer 开展了详细调查,我们认为 Cloud Composer 不会受到此漏洞的影响。

Cloud Composer 2:访问 Cloud Storage 存储桶时,Airflow 工作器或调度器可能会遇到问题

在某些偶尔的情况下,在 Cloud Composer 2 环境中,当 Airflow 工作器或 Airflow 调度器重启时,它可能会在访问 Cloud Storage 存储桶内容时发生故障并遇到问题。

在这种情况下,您可能会在 Airflow 日志中看到以 Transport endpoint is not connected 开头的错误。

例如,Airflow 工作器的错误日志可能如下所示:

[Errno 107] Transport endpoint is not connected: '/home/airflow/gcs/logs/airflow_monitoring/echo/2022-01-11T22:50:48+00:00'

解决方案:

  • 升级到 Cloud Composer 2.0.26 或更高版本

更改插件后,Airflow 界面有时有时不重新加载插件

如果插件包含多个会导入其他模块的文件,则 Airflow 界面可能无法识别应该重新加载插件的情况。在这种情况下,需要触发 Airflow Web 服务器的重启。为此,您可以添加环境变量或者安装或卸载 PYPI 依赖项。您也可以重启 Airflow Web 服务器

与 Airflow 元数据数据库通信时出现间歇性问题

此已知问题仅适用于 Cloud Composer 1。

2021 年 8 月 12 日之前创建的某些旧版 Cloud Composer 1 环境(1.16.3 或更低版本)可能会遇到与 Airflow 元数据数据库通信相关的暂时性问题。

如果您遇到此问题,那么在 Airflow 任务日志中,您会看到以下错误消息:

"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"

Cloud Composer 团队正在努力解决这个问题。在此期间,如果您认为自己受到此问题的极大影响,可以采取以下措施将其消除:

  1. 在 Google Cloud 控制台中,前往受影响的 Cloud Composer 环境的环境配置页面。
  2. 点击查看集群详情链接,导航到环境的底层 GKE 集群。
  3. 导航到节点标签页,然后点击节点池部分中显示的 default-pool选择默认池
  4. 点击页面顶部的修改
  5. 将映像类型更改为 Container-Optimized OS with containerd 并保存配置,如下所示。 将节点池映像类型从 Docker 更改为 containerd
  6. 提交更改后,您的 default-pool 节点池将重新配置为使用 containerd 作为其容器运行时。在重新配置节点池时,某些 Airflow 任务可能会失败。如果这些任务已配置重试,则在节点池的操作完成后,Airflow 将重新运行这些任务。

环境的集群有工作负载处于“无法调度”状态

此已知问题仅适用于 Cloud Composer 2。

在 Cloud Composer 2 中,创建环境后,环境的集群中的多个工作负载将保持“无法调度”状态。

当环境纵向扩容时,系统会创建新的工作器 Pod,Kubernetes 会尝试运行它们。 如果没有可用资源来运行它们,则工作器 Pod 会被标记为“无法调度”。

在这种情况下,集群自动扩缩器会增加更多节点,这需要几分钟的时间。在此之前,Pod 会保持“无法调度”状态,并且不会运行任何任务。

无法在没有 Airflow 组件的节点上启动的名为 composer-gcsfusecomposer-fluentd 的不可调度 DaemonSet 工作负载不会影响您的环境。

如果此问题长时间(超过 1 小时)持续存在,您可以检查集群自动扩缩器日志。您可以在日志查看器中使用以下过滤条件找到这些日志:

resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"

它包含有关集群自动扩缩器所做的决策的信息:展开任何 noDecisionStatus 即可查看集群无法纵向扩容或缩容的原因。

访问 Airflow 界面时出错 504

访问 Airflow 界面时可能会收到 504 Gateway Timeout 错误。此错误可能是由以下原因造成的:

  • 暂时性的通信问题。在这种情况下,请稍后尝试访问 Airflow 界面。您也可以重启 Airflow Web 服务器
  • (仅限 Cloud Composer 2)连接问题。如果 Airflow 界面永久不可用,并且生成超时或 504 错误,请确保您的环境可以访问 *.composer.cloud.google.com。如果您使用专用 Google 访问通道并通过 private.googleapis.com 虚拟 IP 或 VPC Service Controls 发送流量并通过 restricted.googleapis.com 虚拟 IP 发送流量,请确保也为 *.composer.cloud.google.com 域名配置了 Cloud DNS。
  • Airflow Web 服务器无响应。如果错误 504 仍然存在,但在某些情况下您仍可以访问 Airflow 界面,则 Airflow Web 服务器可能会因为负载过重而无响应。 尝试增加 Web 服务器的扩缩和性能参数

访问 Airflow 界面时出错 502

错误 502 Internal server exception 表示 Airflow 界面无法处理传入请求。此错误可能是由以下原因造成的:

  • 暂时性的通信问题。请稍后尝试访问 Airflow 界面。

  • 无法启动 Web 服务器。首先,Web 服务器需要先同步配置文件。检查 Web 服务器日志中是否存在类似于 GCS sync exited with 1: gsutil -m cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmpGCS sync exited with 1: gsutil -m cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp 的日志条目。如果您看到这些错误,请检查错误消息中提及的文件是否仍然存在于环境的存储桶中。

    如果这些用户被意外移除(例如,由于配置了保留政策),您可以恢复它们:

    1. 在您的环境中设置新的环境变量。您可以使用任何变量名称和值。

    2. 替换 Airflow 配置选项。您可以使用不存在的 Airflow 配置选项。

Airflow 2.2.3 或更低版本中的 Airflow 界面容易受到 CVE-2021-45229 攻击

CVE-2021-45229 中所述,“使用配置触发 DAG”屏幕容易受到通过 origin 查询参数进行 XSS 攻击。

建议:升级到支持 Airflow 2.2.5 的最新 Cloud Composer 版本。

工作器需要的内存比以前的 Airflow 版本更多

症状

  • 在 Cloud Composer 2 环境中,所有环境的 Airflow 工作器集群工作负载都处于 CrashLoopBackOff 状态,不执行任务。如果您受到此问题的影响,您还可以查看系统生成的 OOMKilling 警告。

  • 此问题可能会导致环境升级。

原因

  • 如果您为 [celery]worker_concurrency Airflow 配置选项使用自定义值,并为 Airflow 工作器使用自定义内存设置,则当资源消耗量接近上限时,您可能会遇到此问题。
  • 与早期版本中的工作器相比,采用 Python 3.11 的 Airflow 2.6.3 中的 Airflow 工作器内存要求提高了 10%。
  • 与 Airflow 2.2 或 Airflow 2.1 中的工作器相比,Airflow 2.3 及更高版本对 Airflow 工作器内存要求提高了 30%。

解决方案

  • 移除 worker_concurrency 的替换项,以便 Cloud Composer 自动计算此值。
  • 如果您对 worker_concurrency 使用自定义值,请将其设置为较低的值。您可以使用自动计算的值作为起点。
  • 或者,您也可以增加可供 Airflow 工作器使用的内存量。
  • 如果您由于此问题而无法将环境升级到更高版本,请在升级之前应用建议的解决方案之一。

使用 Cloud Functions 通过专用网络触发 DAG

Cloud Composer 不支持使用 VPC 连接器通过专用网络通过 Cloud Functions 触发 DAG。

建议:使用 Cloud Functions 在 Pub/Sub 上发布消息。此类事件可以激活 Pub/Sub 传感器以触发 Airflow DAG 或实现基于可延期运算符的方法。

410.0.0 版本中 gcloud Compose 命令的问题

410.0.0 版本的 gcloud 中,以下 Cloud Composer 命令:

  • gcloud composer environments run
  • gcloud composer environments list-packages

返回非零错误代码并显示以下错误消息:

  (ERROR: gcloud crashed (TypeError): 'NoneType' object is not callable)

除了 gcloud 命令生成的常规输出之外,还会出现此行为,不会影响其功能。

如果此问题不会影响您的操作,您可以继续使用 410.0.0 版本,并忽略错误的错误消息。如果您需要使用 410.0.0 版本并以程序化方式使用 gcloud 命令,请实现其他逻辑,以忽略输出中的非零错误代码以及有关错误堆栈轨迹的信息。您还可以查看“解决方案”部分,了解任何其他解决方法。

解决方案

调度器和工作器中的空文件夹

Cloud Composer 不会主动从 Airflow 工作器和调度器中移除空文件夹。当这些文件夹存在于存储桶中并最终被移除时,环境存储桶同步过程可能会创建此类实体。

建议:调整您的 DAG,使其准备好跳过此类空文件夹。

重启这些组件时(例如,由于 Cloud Composer 集群中的缩减或维护操作),此类实体最终会从 Airflow 调度器和工作器的本地存储空间中移除。

对 Kerberos 的支持

Cloud Composer 尚不支持 Airflow Kerberos 配置

Cloud Composer 2 对计算类的支持

Cloud Composer 2 仅支持通用 计算类。这意味着无法运行请求其他计算类(例如平衡扩容)的 Pod。

通用类允许运行请求最多 110 GB 内存和 30 个 CPU 的 Pod(如计算类最大值请求中所述)。

如果您想使用基于 ARM 的架构或需要更多的 CPU 和内存,则必须使用其他计算类,这在 Cloud Composer 2 集群中不受支持。

建议:使用 GKEStartPodOperator 在支持所选计算类的其他集群上运行 Kubernetes Pod。如果您运行需要其他计算类的自定义 Pod,则这些 Pod 也必须在非 Cloud Composer 2 集群上运行。

支持 Google Campaign Manager 360 操作符

2.1.13 之前的 Cloud Composer 版本中的 Google Campaign Manager Operator 基于已弃用的 Campaign Manager 360 v3.5 API,其停用日期为 2023 年 5 月 1 日

如果您使用 Google Campaign Manager 运算符,请将环境升级到 Cloud Composer 2.1.13 或更高版本。

支持 Google Display & Video 360 运营商

在 Cloud Composer 2.1.13 之前的版本中,Google Display & Video 360 运算符基于已弃用的 Display & Video 360 v1.1 API,其停用日期为 2023 年 4 月 27 日。

如果您使用 Google Display & Video 360 运算符,请将您的环境升级到 Cloud Composer 2.1.13 版或更高版本。除此之外,您可能还需要更改 DAG,因为一些 Google Display & Video 360 运算符已弃用,取而代之的是新运算符。

  • GoogleDisplayVideo360CreateReportOperator 现已废弃。请改用 GoogleDisplayVideo360CreateQueryOperator。此运算符返回 query_id,而不是 report_id
  • GoogleDisplayVideo360RunReportOperator 现已废弃。请改用 GoogleDisplayVideo360RunQueryOperator。此运算符返回 query_idreport_id,而不是仅 report_id,并且需要 query_id(而不是 report_id)作为参数。
  • 如需检查报告是否准备就绪,请使用采用 query_idreport_id 参数的新 GoogleDisplayVideo360RunQuerySensor 传感器。已废弃的 GoogleDisplayVideo360ReportSensor 传感器只需要 report_id
  • GoogleDisplayVideo360DownloadReportV2Operator 现在同时需要 query_idreport_id 参数。
  • GoogleDisplayVideo360DeleteReportOperator 中,没有会影响 DAG 的更改。

次要范围名称限制

CVE-2023-29247(界面中的任务实例详情页面容易受到存储的 XSS 攻击)

Airflow 2.0.x 至 2.5.x 版本中的 Airflow 界面容易受到 CVE-2023-29247 攻击。

如果您使用的是 Cloud Composer 2.4.2 之前的版本,并怀疑您的环境容易受到攻击,请阅读以下说明和可能的解决方案。

在 Cloud Composer 中,使用 IAM 和 Airflow 界面访问权限控制功能保护对 Airflow 界面的访问。

这意味着,为了利用 Airflow 界面漏洞,攻击者首先需要获得对您的项目的访问权限,以及必要的 IAM 权限和角色。

解决方案:

  • 验证项目中的 IAM 权限和角色,包括分配给各个用户的 Cloud Composer 角色。确保只有获得批准的用户才能访问 Airflow 界面。

  • 通过 Airflow 界面访问权限控制机制验证分配给用户的角色(这是一种单独的机制,可提供对 Airflow 界面的更精细的访问权限)。请确保只有获得批准的用户才能访问 Airflow 界面,并且所有新用户均以适当的角色注册。

  • 请考虑通过 VPC Service Controls 进行额外安全强化。

删除后,系统不会重新创建 Cloud Composer 2 Composer 环境的 Airflow 监控 DAG

如果 Airflow 监控 DAG 被用户删除,或者使用 composer-2.1.4-airflow-2.4.3 从 Composer 环境中的存储桶中移除,则系统不会自动重新创建 Airflow 监控 DAG。

解决方案:

  • 此问题已在后续版本(例如 Compose-2.4.2-airflow-2.5.3)中得到修复。建议的方法是将环境升级到较新版本。
  • 环境升级的替代或临时解决方法是,从具有相同版本的其他环境中复制 airflow_monitoring DAG。

如果启用 Sentry,升级操作可能会失败

如果您在环境中配置了 Sentry 并将 [sentry]sentry_on 设置设为 true,则 Cloud Composer 环境的升级操作可能会失败。

解决方案:

  • 在您的环境中关闭 Sentry,执行升级,然后重新配置 Sentry。

无法减少 Cloud SQL 存储空间

Cloud Composer 使用 Cloud SQL 运行 Airflow 数据库。随着时间的推移,Cloud SQL 实例的磁盘存储空间可能会增加,因为当 Airflow 数据库增大时,磁盘会纵向扩容以适应 Cloud SQL 操作存储的数据。

无法缩减 Cloud SQL 磁盘大小。

解决方法:如果要使用最小的 Cloud SQL 磁盘大小,可以使用快照重新创建 Cloud Composer 环境。

从 Cloud SQL 移除记录后,数据库磁盘使用率指标不会缩减

Postgres 或 MySQL 等关系型数据库在删除或更新行时不会以物理方式移除行。相反,它会将它们标记为“死元组”,以保持数据一致性并避免阻塞并发事务。

MySQL 和 Postgres 都实现了删除记录后回收空间的机制。

虽然您可以强制数据库收回未使用的磁盘空间,但这种操作需要大量资源,而且还会锁定数据库,导致 Cloud Composer 无法使用。因此,建议依靠构建机制回收未使用的空间。

禁止访问:发生了授权错误

如果此问题会影响用户,Access blocked: Authorization Error 对话框中会显示 Error 400: admin_policy_enforced 消息。

如果在 Google Workspace 中启用了 API 控件 > 未配置的第三方应用 > 不允许用户访问任何第三方应用选项,并且未明确允许 Cloud Composer 应用中的 Apache Airflow,则除非用户明确允许该应用,否则将无法访问 Airflow 界面。

如需允许访问,请执行允许访问 Google Workspace 中的 Airflow 界面中提供的步骤。

过去成功执行的任务实例已标记为“失败”

在某些情况下和极少数情况下,过去成功完成的 Airflow 任务实例可以标记为 FAILED

如果发生这种情况,它通常由环境更新或升级操作触发,或者由 GKE 维护触发。

注意:问题本身并不表示环境中存在任何问题,也不会导致任务执行有任何实际失败。

此问题已在 Cloud Composer 2.6.5 版或更高版本中修复。

在与 Cloud Composer 配置的其他部分通信时,Airflow 组件出现问题

在极少数情况下,与 Compute Engine 元数据服务器的通信缓慢可能会导致 Airflow 组件无法以最佳方式运行。例如,Airflow 调度器可能会重启,Airflow 任务可能需要重试,或者任务启动时间可能较长。

症状

以下错误会显示在 Airflow 组件(例如 Airflow 调度器、工作器或 Web 服务器)的日志中:

Authentication failed using Compute Engine authentication due to unavailable metadata server

Compute Engine Metadata server unavailable on attempt 1 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 2 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 3 of 3. Reason: timed out

解决方案:

设置以下环境变量GCE_METADATA_TIMEOUT=30

Airflow Web 服务器中不提供 /data 文件夹

在 Cloud Composer 2 中,Airflow Web 服务器主要是只读组件,Cloud Composer 不会将 data/ 文件夹同步到此组件。

有时,您可能希望在所有 Airflow 组件(包括 Airflow Web 服务器)之间共享通用文件。

解决方案:

  • 将要与 Web 服务器共享的文件封装到 PYPI 模块中,并将其作为常规 PYPI 软件包安装。在环境中安装 PYPI 模块后,文件会添加到 Airflow 组件的映像中,并可供这些组件使用。

  • 将文件添加到 plugins/ 文件夹中。该文件夹会同步到 Airflow Web 服务器。

后续步骤