Fluid新魔法:跨Kubernetes Namespace共享数据集

简介: Fluid帮助数据科学家优化数据访问。不同的数据科学家团队会在多个不同的Namespace中创建数据密集型作业,且这些作业将访问相同的数据集。多个数据科学家复用相同的数据集,特别是开源数据集。各数据科学家拥有自己独立的Namespace提交作业。如果对于每个Namespace运行缓存运行时并进行缓存预热,会造成缓存资源浪费和作业启动延迟问题。
什么是Fluid?

在云上通过云原生架构运行AI、大数据等任务,可以享受计算资源弹性的优势,但同时也会遇到,计算和存储分离架构带来的数据访问延迟和远程拉取数据带宽开销大的挑战。尤其在GPU深度学习训练场景中,迭代式的远程读取大量训练数据方法会严重拖慢GPU计算效率。

另一方面,Kubernetes只提供了异构存储服务接入和管理标准接口(CSI,Container Storage Interface),对应用如何在容器集群中使用和管理数据并没有定义。在运行训练任务时,数据科学家需要能够管理数据集版本,控制访问权限,数据集预处理,加速异构数据读取等。但是在Kubernetes中还没有这样的标准方案,这是云原生容器社区缺失的重要能力之一。

Fluid对“计算任务使用数据的过程”进行抽象,提出了弹性数据集Dataset的概念,并作为“first class citizen”在Kubernetes中实现。Fluid围绕弹性数据集Dataset,创建了数据编排与加速系统,来实现Dataset管理(CRUD操作)、权限控制和访问加速等能力。

Fluid中有两个最核心的概念:Dataset和Runtime。

  • Dataset 是指数据集,是逻辑上相关的一组数据的集合,会被计算引擎使用,比如Spark,TensorFlow,PyTorch等等。
  • Runtime 指的是提供分布式缓存的系统,目前 Fluid 支持的 Runtime 类型有 JuiceFS、Alluxio、JindoFS,GooseFS,其中 Alluxio、JindoFS 都是典型的分布式缓存引擎;JuiceFS是一款分布式文件系统,具备分布式缓存能力。这些缓存系统使用Kubernetes集群中节点上的存储资源(如:内存和磁盘)来作为远程存储系统的计算侧缓存。
为什么Fluid需要支持跨namespace共享?

Fluid最早的模式默认支持一个Dataset独占一个Runtime,可以理解为一个数据集就有专门的缓存集群加速。可以针对于数据集的特点,比如单文件大小特征,文件数量规模,客户端数量进行定制优化;并且提供单独的缓存系统。它能够提供最好的性能以及稳定性,并且不会互相干扰,但是它的问题在于硬件资源浪费,需要为每个不同的数据集部署缓存系统;同时运维复杂,需要管理多个缓存Runtime。这种模式其实本质上是单租户架构,适合于对于数据访问吞吐和延时高要求的场景。

当然随着Fluid使用的深入,也有不同的需求出现。比如用户会在多个不同的Namespace中创建数据密集型作业,且这些作业将访问相同的数据集。多个数据科学家共享相同的数据集,各数据科学家拥有自己独立的Namespace提交作业。如果对于每个Namespace重新部署缓存系统并进行缓存预热,那么就会造成数据冗余和作业启动延迟问题。

此时社区用户能够为了节省资源和运维简单降低对于性能的要求,就开始有了跨Namespace访问数据集的需求。跨namespace需求本质上是在呼唤多租户架构,即集群管理员将Runtime指向某个存储的根目录,多个数据科学家可以在不同的Namespace中创建多个Dataset共用同一个Runtime。更近一步,管理员可以为不同Namespace的数据科学家配置子目录和不同的读写权限。

共享Runtime模式

独占Runtime模式

性能

相对低

可靠性

相对低

隔离性

相对低

可定制配置能力

相对低

升级能力

升级简单,只需要更新一次,维护人员不需要对每个用户更新,节省了很大的运维成本。

可以控制升级的时间和方式,选择延迟甚至跳过升级周期。

运维复杂度

简单

多个数据集管理成本高

硬件成本

相对低

所有的架构选择上并不存在银弹,都是取舍。本文以AlluxioRuntime为例子向您演示如何使用Fluid共享Runtime。

使用样例:

想像一下,用户A在Kubernetes的命名空间development下对于数据集spark进行预热,用户B在另一个命名空间production中也同样需要访问数据集spark,通过Fluid可以帮助用户B在命名空间production中访问缓存过的数据,不需要二次预热,简化用户使用。可以做到一次预热,不同namespace的用户都得到收益。

  1. 在运行该示例之前,请参考安装文档完成安装(目前该功能存在于master分支)。并检查Fluid各组件正常运行:
NAME                                        READY   STATUS              RESTARTS   AGE
csi-nodeplugin-fluid-mwx59                  2/2     Running             0          5m46s
csi-nodeplugin-fluid-tcbfd                  2/2     Running             0          5m46s
csi-nodeplugin-fluid-zwm8t                  2/2     Running             0          5m46s
dataset-controller-5c7557c4c5-q58bb         1/1     Running             0          5m46s
fluid-webhook-67fb7dffd6-h8ksp              1/1     Running             0          5m46s
fluidapp-controller-59b4fcfcb7-b8tx5        1/1     Running             0          5m46s
  1. 创建命名空间development
$ kubectl create ns development
  1. 在命名空间development创建Dataset和AlluxioRuntime,
$ cat<<EOF >dataset.yaml
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:  name: spark
  namespace: development
spec:  mounts:    - mountPoint: https://mirrors.bit.edu.cn/apache/spark/
      name: spark
      path: "/"---apiVersion: data.fluid.io/v1alpha1
kind: AlluxioRuntime
metadata:  name: spark
  namespace: development
spec:  replicas: 1  tieredstore:    levels:      - mediumtype: MEM
        path: /dev/shm
        quota: 4Gi
        high: "0.95"        low: "0.7"EOF
  1. 查看数据集状态
$ kubectlget dataset -ANAMESPACE     NAME    UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
development   spark   3.41GiB          0.00B    4.00GiB          0.0%                Bound   2m54s
  1. 在命名空间development创建Pod访问数据集
$ cat<<EOF >app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: development
spec:
  containers:
- name: nginx
      image: nginx
      volumeMounts:
- mountPath: /data
          name: spark
  volumes:
- name: spark
      persistentVolumeClaim:
        claimName: spark
EOF
$ kubectl create -f app.yaml
  1. 查看应用通过dataset可以访问的数据, 并且执行拷贝。可以发现拷贝1.4G数据(7个文件)花费了3分钟16秒。
$ kubectl exec -it-n development nginx --ls-ltr /data
total 2dr--r----- 1 root root 6 Dec  415:39 spark-3.1.3
dr--r----- 1 root root 7 Dec  415:39 spark-3.2.3
dr--r----- 1 root root 7 Dec  415:39 spark-3.3.1
$ kubectl exec -it-n development nginx --bashroot@nginx:/# time cp -R  /data/spark-3.3.1/* /tmpreal  3m16.761s
user  0m0.021s
sys 0m3.520s
root@nginx:/# du -sh /tmp/1.4G  /tmp/
root@nginx:/# du -sh /tmp/*348K  /tmp/SparkR_3.3.1.tar.gz
269M  /tmp/pyspark-3.3.1.tar.gz
262M  /tmp/spark-3.3.1-bin-hadoop2.tgz
293M  /tmp/spark-3.3.1-bin-hadoop3-scala2.13.tgz
286M  /tmp/spark-3.3.1-bin-hadoop3.tgz
201M  /tmp/spark-3.3.1-bin-without-hadoop.tgz
28M /tmp/spark-3.3.1.tgz
  1. 通过dataload对于指定数据集子目录进行加载
$ cat<<EOF >dataload.yaml
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: spark
  namespace: development
spec:
  dataset:
    name: spark
    namespace: development
  target:
- path: /spark-3.3.1
EOF
$ kubectl create -f dataload.yaml
  1. 查看dataload状态
$ kubectlget dataload -ANAMESPACE     NAME    DATASET   PHASE      AGE     DURATION
development   spark   spark     Complete   5m47s   2m1s
  1. 查看缓存效果, 可以看到38.4%的数据已经缓存完成
$ kubectlget dataset -n development
NAME    UFS TOTAL SIZE   CACHED    CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
spark   3.41GiB          1.31GiB   4.00GiB          38.4%               Bound   79m
  1. 再次拷贝1.4G数据仅耗时0.8秒不到1秒钟, 访问速度比之前的提升了245倍
$ kubectl exec -it-n development nginx --bashroot@nginx:/# time cp -R  /data/spark-3.3.1/* /tmpreal  0m0.872s
user  0m0.009s
sys 0m0.859s
root@nginx:/# du -sh /tmp/1.4G  /tmp/
root@nginx:/# du -sh /tmp/*348K  /tmp/SparkR_3.3.1.tar.gz
269M  /tmp/pyspark-3.3.1.tar.gz
262M  /tmp/spark-3.3.1-bin-hadoop2.tgz
293M  /tmp/spark-3.3.1-bin-hadoop3-scala2.13.tgz
286M  /tmp/spark-3.3.1-bin-hadoop3.tgz
201M  /tmp/spark-3.3.1-bin-without-hadoop.tgz
28M /tmp/spark-3.3.1.tgz
  1. 创建production命名空间
$ kubectl create ns production
  1. production 命名空间下,创建:

- 引用数据集spark,其mountPoint格式为dataset://${初始数据集所在namespace}/${初始数据集名称},  在本例子中初始dataset所在

注: 当前引用的数据集,只支持一个mount,且形式必须为dataset://(即出现dataset://和其它形式时,dataset创建失败),Spec中其它字段无效;

$ cat<<EOF >spark-production.yaml
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: spark
  namespace: production
spec:
  mounts:
- mountPoint: dataset://development/spark
EOF
$ kubectl create -f spark-production.yaml
  1. 查看数据集, 可以看到在production这命名空间下的spark数据集,并且都已经完成了数据缓存
$ kubectlkubectlget dataset -n production
NAME    UFS TOTAL SIZE   CACHED    CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
spark   3.41GiB          1.31GiB   4.00GiB          38.4%               Bound   14h
  1. 在production命名空间,创建Pod:
$ cat<<EOF >app-production.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: production
spec:
  containers:
- name: nginx
      image: nginx
      volumeMounts:
- mountPath: /data
          name: spark
  volumes:
- name: spark
      persistentVolumeClaim:
        claimName: spark
EOF
$ kubectl create -f app-production.yaml
  1. 在production命名空间访问数据的耗时也是0.878s,
$ kubectl exec -it-n production nginx --ls-ltr /data
total 2dr--r----- 1 root root 6 Dec  415:39 spark-3.1.3
dr--r----- 1 root root 7 Dec  415:39 spark-3.2.3
dr--r----- 1 root root 7 Dec  415:39 spark-3.3.1
$ kubectl exec -it-n production nginx --bashroot@nginx:/# ls -ltr /tmp/total 0root@nginx:/# time cp -R  /data/spark-3.3.1/* /tmpreal  0m0.878s
user  0m0.014s
sys 0m0.851s
root@nginx:/# du -sh /tmp1.4G  /tmp
root@nginx:/# du -sh /tmp/*348K  /tmp/SparkR_3.3.1.tar.gz
269M  /tmp/pyspark-3.3.1.tar.gz
262M  /tmp/spark-3.3.1-bin-hadoop2.tgz
293M  /tmp/spark-3.3.1-bin-hadoop3-scala2.13.tgz
286M  /tmp/spark-3.3.1-bin-hadoop3.tgz
201M  /tmp/spark-3.3.1-bin-without-hadoop.tgz
28M /tmp/spark-3.3.1.tgz

总结:

上面的例子展示了如何使用Fluid实现跨namespace共享数据集的能力,下一步Fluid会支持在Serverless Kubernetes上的跨Namespace数据集访问,实际上对于用户来说整个使用体验没有任何差别。

在近一步我们会支持Sub Dataset的能力,也就是将某个Dataset的子目录作为Dataset。能够实现同一套缓存,适合于不同的数据科学家,敬请期待。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
Prometheus Kubernetes 监控
Kubernetes 的 NameSpace 无法删除应该怎么办?
Kubernetes 的 NameSpace 无法删除应该怎么办?
|
Kubernetes Nacos 数据中心
k8s(9)Namespace(命名空间)
Namespace(命名空间)
621 0
|
2月前
|
人工智能 算法 调度
阿里云ACK托管集群Pro版共享GPU调度操作指南
本文介绍在阿里云ACK托管集群Pro版中,如何通过共享GPU调度实现显存与算力的精细化分配,涵盖前提条件、使用限制、节点池配置及任务部署全流程,提升GPU资源利用率,适用于AI训练与推理场景。
288 2
|
存储 Kubernetes 数据管理
Fluid 携手 Vineyard,打造 Kubernetes 上的高效中间数据管理
本文阐述了如何利用 Fluid 和 Vineyard 在 Kubernetes 上优化中间数据管理,解决开发效率、成本和性能问题。 Fluid 提供数据集编排,使数据科学家能用 Python 构建云原生工作流,而 Vineyard 通过内存映射实现零拷贝数据共享,提高效率。两者结合,通过数据亲和性调度减少网络开销,提升端到端性能。 同时通过一个真实事例介绍了安装 Fluid、配置数据与任务调度及使用 Vineyard 运行线性回归模型的步骤,展示了在 Kubernetes 上实现高效数据管理的实践方法。未来,项目将扩展至 AIGC 模型加速和 Serverless 场景。
391 0
|
9月前
|
存储 缓存 弹性计算
聚宽揭秘:为什么量化研究员喜欢在Kubernetes上使用Fluid简化数据管理?
通过引入阿里云的 ack-fluid 技术,基于 JindoRuntime 的分布式缓存加速,解决了多数据源、弹性扩展、动态挂载等挑战,显著提升了数据处理效率和资源利用率,降低运营成本。这一方案帮助量化研究员实现了更高效的开发和实验流程,为未来的优化和扩展奠定了基础。
|
JSON Kubernetes 数据格式
k8s集群namespace一直处于Terminating状态不释放解决办法
k8s集群namespace一直处于Terminating状态不释放解决办法
1177 0
|
存储 Kubernetes 调度
在k8S中,Pod如何实现数据持久化?数据共享?跨节点Pod如何实现数据共享?
在k8S中,Pod如何实现数据持久化?数据共享?跨节点Pod如何实现数据共享?
|
Kubernetes 前端开发 API
在K8S中,在容器内如何获取pod和namespace名字?
在K8S中,在容器内如何获取pod和namespace名字?
|
存储 Kubernetes 调度
在k8S中,共享存储的作用是什么?
在k8S中,共享存储的作用是什么?
|
Kubernetes API 容器
在K8s中,容器内如何获取pod和namespace名?
在K8s中,容器内如何获取pod和namespace名?

相关产品

  • 容器服务Kubernetes版
  • 推荐镜像

    更多