Cloud Composer 责任共担模型

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

在 Cloud Composer 上运行关键业务应用需要多方承担不同的责任。本文档虽然并不详尽，但列出了 Google 和客户的责任。

Google 责任

  • 强化和修补 Cloud Composer 环境的组件和底层基础架构，包括 Google Kubernetes Engine 集群、Cloud SQL 数据库（用于托管 Airflow 数据库）、Pub/Sub、Artifact Registry 和其他环境元素。具体而言，这包括自动升级底层基础架构，包括 GKE 集群和环境的 Cloud SQL 实例。

  • 通过整合 IAM 提供的访问权限控制机制、默认加密静态数据、提供额外客户管理的存储加密和加密传输中的数据，保护对 Cloud Composer 环境的访问权限。

  • 为 Identity and Access Management、Cloud Audit Logs 和 Cloud Key Management Service 提供 Google Cloud 集成。

  • 出于合同支持目的，使用 Access Transparency 和 Access Approval 限制并记录 Google 对客户集群的管理员权限。

  • 在 Cloud Composer 版本说明中发布有关 Cloud Composer 和 Airflow 版本之间不向后兼容的更改的信息。

  • 确保 Cloud Composer 文档保持最新状态：

    • 提供 Cloud Composer 提供的所有功能的说明。

    • 提供问题排查说明，有助于将环境保持在正常运行状态。

    • 发布已知问题及解决方法（如果有）的信息。

  • 通过提供处理突发事件的新版本，解决与 Cloud Composer 提供的 Cloud Composer 环境和 Airflow 映像（不包括客户安装的 Python 软件包）相关的重要安全突发事件。

  • 排查 Cloud Composer 环境运行状况问题，具体取决于客户的支持方案。

  • 维护和扩展 Cloud Composer Terraform 提供程序的功能。

  • 与 Apache Airflow 社区合作，维护和开发 Google Airflow 操作器。

  • 对 Airflow 核心功能进行问题排查并尽可能修复问题（如果可能）。

客户责任

  • 在 Cloud Composer 服务发布可解决这些问题的 Cloud Composer 版本后，升级到新的 Cloud Composer 和 Airflow 版本，以保留对产品的支持并解决安全问题。

  • 维护 DAG 代码，使其与所用的 Airflow 版本兼容。

  • 保持环境的 GKE 集群配置原封不动，特别是包括其自动升级功能。

  • 在 IAM 中为环境的服务帐号维护适当的权限。特别是保留 Cloud Composer 代理和环境的服务帐号所需的权限。保留用于 Cloud Composer 环境加密的 CMEK 密钥所需的权限，并根据需要轮替该密钥。

  • 在 IAM 和 Airflow 界面访问权限控制配置中维护适当的最终用户权限。

  • 通过使用维护 DAG 将 Airflow 数据库大小保持在 16 GB 以下。

  • 在向 Cloud Customer Care 提交支持请求之前，先解决所有 DAG 解析问题。

  • 使用 Cloud Composer 优化指南和环境伸缩指南调整 Cloud Composer 环境参数（例如 Airflow 组件的 CPU 和内存）和 Airflow 配置，以满足 Cloud Composer 环境的性能和负载预期。

  • 避免移除 Cloud Composer Agent 和环境的服务帐号所需的权限（移除这些权限可能会导致管理操作失败，或者 DAG 和任务失败）。

  • 使 Cloud Composer 所需的所有服务和 API 始终保持启用状态。这些依赖项必须在 Cloud Composer 所需的级别上配置配额。

  • 保留用于托管 Cloud Composer 环境所用容器映像的 Artifact Registry 代码库。

  • 遵循建议和最佳实践来实现 DAG。

  • 按照调度器问题排查、DAG 问题排查和触发器问题排查的说明诊断 DAG 和任务失败。

  • 避免在环境的 GKE 集群中安装或运行会干扰 Cloud Composer 组件并阻止它们正常运行的其他组件。

后续步骤