Fluid-架构详细解析

前言

Fluid 是云原生分布式数据集编排和加速引擎，主要服务于云原生场景下的数据密集型应用，例如大数据应用、AI 应用等。

其目标是为AI与大数据云原生应用提供一层高效便捷的数据抽象，将数据从存储抽象出来，以便实现：

1. 通过数据亲和性调度和分布式缓存引擎加速，实现数据和计算之间的融合，从而加速计算对数据的访问。

2. 将数据独立于存储进行管理，并且通过Kubernetes的命名空间进行资源隔离，实现数据的安全隔离。

3. 将来自不同存储的数据联合起来进行运算，从而有机会打破不同存储的差异性带来的数据孤岛效应。

本文对Fliud的架构和组件进行详细解析，分析是如何实现上述目标的。

概念

Dataset:

数据集是逻辑上相关的一组数据的集合，会被运算引擎使用，比如大数据的Spark，AI场景的TensorFlow/PyTorchJob。可以理解为一个抽象的volume。告诉业务哪里可以获取到数据

Runtime:

实现dataset能力的实际执行引擎，定义了一系列生命周期的接口。可以通过实现这些接口，支持数据集的管理和加速。 目前 Fluid 支持的 Runtime 类型有 JuiceFS、Alluxio、JindoFS，其中 Alluxio、JindoFS 都是典型的分布式缓存引擎；JuiceFS 是一款分布式文件系统，具备分布式缓存能力。

dataload：

提供数据缓存、预加载能力的CRD。该CRD让业务可通过简单的配置就能完成整个数据预加载过程，并对数据预加载的许多行为进行自定义控制。比如指定一个或多个数据集子目录进行加载，设置数据加载时的缓存副本数量等。

核心组件

控制器(Fluid-controller-manager)

这些控制器包括：

Dataset Controller: 负责Dataset的生命周期管理，包括创建，与Runtime的绑定和解绑，删除。

Runtime Controller: 负责Runtime的生命周期管理，包括创建，扩缩容，缓存预热和清理的触发，删除等操作，这些操作实际是操作后端缓存引擎（Alluxio、juiceFS）

dataload controller：负责dataload的生命周期管理，包括创建，缓存状态变更，与runtime引擎对接，利用底层引擎实际缓存能力。

调度器(Fluid-scheduler)

负责在调度过程，结合数据缓存的信息，选择符合条件的节点。

Cache co-locality Plugin: 结合Runtime中的数据缓存信息，对于使用数据集的应用进行调度。无需用户指定缓存节点。

Prefetch Plugin: 在调度过程中，根据应用使用数据的特性触发Runtime进行数据预热

实现方式是利用webhook，给node打标签，给pod打上对应的亲和性、凡亲和性

CSI Driver

以daemonset的形式部署在每个节点上。负责与k8s交互，提供相应的csi接口，创建外部存储，并将目录挂载到pod中。

架构

Fluid 的整个架构主要分为三个部分。

Controller

包括 RuntimeController、 DatasetController、DataLoad Controller，分别管理 Runtime 、 Dataset 、DataLoad的生命周期，三者共同作用，以 helm chart 为基础，快速搭建出一套完整的分布式缓存系统，通常是 master + worker + fuse 的形式，向上提供服务。

master 是缓存系统的核心组件，通常是一个 pod；

worker 是组成缓存集群的组件，可以是多个 pod，可以设置个数；用于缓存远端数据。

fuse 是提供 POSIX 接口服务的组件，主要用于与engine的远端存储通信，并在节点上实现文件系统挂载。并与csi driver配合实现pod内目录挂载。

调度器

在有缓存的情况下，调度器会根据 worker 的节点信息，使得上层应用 pod 尽可能调度到有缓存的节点。

CSI Driver

提供标准CSI接口，与本节点kubelet通信。并与fuse配合，实现远端存储挂载到pod内目录。