Fluid的系统架构是什么呢?

Fluid 是构建在 K8s 上的系统，对原生 K8s 具备良好的兼容性，无需修改任意代码。如上图所示，用户需要定义两个 CRD，分别是 Dataset 和 Runtime。Dataset 是数据集的通用定义，这是我们提供的 K8s 资源对象，需要写 YAML 文件来定义数据集从哪儿来，以及想要放到哪儿去；Runtime 是存储这些数据集的缓存引擎，目前使用的是开源的分布式缓存系统 Alluxio。这里要注意的是 Dataset 和 Runtime 定义的时候，它通常是要具有相同 Namespace，从而实现很好的绑定。

Fluid Operator 是 Fluid 项目的核心，它分为两部分。第一部分是 Fluid-controller-manager，包含很多 Controller；另一部分为 Fluid-Scheduler。这两个组件完成了编排调度的操作。Fluid-controller-manager 做的工作就是对数据进行编排，包括三个 Controller。这三个 Controller 从逻辑上它们是独立的，可以去做单进程。但为了降低复杂性，很多 Controller 的功能编译时被合并成一个和多个可执行文件，所以在真正运行起来时，也是一个进程。

数据集的 Dataset Controller 负责整个数据集的生命周期管理，包括数据集的创建，以及要和哪个 Runtime 进行绑定。 Runtime Controller 负责数据集如何在云原生平台上被调度与缓存，应该放在哪些节点上，要有多少副本。 Volume Controller：由于 Fluid 是基于 K8s 运行，因此需要和 K8s 进行对接，这里我们使用的是 PVC（数据持久卷）协议，这是 K8s 本地存储栈的协议，使用非常广泛，Fluid 与 PVC 的对接非常流畅。 最下面为 Cache Runtime Engine，是真正完成缓存数据具体工作的地方。 图中右边部分的 Fluid-Scheduler 主要是基于定义好的 dataset、runtime controller 等具体信息，对 K8s 的调度器做一些扩展。这里面包含两个 Plugin：

Cache co-locality Plugin：Cache co-locality Plugin 做的事就是结合前面数据编排的信息，把应用调度到最合适的节点上，然后尽量能够让用户去读到缓存节点里面的信息。 Prefetch Plugin：当用户集群还没有缓存流入数据情况之下，且知道应用肯定是要读哪一类数据时，尤其在应用调度和编排运行之前，可以做 Prefetch 的调度，将这个数据从最底下的存储卷当中缓存到数据缓存里面，可以手动触发。 再往下就是标准 K8s。通过 K8s 可以对接底层不同的存储，具体的对接方式可通过 K8s 的 PVC 完成。由于通过 Alluxio 进行了抽象，可以直接支持 Alluxio 本身支持的存储类型。