共计 8544 个字符，预计需要花费 22 分钟才能阅读完成。
作者：车漾、刘奖、景奇
随着 IT 基础设施从物理机到虚拟机，再到以 Kubernetes 为代表的容器环境，甚至到 Serverless 的逐步演进，明天的计算和利用的状态以日新月异的速度倒退。尤其是 AI 和数据分析等数据智能利用的 Serverless 化曾经成为了一种趋势。Gartner 曾预测，到 2023 年 70% 的 AI 利用将基于容器和 Serverless 技术开发。这是大家置信的将来，但利用 Serverless 化之路充斥艰苦，比方现有 利用迁徙门槛高，供应商锁定，基础设施响应能力有余，可观测性欠缺，存储接入繁琐 等。
这些都是用户对于 Serverless 根底平台提供商的刚性需要，谁能更加凋谢，谁能更好提供 Serverless 利用所运行的基础设施和生态系统，谁能力成为客户的最终抉择，而不仅仅是谁提供的计算资源弹性能力更强或者老本更低，这理论是云计算巨头的内功较量。
（图片来源于网络）
本文首先聚焦到 AI 和大数据等利用 Serverless 化的最大挑战：计算和存储拆散架构带来的 数据拜访提早 和近程拉取 数据带 宽 微小 的挑战。尤其在 GPU 深度学习训练场景中，迭代式的近程读取大量训练数据办法会重大拖慢 GPU 计算效率。
Serverless 的数据拜访挑战
Serverless 云平台对用户提供的外围能力就是极致弹性，然而这里探讨的弹性并不只是资源弹性，而是站在用户视角的利用弹性或者说业务弹性，即从用户决定扩容开始到利用真正就绪提供服务的端到端工夫。资源弹性工夫是其中很重要的局部，计算资源可能实现秒级，甚至毫秒级扩容，相干基础设施就很快会面临微小的压力，其中最常见的基础设施就是存储。如果存储系统的 IO 吞吐能力跟不上实例变动的速度，例如对于业务来说，容器实例 2 秒就实现了扩容，但还须要花几十秒钟甚至几分钟期待从存储下载数据，那么极致弹性也就无从谈起。
应该说 Serverless 容器化的技术体系对于传统的存储系统提出了新的挑战：
1. 高密拜访：
计算资源无存储能力，数据齐全下沉到存储系统，导致并发数据拜访压力陡增。这一方面影响存储系统的稳定性，另一方面也会打满存储系统服务带宽。
2. 网络延时:
计算存储拆散架构拉长了存储拜访链路，跨网络通信数据和元数据拜访的额定提早。
3. IO 吞吐能力的扩容老本高：
传统分布式存储带宽与吞吐仅和数据应用容量成正比，而 Serverless 平台会创立大量的容器并发的拜访存储系统的数据，会触发存储系统拜访限流。这就造成计算资源极致弹性与存储系统无限带宽之间的矛盾。
换而言之，Serverless 的大数据和 AI 场景须要数据分流（Data Offloading），缩短数据读取链路和提供弹性的 IO 吞吐能力。然而思考到现有云存储系统的稳定性，老本和通用性，这个架构演进会是一个任重道远的工作。
Fluid：利用应用数据过程的形象
Fluid 是云原生计算基金会（CNCF）旗下的官网沙箱开源我的项目。该开源我的项目定位于面向云原生场景下的数据密集型利用减速和编排，社区次要开发者和维护者来自阿里巴巴、南京大学等多家知名企业和高校。Fluid 的思路是将存储系统的能力进行分层，合成为数据存储和数据拜访能力，并且将一部分的数据拜访能力向上平移到计算集群中；并且在大数据（AI）场景下，对“计算工作应用数据的过程”进行形象，提出了弹性数据集 Dataset 的概念，并将数据分布式缓存技术与 云原生 主动弹性（Autoscaling），可迁徙（Portablity），可调度（Scheduling） 能力相结合。
Fluid 我的项目地址：
https://github.com/fluid-clou…
数据拜访能力向上平移的益处是能够利用计算集群中闲置的资源，通过分布式数据缓存能力一方面提供数据分流升高核心存储压力，另一方面利用数据本地性，VPC 网络性能劣势和数据拜访复用的个性，缩短数据拜访门路，晋升性能；通过 Dataset 的形象，在特定语境下，依据利用的需要定义数据拜访的范畴，特色以及弹性，并且依据这些个性进行特定性能优化。
All problems in computer science can be solved by another level of indirection
实际上 Fluid 还是遵循计算迷信中的所有问题都能够通过减少一层形象来解决的准则，在 Kubernetes 为代表的计算集群提供数据拜访编排层 Dataset 形象, 实现 Dataset 治理（CRUD 操作）、数据预热，数据备份 / 复原权限管制和拜访减速等能力，Fluid 的架构能够通过 CacheRuntime plugin 的形式，扩大兼容多种分布式缓存服务。目前曾经反对了阿里云 EMR 的 JindoFS，开源的 Alluxio，Juicefs 等缓存引擎, 而对于用户来说这是一个通明的体验。
没有银弹，Fluid 的本质是利用计算集群的闲暇资源（CPU，Memory，Disk）和特定场景的形象假如简化问题，通过 数据分流（Data Offloading ） 升高核心存储的压力；就近缓存（Tiered Locality Cache） 和 亲和性调度（Cache Locality Scheduling） 晋升数据拜访性能；在计算资源高并发拜访数据的时候，通过自动化扩容缓存集群提供 弹性 IO 吞吐能力。
在此基础上，Fluid 反对数据弹性和可操作性，可能依据计算吞吐需要实现：
- 数据集的可伸缩性——Fluid 反对 Runtime 弹性伸缩的模式，通过管制缓存 worker 的数量实现弹性伸缩。
- 数据汇合的可操作性——Fluid 反对通过 Dataload CRD 来进行多种模式的预热，包含指定文件列表、文件夹的元数据进行预热。
从下到上优化，Fluid 拥抱阿里云 ECI
因而如何将分布式缓存引擎落地到 Serverless 容器化平台就成了一个挑战。而其中的关键问题是如何可能 平安，凋谢，灵便 的在 Serverless 容器化平台中运行。将 Fluid 开源软件与 Serverless 平台相结合减速利用拜访数据性能在业界是第一次尝试，须要单方相向而行，独特定义合作的界面和权责, 否则扭转不会产生。Fluid 须要尊重 Serverless 平台的概念模型和生命周期（比方一个 Pod 占用一个虚拟机的模式），Serverless 平台须要提供基于肯定规范的最小开放性。
这背地次要有三个问题：
- 协定与分工界面不清：Serverless 平台是黑盒零碎，运行时反对都是由平台提供商开发的，对于 Kubernetes 生态的反对并不欠缺。比方少数 Serverless 不反对社区广泛支持的 CSI Plugin、Device Plugin 机制等。传统的形式是将各种存储系统客户端注入 Serverless Pod 运行的虚拟机镜像，但这就要面对虚拟机镜像治理就要面对绑定重大，降级艰难，镜像臃肿等问题，同时软件问题排查时边界不清。
- 平安危险和开放性的均衡：Serverless 平台肯定是多租户的，因而平台安全性是生命线。然而 Serverless 赋能更多场景，就须要反对更多的开源软件，而这时肯定会引入更多个攻击面；因而须要认真的衡量二者之间关系。这十分考验平台的硬核实力，也须要软件供应链的控制能力。
- 分布式与 Serverless 之间的抵触: Serverless 利用假如执行的是简略的、独立的工作，相互间不通信，同时计算工作齐全无状态；生命周期治理也要差别。然而，Fluid 自身是要通过分布式缓存零碎实现提速的。这里波及到的分布式（网络通信），有状态（缓存），生命周期一致性，又是一个矛盾点。
为了反对 Serverless 场景，阿里云容器服务团队，根底软件和操作系统团队，弹性计算 ECI 团队，数据湖存储团队联合作战，提供了从底到顶的残缺解决方案。解决问题的基本思路是对不同的问题分而治之，而准则是：
- 拥抱已有规范，比方通过 Kubernetes 中 Sidecar，Device Plugin 等规范作为凋谢接口。保障用户一致性体验。
- 精细化 Linux 特权管制
- 关注点拆散，让不同的角色关注本人的能力，存储和计算能够并行演进。
最终的计划是：通过 Sidecar 机制通明替换 Perstistent Volume Claim，并且对于现有 FUSE 计划 进行平安加固；同时将分布式缓存和弹性能力运行在 ServerFull 节点（ECS）；另外针对蕴含 Sidecar 的工作利用进行非凡的反对。
价值
凋谢规范
对于存储能力提供方，存储组件无需与 Serverless 平台间接对接，由开源的 Fluid 表演适配角色，规范公开同时升高计算平台保护存储客户端的复杂度。对于用户来说，以 sidecar 模式运行存储客户端，云上和云下应用体验基本一致, 同时无需放心平台绑定。
关注点拆散
关注点拆散是 Fluid 用来解决存储能力提供者与 Serverless 平台团队不足责任分层的窘境。
对于 存储能力提供团队，不须要将存储客户端以安装包的形式加载到虚拟机，这样就能够独立迭代本身能力，无需依赖 Serverless 平台团队虚拟机镜像公布节奏；同时问题排查时也无需期待 Serverless 平台团队收集日志，晋升了问题诊断和修复的效率。
对于 Serverless 平台团队，存储组件作为 sidecar 存在，减小的虚拟机镜像中软件的复杂度和大小，同时也防止了频发公布虚拟机镜像引入的稳定性危险，升高了问题排查的复杂度。
弹性
能够与分布式存储相结合，通过用户应用本身计算集群的资源，按需的实现吞吐能力扩容。一方面为用户提供了弹性按 IO 需要付费的抉择，也升高了存储的老本压力。
平安
通过精细化特权管制，实现 Serverless 下肯定的水平实现能力分层，在凋谢的前提下为底层平台提供平安保障。
可观测
传统存储客户端以过程形式运行在 Serverless 平台中，衰弱状态和资源耗费都是黑盒；存储客户端问题排查也须要依赖 Serverless 平台运维，而新的模式下，存储客户端以容器的状态运行，提供了残缺的可观测性。
疾速体验
该试验模仿模型推理服务启动时下载并且初始化模型。
前置条件
- 领有一个阿里云容器服务 ACK Pro 集群，并且 K8s 版本号≥1.18
- 集群中有虚构节点，如无可参考 ACK Virtual Node 装置，详见：https://help.aliyun.com/docum…
- 开明云原生 AI 套件，并装置降级 Fluid 到最新版本，详见：https://help.aliyun.com/docum…
操作步骤
- 查看 Fluid 是否装置胜利以及版本是否是最新：
$ helm list -n fluid-system
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
ack-fluid fluid-system 1 2022-08-13 16:05:47.540883158 +0800 CST deployed ack-fluid-0.8.1 0.8.0-50edf67- Fluid 依赖 Webhook 机制注入 Serverless 依赖的 sidecar
$ kubectl label namespace default fluid.io/enable-injection=true- 查看 namespace 的标签是否胜利关上
$ kubectl get namespace default --show-labels
NAME STATUS AGE LABELS
default Active 5h28m fluid.io/enable-injection=true- 创立数据集和缓存运行时
本示例应用 JindoFS 作为数据集的缓存引擎并挂载一个 OSS Bucket，OSS Bucket 中存储着利用须要拜访的数据集。该 OSS Bucket 位于北京地区，Bucket 名为 large-model-sh。在理论应用中，请依据理论应用的 OSS Bucket 属性进行批改。
4.1 创立 Secret 加密 Access Key
$ cat << EOF > secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: access-key
stringData:
fs.oss.accessKeyId: <YOUR_ACCESS_KEY_ID>
fs.oss.accessKeySecret: <YOUR_ACCESS_KEY_SECRET>
EOF4.2 上述例子中的 Access Key 可在 RAM 访问控制页面查问
$ kubectl create -f secret.yaml4.3 创立 Dataset 和 JindoRuntime
$ cat << EOF > dataset.yaml
apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
name: serverless-data
spec:
mounts:
- mountPoint: oss://large-model-sh/
name: demo
path: "/"
options:
fs.oss.endpoint: oss-cn-beijing-internal.aliyuncs.com
encryptOptions:
- name: fs.oss.accessKeyId
valueFrom:
secretKeyRef:
name: access-key
key: fs.oss.accessKeyId
- name: fs.oss.accessKeySecret
valueFrom:
secretKeyRef:
name: access-key
key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
name: serverless-data
spec:
replicas: 1
tieredstore:
levels:
- mediumtype: MEM
path: /dev/shm
quota: 10Gi
high: "0.95"
low: "0.7"
EOF相干参数：
4.4 执行以下步骤
$ kubectl create -f dataset.yaml4.5 查看 Dataset 状态：
$ kubectl get dataset serverless-data
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
serverless-data 1.16GiB 0.00B 10.00GiB 0.0% Bound 80s4.6 对应会创立 pvc
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
serverless-data Bound default-serverless-data 100Gi ROX fluid 91s- 创立基于 ECI 的 Deployment 拜访数据集
$ cat << EOF > serving.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: model-serving
spec:
selector:
matchLabels:
app: model-serving
template:
metadata:
labels:
app: model-serving
alibabacloud.com/fluid-sidecar-target: eci
alibabacloud.com/eci: "true"
annotations:
k8s.aliyun.com/eci-use-specs: ecs.s6-c1m2.xlarge
spec:
containers:
- image: fluidcloudnative/serving
name: serving
ports:
- name: http1
containerPort: 8080
env:
- name: TARGET
value: "World"
volumeMounts:
- mountPath: /data
name: data
volumes:
- name: data
persistentVolumeClaim:
claimName: serverless-data
EOF- labels 中 alibabacloud.com/eci: “true” 示意该容器以 ECI 容器形式启动
- labels 中 alibabacloud.com/fluid-sidecar-target “eci” 告知 Fluid 该 Pod 以 Serverless 形式启动，Fluid 会利用 Webhook 主动向利用 Pod 注入 Fuse 容器，让利用 Pod 可通过 POSIX 接口拜访数据集
- annotations 中的 k8s.aliyun.com/eci-use-specs 示意应用的 ECI 实例规格
- 创立 Deployment
$ kubectl create -f serving.yaml- 查看启动日志，能够看到启动加载数据的工夫是 64s
$ kubectl logs model-serving-546578c447-5x6fm -c serving
Begin loading models at 16:35:38
real 1m4.999s
user 0m0.000s
sys 0m1.143s
Finish loading models at 16:36:43
2022-08-13 16:36:43 INFO Hello world sample started.8. 删除该服务
$ kubectl delete -f serving.yaml- 预热缓存数据, 该步骤不是必须执行的操作
$ cat<<EOF >dataload.yaml
apiVersion: data.fluid.io/v1alpha1
kind: DataLoad
metadata:
name: serverless-data-warmup
spec:
dataset:
name: serverless-data
namespace: default
EOF执行 Dataload, 并查看缓存成果。能够看到 1.2G 数据曾经齐全缓存了。
$ kubectl create -f dataload.yaml
dataload.data.fluid.io/serverless-dataload created
$ kubectl get dataload
NAME DATASET PHASE AGE DURATION
serverless-dataload serverless-data Complete 2m43s 34s
$ kubectl get dataset
NAME UFS TOTAL SIZE CACHED CACHE CAPACITY CACHED PERCENTAGE PHASE AGE
serverless-data 1.16GiB 1.16GiB 10.00GiB 100.0% Bound 19m- 再次创立该服务
$ kubectl create -f serving.yaml此时查看启动工夫发现以后启动加载数据的工夫是 6.263s，变成没有预热的状况下耗时的 1/10，速度晋升了 10 倍
kubectl logs model-serving-546578c447-pkcpf -c serving
Begin loading models at 17:18:54
real 0m6.263s
user 0m0.000s
sys 0m0.998s
Finish loading models at 17:19:00
2022-08-13 17:19:04 INFO Hello world sample started.更多应用办法请参考文档：
https://help.aliyun.com/docum…
瞻望
Fluid 与 Serverless 场景的联合只是刚刚开始，和 Serverless 同行（With the Serverless），与 Serverless 合作（On the Serverless），服务好 Serverless（For the Serverless）。在第一阶段，咱们与 JindoFSX Runtime 一起实现了 Serverless 无缝对接，后续咱们也会反对开源社区的 JuiceFS，Alluxio；同时咱们在内核和容器层面的批改也会奉献到社区，一起推动 Serverless 平台的扭转。
致谢
Fluid 反对 Serverless 的工作感激来自阿里云，南京大学，Juicedata，哔哩哔哩的小伙伴们共同努力，这是 Serverless 反对数据场景的第一步，咱们一起加油来让云的世界更加美妙。如果您有趣味也能够钉钉搜寻群号：32850151，退出 Fluid 开源社区技术交换群。如果您认为 Fluid 有用的话，欢送与感谢您给 Fluid 我的项目一个 star。
Fluid 的代码仓库地址为：
https://github.com/fluid-clou…
作者简介：
车漾，阿里云容器服务高级技术专家
刘奖，阿里云操作系统部资深技术专家
景奇，阿里云弹性计算技术专家
如何高效调度 AI 和大数据作业？怎么进步 GPU 等资源效率和弹性？快来尝试 ACK 云原生 AI 套件 吧！基于规范 Kubernetes，提供组件化、可扩大、可灵便组合和定制的云原生 AI 能力，全栈优化 AI 性能、效率和老本，助力企业级用户疾速定制化构建 AI 平台。戳此处链接支付 2022 年收费体验席位！
