Fluid 助力阿里云 Serverless 容器极致提速-六虎

作者：东伝

背景

数据关于当今互联网业务的重要性不言而喻，它几乎渗透到了当今这个国际的每一个旮旯。但单有数据是不行的，真实让数据发生价值的，是针对各业务场景运转的对很多数据的密布剖析与核算，如机器学习、大数据剖析、OLAP 聚合剖析等等。近些年，跟着数据规模的增大，这些关于资源有着更高要求的数据密布运用自然地导向了以弹性资源著称的云服务。

在这种数据密布运用上云的趋势下，Serverless 好像并不是这个趋势的明显受益者。尽管几乎所有人都对这种核算资源无限扩容、弹性敏捷交给、低运维本钱的架构不惜赞许之词，但因为它将核算存储分离的架构面向了一个更朴实的极端，具有强数据依赖的数据密布运用想要高效运转于 Serverless 环境变得极其困难。

举例来说，假如咱们想将 AI 推理服务运用布置在 Serverless 架构下，每个服务运用发动前必须将存放在外部存储体系的 AI 模型首先拉取到本地内存中。考虑到近年来 AI 大模型现已成为业界干流，让咱们假设这个 AI 模型的巨细为 30GB，而且存储于 OSS 目标存储服务中，假如需求同时发动 100 个这样的 AI 推理服务运用，那么一共的数据读取量便是 3000GB。OSS 存储默许的数据拜访限速是 10Gbps，这就意味着 100 个运用都需求等候 2400 秒（3000GB * 8 / 10Gbps） 才可以真实开端对外供给服务。假如每个服务咱们创立一个 ecs.gn7i-c32g1.16xlarge 的实例（按每小时单价折算每秒0.008 元），这意味着光在等候数据上就现已花掉了 1920 元（0.008 元/秒* 2400 秒* 100） 。总结来说，咱们很多的费用没有花在发生价值的核算上，这显然不是咱们想要的。（*实践价格以阿里云官网显现为准）

那么，有没有什么办法可以优化上述进程？这就引进了本文的主角：Fluid。Fluid 是一个 Kubernetes 原生的分布式数据集编排和加快引擎。Fluid 诞生的初衷即是为运用的数据拜访延时问题供给云原生的解决方案。关于困扰着 Serverless 数据密布运用的上述相关问题，Fluid 在保证用户简略易用的运用体验前提下，给出了一套 Serverless 环境新的数据拜访架构方案，协助用户提高数据拜访功率。

本文将 step by step 地介绍 Fluid 的运转示例，协助咱们了解如何在阿里云 ASK（Alibaba Serverless Kubernetes）环境中运用 Fluid，展现如何借助 Fluid 完成 zero to zero 的（从零资源运用开端到悉数资源释放结束）规模化数据密布型使命履行形式，并获得降本提速的作用。

Fluid on ASK 运转示例

Fluid 数据编排加快 Serverless Kubernetes 功能尚处于公测阶段，可点击阅览原文请求体验座位。

Fluid 布置

在运转以下示例前，首先需求搭建一个 ASK 集群，并装备好连接该集群的 Kubeconfig。相关进程可参阅文末文档《如何创立 ASK 集群》 。在运用 Fluid 的各项功能前，需求将 Fluid 的各控制面组件布置到 ASK 集群中。这个布置进程可以经过阿里云容器服务-Kubernetes 控制台轻松完结。

如下图所示：

挑选 ASK 集群面板右侧的“运用-Helm”子面板
点击”创立”按钮
在 Chart 商场中搜索 ack-fluid 即可找到 Fluid 对应的 Helm Chart，填写“运用名”（例：ack-fluid)。
点击“下一步”后，挑选运用默许的 fluid-system 作为布置的命名空间
接着无需对 Chart Values 进行任何修改，直接点击“确定”，即可将 Fluid 布置到 ASK 集群中。

在装备完 ASK 集群对应的 Kubeconfig 信息后，输入以下指令：

$ kubectl get pod -n fluid-system

可以观察到 Fluid 的几个组件现已正常运转起来：

NAME                                  READY   STATUS    RESTARTS   AGE
dataset-controller-d99998f79-dgkmh    1/1     Running   0          2m48s
fluid-webhook-55c6d9d497-dmrzb        1/1     Running   0          2m49s

其中：

Dataset Controller：担任保护各个 Fluid 所引进的 Dataset CRs 的完好生命周期。
Fluid Webhook:担任对用户需求拜访数据的运用 Pod 进行自动化变换（Mutation），无感知地协助用户完成 Serverless 场景的数据拜访功能。

除了上述描绘的两个组件外，Fluid 的控制面仍然包含了一些与各类缓存体系（例如：JindoFS、JuiceFS、Alluxio 等）严密相关的控制器组件，这些组件在初始布置状况下不会创立，仅当用户指定需求运用某种缓存体系时，与其相相关的缓存体系控制器组件 Pod 才会按需扩容，然后在按量付费的 ASK 环境中尽可能地协助用户节约本钱。

数据缓存布置

Fluid 国际中的悉数都以 Dataset 这一自定义资源为中心：无论是对外部存储中已有数据的笼统办理仍是运用 Pod 的数据拜访，用户都需求和 Dataset 资源进行交互。每当用户创立一个 Dataset CR 并指定了它的缓存体系后端，Fluid 就会自动地将数据缓存布置到 Kubernetes 集群中。

在下面的实践进程中，咱们以阿里云 OSS 目标存储作为外部存储体系为例，模拟一个完好的“缓存布置-数据拜访-资源收回”的标准数据运用进程。

数据文件预备

首先，预备一个待拜访的文件。例如，这儿咱们运用 dd 指令快速创立一个巨细约为 30G 的文件：

$ cd $(mktemp -d)

$ dd if=/dev/zero of=./largefile-30G bs=10M count=3072
3072+0 records in
3072+0 records out
32212254720 bytes (32 GB) copied, 108.189 s, 298 MB/s

$ ls -lh ./largefile-30G 
-rw-r--r-- 1 root root 30G Sep  7 21:11 ./largefile-30G

接着，把上述创立的待拜访文件上传到 OSS Bucket 中，这儿以一个坐落 Beijing Region 的名为 fluid-demo 的 OSS Bucket 为例。

$ ossutil cp -i <access_key_id> -k <access_key_secret> -e oss-cn-beijing-internal.aliyuncs.com ./largefile-30G oss://fluid-demo/

创立 Fluid Dataset 和 Runtime 资源

数据预备和上传后，即可在 Fluid 中声明上述待拜访的数据。详细而言，咱们需求提交一个 Dataset CR 和一个 Runtime CR。Dataset CR 中描绘数据在外部存储体系中的 URL 位置，Runtime CR 描绘缓存体系及体系详细装备。

首先，把拜访 OSS Bucket 所需的身份凭据信息存储于 Secret 中：

$ kubectl create secret generic oss-access-key \
  --from-literal=fs.oss.accessKeyId=<access_key_id> \
  --from-literal=fs.oss.accessKeySecret=<access_key_secret>

接着，定义 Dataset CR 和 Runtime CR。这儿咱们挑选 JindoFS 作为缓存体系后端，Fluid Runtime 资源为 JindoRuntime:

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  mounts: 
    - mountPoint: oss://fluid-demo # OSS Bucket URL
      name: demo
      path: /
      options:
        fs.oss.endpoint: oss-cn-beijing-internal.aliyuncs.com # OSS Bucket内网拜访端点
      encryptOptions:
        - name: fs.oss.accessKeyId
          valueFrom:
            secretKeyRef:
              name: oss-access-key
              key: fs.oss.accessKeyId
        - name: fs.oss.accessKeySecret
          valueFrom:
            secretKeyRef:
              name: oss-access-key
              key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo-dataset
spec:
  # 缓存Worker节点数量
  replicas: 5
  podMetadata:
    annotations:
      # 挑选JindoFS Pod运用的实例标准
      k8s.aliyun.com/eci-use-specs: ecs.d1ne.6xlarge
      # 启用实例镜像缓存，加快Pod发动进程
      k8s.aliyun.com/eci-image-cache: "true"
  tieredstore:
    levels:
      # 以40GiB的内存作为每个缓存Worker节点的缓存介质
      - mediumtype: MEM
        volumeType: emptyDir
        path: /dev/shm
        quota: 40Gi
        high: "0.99"
        low: "0.99"

创立上述 Dataset CR 和 JindoRuntime CR 到 ASK 集群：

$ kubectl create -f dataset.yaml

检查 Dataset 布置状况

Dataset CR 和 JindoRuntime CR 创立后，约 1 到 2 分钟后，Dataset 将布置完结，届时可以检查到与缓存体系以及后端存储体系中数据的相关信息。

$ kubectl get dataset demo-dataset
NAME           UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo-dataset   30.00GiB         0.00B    200.00GiB        0.0%                Bound   2m9s

例如，上方示例展现了 FluidDataset 的相关信息

OSS 中数据集总巨细(UFS TOTAL SIZE)：30.00GiB
当前缓存量（CACHED）：0.00B
缓存体系容量（CACHE CAPACITY）：200.00GiB
数据集缓存百分比（CACHED PERCENTAGE）：0.0%
Dataset 状况（PHASE）：Bound，表明已成功布置。

数据缓存预热

Fluid 完成的 Kubernetes 集群内数据拜访加快不是什么 Magic Trick：其本质是经过数据分流（Data Offloading） 来下降中心存储的拜访压力：Fluid 会把需求拜访的数据缓存到与运用 Pod 更近的分布式缓存体系（例如：JindoFS、JuiceFS、Alluxio 等）中，所以，与缓存体系坐落同一 VPC 网络的运用 Pod，就可以以远比直接拜访中心存储带宽更高的 VPC 内网带宽进行数据拜访。进一步地，因为对接的是分布式缓存体系，所以当单个缓存体系 Worker 节点供给带宽缺乏时，可将分布式缓存体系扩容，然后完成数据拜访带宽的弹性弹性，匹配 Serverless 场景下的核算资源弹性。

因此，为了经过数据分流完成高带宽数据拜访，在运用 Pod 进行数据拜访前履行数据缓存预热是一个“磨刀不误砍柴工”的必要操作。

创立DataLoadCR

在 Fluid 中履行数据缓存预热只需创立如下的 DataLoad CR：

apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
  name: demo-dataset-warmup
spec:
  # 指定需求预热的Dataset
  dataset:
    name: demo-dataset
    namespace: default
  loadMetadata: true
  target:
    - path: / # 指定预热的数据子途径，“/”表明预热整个数据集
      replicas: 5 # 预热后数据在缓存体系中的副本数量

$ kubectl create -f dataload.yaml

检查预热后 Dataset 状况

检查 DataLoad CR 状况，直至其 PHASE 变为 Complete 状况：

$ kubectl get dataload demo-dataset-warmup
NAME                  DATASET        PHASE      AGE     DURATION
demo-dataset-warmup   demo-dataset   Complete   2m38s   2m20s

经过 Duration 可以检查数据预热消耗的时刻，上述示例中预热耗时为 2m20s。

在数据缓存预热完结后，Dataset 上相关的缓存状况也会随即更新：

$ kubectl get dataset demo-dataset
NAME           UFS TOTAL SIZE   CACHED      CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo-dataset   30.00GiB         150.00GiB   200.00GiB        100.0%              Bound   8m27s

可以看到，数据预热完结后，整个数据集都现已被缓存在了分布式缓存体系中，缓存比例 100.0%，因为预热时指定了预热的缓存副本数量为 5，预热后缓存占用总量为数据集巨细的 5 倍。

注：添加缓存副本数量有助于减轻数据拜访时对分布式缓存 Worker 节点的单点拜访功能瓶颈。

数据拜访

紧接着，尝试创立运用 Pod 来拜访 OSS 中的数据。咱们将会一次性拉起 100 个运用 Pod，让这些 Pod 同时拜访 OSS 中的数据文件。这样的数据读取形式在 AI 推理服务弹性扩容、自动驾驶仿真等详细场景中都非常常见。

创立数据拜访运用

例如：下面是一个 Argo Workflow 运用示例：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: parallelism-fluid-
spec:
  entrypoint: parallelism-fluid
  # Argo Workflow Task最大并发数，即同时发动100个Pod
  parallelism: 100
  podSpecPatch: '{"terminationGracePeriodSeconds": 0}'
  podMetadata:
    labels:
      # 添加如下label翻开Fluid对Serverless场景的数据拜访支持
      alibabacloud.com/fluid-sidecar-target: eci
    annotations:
      # 启用实例镜像缓存，加快Pod发动进程
      k8s.aliyun.com/eci-image-cache: "true"
      # 挑选Argo Workflow Pod运用的实例标准
      k8s.aliyun.com/eci-use-specs: ecs.g6e.4xlarge
  templates:
  - name: parallelism-fluid
    steps:
    - - name: domd5sum
        template: md5sum
        withSequence:
          start: "1"
          end: "100"
  - name: md5sum
    container:
      imagePullPolicy: IfNotPresent
      image: alpine:latest
      # 每个pod核算待读取文件的md5sum
      command: ["/bin/sh", "-c", "md5sum /data/largefile-30G"]
      volumeMounts:
      - name: data-vol
        mountPath: /data
    volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: demo-dataset # claimName须与Fluid Dataset名字一致

$ argo submit workflow.yaml

检查数据拜访运用状况

上述示例的 Argo Workflow 将会一次性拉起 100 个 Pod 进行并行数据拜访。待上述 100 个 Pod 悉数完结后，可以看到如下结果：

$ argo list
NAME                      STATUS      AGE   DURATION   PRIORITY
parallelism-fluid-x677t   Succeeded   8m    5m         0

检查使命的详细信息：

$ argo get parallelism-fluid-x677t
Name:                parallelism-fluid-x677t                                                                                                                      
Namespace:           default                                                                                                                                      
ServiceAccount:      unset (will run with the default ServiceAccount)                                                                                             
Status:              Succeeded                                                                                                                                    
Conditions:                                                                                                                                                       
 PodRunning          False
 Completed           True
Created:             Wed Sep 07 21:25:30 +0800 (7 minutes ago)
Started:             Wed Sep 07 21:25:30 +0800 (7 minutes ago)
Finished:            Wed Sep 07 21:31:28 +0800 (1 minute ago)
Duration:            5 minutes 58 seconds
Progress:            100/100
ResourcesDuration:   8h10m22s*(1 alibabacloud.com/vfuse),24h15m6s*(1 cpu),24h15m6s*(100Mi memory)
STEP                        TEMPLATE           PODNAME                             DURATION  MESSAGE
 ✔ parallelism-fluid-x677t  parallelism-fluid                                                   
 └─┬─✔ domd5sum(0:1)        md5sum             parallelism-fluid-x677t-2855796525  5m          
   ├─✔ domd5sum(1:2)        md5sum             parallelism-fluid-x677t-1226856655  5m          
   ├─✔ domd5sum(2:3)        md5sum             parallelism-fluid-x677t-2858910973  5m          
   ├─✔ domd5sum(3:4)        md5sum             parallelism-fluid-x677t-2609269875  4m          
   ├─✔ domd5sum(4:5)        md5sum             parallelism-fluid-x677t-616770109   5m          
   ├─✔ domd5sum(5:6)        md5sum             parallelism-fluid-x677t-3071900311  5m          
   ├─✔ domd5sum(6:7)        md5sum             parallelism-fluid-x677t-3841084237  5m          
   ├─✔ domd5sum(7:8)        md5sum             parallelism-fluid-x677t-120540963   5m          
   ├─✔ domd5sum(8:9)        md5sum             parallelism-fluid-x677t-1353329645  5m          
   ├─✔ domd5sum(9:10)       md5sum             parallelism-fluid-x677t-2391364586  5m          
   ├─✔ domd5sum(10:11)      md5sum             parallelism-fluid-x677t-4083824607  5m          
   ├─✔ domd5sum(11:12)      md5sum             parallelism-fluid-x677t-258640575   5m          
   ├─✔ domd5sum(12:13)      md5sum             parallelism-fluid-x677t-3913466863  5m          
   ├─✔ domd5sum(13:14)      md5sum             parallelism-fluid-x677t-1949266799  5m          
   ├─✔ domd5sum(14:15)      md5sum             parallelism-fluid-x677t-214569823   5m          
   ├─✔ domd5sum(15:16)      md5sum             parallelism-fluid-x677t-684353087   5m

可以看到，整个使命的运转时长为 5m58s。

资源收回

数据缓存资源收回

用户可以在不再需求数据缓存时，将缓存从 ASK 集群中收回以节约集群资源并下降本钱。Fluid 中关于缓存体系的收回仅需求将相关的 Fluid Dataset 删去，例如：

$ kubectl delete dataset demo-dataset

履行上述删去指令后等候一段时刻（Fluid 将会进行一些清理工作），缓存体系的相关 Pod 都会被收回。

Fluid 控制面组件收回

在缓存体系相关 Pod 收回后，用户同样可以试状况收回控制面组件占用的资源。履行下面的脚本，缩容控制面组件。

$ kubectl get deployments.apps -n fluid-system | awk 'NR>1 {print $1}' | xargs kubectl scale deployments -n fluid-system --replicas=0

当再次需求运用 Fluid 时，履行下面的扩容指令，创立新的控制面组件 Pod 即可：

$ kubectl scale -n fluid-system deployment dataset-controller --replicas=1
$ kubectl scale -n fluid-system deployment fluid-webhook --replicas=1

方案作用

屡次运转上述示例，并调整缓存体系 Worker 的数量（5 个或 10 个）或挑选直接拜访 OSS 目标存储，咱们得到了如下作用数据：

作用 1：可弹性弹性的数据拜访带宽

图 1缓存/存储体系供给的有用数据拜访带宽比照

依据数据拜访运用的整体耗时、拜访的数据文件巨细以及数据拜访的 Pod 数量，咱们可以核算出图 1 中的“有用数据拜访带宽*”功能体现。从图 1 来看，比较于 OSS 存储体系供给的默许带宽（10Gbps），F luid 的数据分流机制可以为 Serverless 运用供给更大的有用拜访带宽，而且该带宽可经过添加缓存 Worker 节点数量弹性提高。

*有用数据拜访带宽=Serverless 数据拜访Pod 数量x每 Pod 拜访的数据量/数据拜访运用整体耗时

作用 2：因数据拜访加快而下降的费用本钱

图 2直接拜访OSSvs.Fluid 本钱比照

上述示例中咱们运用如下的 ECI 实例标准：

Argo Workflow 使命 Pod：ecs.g6e.4xlarge (每秒单价 0.0012 元)
缓存体系 Pod：ecs.d1ne.6xlarge (每秒单价 0.0056 元)

由此可核算得到“图 2 直接拜访 OSS vs. Fluid 本钱比照”。观察图 2 不难发现，经过 Fluid 拜访 OSS 中的数据可以将本钱削减为本来的约六分之一到八分之一。别的，在同样运用 Fluid 拜访数据的前提下，运用更多的缓存 Worker 节点可以节约更多本钱。这背面的首要原因是Fluid 供给了更大的数据拜访带宽，然后使得数据拜访功能提高，缩短了运用花在数据读取上的时刻（见图 3），然后使得购买的 Serverless 弹性算力真实做到物尽其用。

图 3ArgoWorkflow 使命耗时比照

总结

本文展现了一个在 ASK 环境中运转 Fluid 的完好数据拜访示例，希望可以协助咱们了解 Fluid 的运用体验、运转作用以及 Serverless 和数据密布型运用结合的更多可行性。详细而言，咱们看到：

用户运用 Fluid 拜访数据是简略易用的：用户只需求把本来拜访 OSS 的 PVC 修改为 Fluid Dataset 对应的 PVC。
Fluid 可以供给可弹性弹性的数据拜访带宽，协助规模化的数据拜访运用提高数据读取功率。
因为数据读取功率的提高，Fluid 可以协助规模化的数据拜访运用大幅下降费用本钱。

参阅链接

[1] 如何创立 ASK 集群：

help.aliyun.com/document_de…

[2] ACK 云原生 AI套件概况：

help.aliyun.com/document_de…

[3] Fluid 项目 github 地址：

github.com/fluid-cloud…

点击此处，请求 ACK 云原生 AI 套件免费体验座位！

Fluid 助力阿里云 Serverless 容器极致提速

背景

Fluid on ASK 运转示例

Fluid 布置

数据缓存布置

数据缓存预热

数据拜访

资源收回

方案作用

作用 1：可弹性弹性的数据拜访带宽

作用 2：因数据拜访加快而下降的费用本钱

总结

参阅链接

相关文章

王者荣耀吕布末日机甲皮肤优化了，我们来用css3给他写一个回城特效

分布式向量检索引擎

Android性能优化 — RecyclerView分页加载组件

目标检测模型的评价标准-AP与mAP

作者信息