使用 Apache DolphinScheduler 构建和部署大数据平台，将任务提交至 AWS 的实践经验

作者介绍

李庆旺 - 软件开发工程师，思科

引言

大家好，我是李庆旺，来自思科的软件开发工程师。我们的团队已经使用 Apache DolphinScheduler 搭建我们自己的大数据调度平台近三年时间。从最初的 2.0.3 版本开始至今，我们与社区一同成长，今天给大家分享的技术思路是基于 3.1.1 版本进行的二次开发，增加了一些社区版本中未包含的新功能。

今天，我将分享我们如何使用 Apache DolphinScheduler 构建大数据平台，将我们的任务提交部署到 AWS 上，期间遇到的一些挑战和我们的解决方案。

架构设计与调整

初始我们所有的服务均部署在 Kubernetes（K8s）上，包括 API、Alert、以及 Zookeeper（ZK）、Master 和 Worker 等组件。

大数据处理任务

我们对 Spark、ETL 和 Flink 等任务进行了二次开发：

• ETL 任务：我们团队开发了一种简单的拖拉拽形式的工具，用户可以通过这种方式快速生成 ETL 任务。

• Spark 支持：早期版本仅支持在 Yarn 上运行的 Spark，我们通过二次开发使其支持在 K8s 上运行。目前社区的最新版本已支持 Spark on K8s。

• *Flink 二次开发: 同样，我们新增了 Flink On K8s 的流任务，同时还有 SQL 任务和 Python 任务 On K8s 的支持。

支持 Job 上 AWS

随着业务的扩展和数据政策的需求，我们面临必须在不同地区运行数据任务的挑战。这需要我们构建一个能够支持多集群的架构。以下是我们的解决方案和实施过程的详细描述。

我们的当前架构包括一个集中控制终端，即一份单一的 Apache DolphinScheduler 服务，它负责管理多个集群。这些集群分布在不同的地理位置，例如欧盟和美国，以遵守当地的数据政策和隔离需求。

架构调整

为了满足这一需求，我们进行了如下调整：

• 保持 Apache DolphinScheduler 服务的集中管理：我们的 DolphinScheduler 服务仍然部署在自建的 Cisco Webex DC 中，保持了管理的集中性和一致性。

• 支持 AWS EKS 集群：同时，我们扩展了架构的能力，以支持多个 AWS EKS 集群。这样，可以满足任务运行在 EKS 集群上的新业务需求，而不影响其他 Webex DC 集群的运行和数据隔离。

通过这种设计，我们能够在保证数据隔离和政策遵守的同时，灵活应对不同的业务需求和技术挑战。

接下来介绍下如何处理 Apache DolphinScheduler 在 Cisco Webex DC 中运行任务时的技术实现和资源依赖。

资源依赖和存储

由于我们所有的任务都在 Kubernetes（K8s）上运行，对我们来说，以下几点是至关重要的：

Docker 镜像

• 存储位置：之前，我们所有 Docker 镜像都存储在 Cisco 的一个 Docker 仓库中。

• 镜像管理：这些镜像为我们运行的各种服务和任务提供了必要的运行环境和依赖。

资源文件和依赖

• Jar 包和配置文件等：我们使用 Amazon S3 Bucket 作为资源存储中心，存储用户的 Jar 包和可能的依赖配置文件。

• 安全性资源管理：包括数据库密码、Kafka 的加密信息和用户依赖的密钥等，这些敏感信息都存储在 Cisco 的 Vault 服务中。

安全访问和权限管理

对于访问 S3 Bucket 这一需求，我们需要配置和管理 AWS 凭证：

IAM 账户配置

• 凭证管理：我们使用 IAM 账户来管理对 AWS 资源的访问权限，包括访问密钥（Access Keys）和秘密密钥（Secret Keys）。

• K8s 集成：这些凭证信息被存储在 Kubernetes 的 Secret 中，由 Api-Service 引用，从而安全地访问 S3 Bucket。

• 权限控制和资源隔离：通过 IAM 账户，我们可以实现精细的权限控制，确保数据安全和业务的合规性。

IAM 账户访问密钥的过期问题及对策

在使用 IAM 账户管理 AWS 资源的过程中，我们面临着访问密钥过期的问题。这里详细介绍我们如何应对这一挑战。

访问密钥过期问题

• 密钥周期：IAM 账户的 AWS 密钥通常设置为每 90 天自动过期，这是为了增强系统的安全性。

• 任务影响：一旦密钥过期，所有依赖这些密钥访问 AWS 资源的任务都将无法执行，这需要我们及时更新密钥以保持业务的连续性。

针对这种情况，我们给任务设置了定期重启，同时设置了对应的监控，如果 AWS 的账号在未到过期时间之内出现了问题，那么就需要通知到我们相应的开发人员，去做一些处理。

支持 AWS EKS

随着业务扩展到 AWS EKS，我们需要对现有架构和安全措施进行一系列调整。

比如像刚才说的 Docker image，我们之前是放到 Cisco 自己的 Docker repo 里，那现在就需要把 Docker image 放到 ECR 上。

多个 S3 Bucket 的支持

由于 AWS 集群的分散性和不同业务的数据隔离需求，我们需要支持多个 S3 Bucket 来满足不同集群的数据存储需求：

• 集群与 Bucket 的对应：每个集群将访问其对应的 S3 Bucket，以确保数据的局部性和合规性。

• 修改策略：我们需要调整我们的存储访问策略，以支持从多个 S3 Bucket 读写数据，不同的业务方要访问自己对应的 S3 bucket。

密码管理工具的变更

为了提高安全性，我们从 Cisco 的自建 Vault 服务迁移到了 AWS 的 Secrets Manager（ASM）：

• ASM 的使用：ASM 提供了一个更加集成的解决方案来管理 AWS 资源的密码和密钥。

我们采取了使用 IAM Role 和 Service Account 的方式，以增强 Pod 的安全性：

• 创建 IAM Role 和 Policy：首先创建一个 IAM Role，为其绑定必要的 Policy，确保只有必要的权限被授予。

• 绑定 K8s Service Account：随后创建一个 Kubernetes Service Account，并将其与 IAM Role 关联。

• Pod 的权限集成：在运行 Pod 时，通过关联到 Service Account，Pod 可以直接通过 IAM Role 获取所需的 AWS 凭证，从而访问必要的 AWS 资源。

这些调整不仅提升了我们系统的可扩展性和灵活性，还加强了整体的安全架构，确保在 AWS 环境中的运行既高效又安全。同时也避免了之前密钥自动过期需要重启的问题。

优化资源管理与存储流程

为了简化部署流程，我们计划直接将 Docker 镜像推送到 ECR，而不是通过二次中转：

• 直接推送：修改当前的打包流程，使 Docker 镜像在构建后直接推送到 ECR，减少时间延迟和潜在的错误点。

改动实施

• 代码级调整：我们在 DolphinScheduler 的代码中进行了修改，使其能够支持多个 S3 Client，增加了对多个 S3Client 的缓存管理，。

• 资源管理 UI 调整：允许用户通过界面选择不同的 AWS Bucket 名称进行操作。

• 资源访问：修改后的 Apache DolphinScheduler 服务现在可以访问多个 S3 Bucket，允许在不同的 AWS 集群之间灵活管理数据。

AWS 资源的管理和权限隔离

集成 AWS Secrets Manager（ASM）

我们对 Apache DolphinScheduler 进行了扩展，以支持 AWS Secrets Manager，使得用户可以在不同的集群类型中选择密钥：

ASM 的功能集成

• 用户界面改进：在 DolphinScheduler 的用户界面中，增加了对不同 secret 类型的展示和选择功能。

• 自动密钥管理：运行时将保存了用户选定的 secret 的文件路径映射到实际的 Pod 环境变量中，确保了密钥的安全使用。

动态资源配置和初始化服务（Init Container）

为了更灵活地管理和初始化 AWS 资源，我们实施了一个名为 Init Container 的服务：

• 资源拉取：Init Container 在 Pod 执行前，会自动拉取用户配置的 S3 资源，并将其放置到指定目录下。

• 密钥和配置管理：根据配置，Init Container 会检查并拉取 ASM 中的密码信息，随后将其存放在文件中，并通过环境变量映射，供 Pod 使用。

Terraform 在资源创建和管理中的应用

我们通过 Terraform 自动化了 AWS 资源的配置和管理过程，简化了资源分配和权限设定：

• 资源自动化配置：使用 Terraform 创建所需的 AWS 资源，如 S3 Bucket 和 ECR Repo。

• IAM 策略和角色管理：自动创建 IAM 策略和角色，确保每个业务单元可以按需访问其所需的资源。

权限隔离和安全性

我们通过精细的权限隔离策略，确保不同业务单元在独立的 Namespace 中操作，避免了资源访问冲突和安全风险：

实施细节

• Service Account 的创建和绑定：为每个业务单元创建独立的 Service Account，并将其与 IAM 角色绑定。

• Namespace 隔离：每个 Service Account 操作在指定的 namespace 内，通过 IAM 角色访问其对应的 AWS 资源。

集群支持与权限控制的改进

集群类型的扩展

我们增加了一个新的字段 cluster type，以支持不同类型的 K8S 集群，这不仅包括标准的 Webex DC 集群和 AWS EKS 集群，还可以支持具有更高安全要求的特定集群：

集群类型管理

• 集群类型字段：通过引入cluster type字段，我们可以轻松地管理和扩展对不同 K8S 集群的支持。

• 代码级别的定制：针对特定集群的独特需求，我们可以进行代码级别的修改，以确保在这些集群上运行 job 时能够满足其安全和配置要求。

增强的权限控制系统（Auth 系统）

我们开发了 Auth 系统，专门用于细粒度的权限控制，包括 project、resource 和 namespace 间的权限管理：

权限管理功能

• 项目和资源权限：用户可以通过项目维度控制权限，一旦拥有项目权限，即拥有该项目下所有资源的访问权。

• namespace 权限控制：确保特定团队只能在指定的 namespace 中运行其项目的 job，从而保证运行资源隔离。

比如说 A team，那么它的 A namespace 上面只能运行某一些 project job，那么比如说像 B 用户，他就不能去在 A 用户的那些 namespace 上面去运行 job。

AWS 资源的管理和权限申请

我们通过 Auth 系统和其他工具，管理 AWS 资源的权限和访问控制，使得资源分配更加灵活和安全：

• 多 AWS Account 支持：在 Auth 系统中可以管理多个 AWS 账户，并绑定不同的 AWS 资源如 S3 Bucket、ECR 和 ASM 等。

• 资源映射和权限申请：用户可以在系统中对已有的 AWS 资源进行映射和权限申请，这样在运行 job 时可以轻松地选择需要访问的资源。

Service Account 的管理和权限绑定

为了更好地管理服务账户和其权限，我们实现了以下功能：

Service Account 的绑定和管理

• Service Account 唯一区分：通过特定的集群、namespace 和项目名称绑定 Service Account，确保其唯一性。

• 权限绑定界面：用户可以在界面上将 Service Account 绑定到具体的 AWS 资源，如 S3、ASM 或 ECR，从而实现权限的精确控制。

简化操作和资源同步

刚才说了很多，但实际对于用户来说操作其实比较简单，整个申请的流程那些都其实都是一次性的工作，为了进一步提高 Apache DolphinScheduler 在 AWS 环境中的用户体验，我们采取了一系列措施来简化操作流程和增强资源同步功能。

给大家总结一下：

简化的用户操作界面

在 DolphinScheduler 中，用户可以轻松配置其作业运行的具体集群和 namespace：

集群和 namespace 选择

• 集群选择：用户在提交作业时，可以选择希望作业运行的集群。

• namespace 配置：根据选择的集群，用户还需要指定作业运行的 namespace。

Service Account 和资源选择

• Service Account 展示：页面将根据选定的项目、集群和 namespace 自动展示相应的 Service Account。

• 资源访问配置：用户可以通过下拉列表选择与服务账户关联的 S3 Bucket、ECR 地址和 ASM 秘钥。

未来展望

针对于现在的设计，还有一些地方可以优化改进可以提升用户提交和方便运维：

• 镜像推送优化：考虑跳过 Cisco 的中转打包流程，直接将包推送至 ECR，尤其是针对特定于 EKS 的镜像修改。

• 一键同步功能：我们计划开发一键同步功能，允许用户将一个上传到 S3 Bucket 的资源包，勾选自动同步到其他 S3 Bucket，减少重复上传的工作。

• 自动映射至 Auth 系统：Aws 资源通过 Terraform 创建后，系统将自动将这些资源映射到权限管理系统中，避免用户手动进行资源录入。

• 权限控制优化：通过自动化的资源和权限管理，用户的操作变得更加简洁，减少了设置和管理的复杂性。

通过这些改进，我们期望能够帮助用户使用 Apache DolphinScheduler 更有效地部署和管理他们的作业，无论是在 Webex DC 还是在 EKS 上，同时提高资源管理的效率和安全性。

本文由 白鲸开源科技 提供发布支持！