乐趣区

关于云计算:基于-Kubernetes-的云原生-AI-平台建设

jiezi

人工智能与 Kubernetes

在国外泛滥出名网站 2021 年对 Kubernetes 的预测中，人工智能技术与 Kubernetes 的更好联合通常都名列其中。Kubernetes 以其良好的扩大和分布式个性，以及弱小的调度能力成为运行 DL/ML 工作负载的现实平台。

下面是微众银行开源的机器学习平台 Prophecis 的架构图，咱们能够看到绿色的局部是机器学习平台通常都会有的性能包含训练、开发、模型、数据和利用的治理等性能。而通常这些机器学习平台都是运行在 Kubernetes 之上的，如紫色的局部所示：最底层是 Kubernetes，再往上是容器治理平台 (微众银行的开发者曾在 KubeSphere 2020 Meetup 北京站上提到这里采纳的是 KubeSphere)，容器治理平台在 Kubernetes 之上提供了存储、网络、服务治理、CI/CD、以及可观测性方面的能力。

Kubernetes 很弱小，但通常在 Kubernetes 上运行 AI 的工作负载还须要更多非 K8s 原生能力的反对比方：

  • 用户治理: 波及多租户权限治理等
  • 多集群治理
  • 图形化 GPU 工作负载调度
  • GPU 监控
  • 训练、推理日志治理
  • Kubernetes 事件与审计
  • 告警与告诉

具体来说 Kubernetes 并没有提供欠缺的用户治理能力，而这是一个企业级机器学习平台的刚需；同样原生的 K8s 也并没有提供多集群治理的能力，而用户有泛滥 K8s 集群须要对立治理；运行 AI 工作负载须要用到 GPU，低廉的 GPU 须要有更好的监控及调度能力进步 GPU 利用率并节省成本；AI 的训练须要很长时间能力实现，从几个小时到几天不等，通过容器平台提供的日志零碎能够更容易地看到训练进度；容器平台事件治理能够帮忙开发者更好地定位问题；容器平台审计治理能够更容易地获知谁对哪些资源做了什么操作，让用户对整个容器平台有深刻的掌控。

总的来说，K8s 就像 Linux/Unix, 但用户依然须要 Ubuntu 或 Mac。KubeSphere 是企业级分布式多租户容器平台，实质上是一个古代的分布式操作系统。KubeSphere 在 K8s 之上提供了丰盛的平台能力如用户治理、多集群治理、可观测性、利用治理、微服务治理、CI/CD 等。

如何利用 K8s 和 KubeSphere 构建机器学习平台

极栈平台是一个面向企业或机构的机器学习服务平台，提供从数据处理、模型训练、模型测试到模型推理的 AI 全生命周期治理服务，致力于帮忙企业或机构迅速构建 AI 算法开发与利用能力。平台提供低代码开发与自动化测试性能，反对工作智能调度与资源智能监控，帮忙企业全面晋升 AI 算法开发效率，升高 AI 算法利用与治理老本，疾速实现智能化降级。

极栈 AI 平台迭代演变的挑战

在应用 Kubernetes 之前，平台应用 Docker 挂载指定 GPU 来调配算力，容器内置 Jupyter 在线 IDE 实现和开发者交互，开发者在调配的容器内实现训练测试代码编写、模型训练，过后存在四个问题须要解决：

  1. 算力利用率低：开发者在编码时，GPU 仅仅用于代码调试；同时开发者需手动开启或者敞开环境，如果开发者训练完结未敞开环境，将持续占用算力资源。以算法大赛的场景为例，算力利用率均匀在 50%，算力资源节约重大。
  2. 存储运维老本高：平台应用 Ceph 来存储数据集、代码，比方容器挂载了 Ceph 的块存储来长久化存储开发环境，不便再次应用时能在其余 node 还原。在大量开发者应用时，呈现挂载卷开释不了、容器无奈进行等问题，影响开发者应用。
  3. 数据集平安无奈保障：商用算法数据集往往涉密，须要实现数据所有权和使用权拆散，比方许多大型政企开发算法往往外包给业余的 AI 公司。怎么让内部 AI 公司的算法工程师在既能实现算法开发，又能不接触到数据集，是政企算法平台客户的迫切需要。
  4. 算法测试人力老本高：对于算法开发者提交的算法，要对精度和性能等指标进行评测，达到算法需求方要求的精度和性能指标前方可上线。还是以算法大赛的场景举例，个别的 AI 平台会提供训练数据集、测试数据集给到用户，用户实现算法开发后，用算法跑测试集，将后果写入到 CSV 文件外面和算法一起提交。对于获奖的开发者，咱们要还原开发者测试环境，从新用开发者的算法来跑测试集，并和开发者提交的 CSV 后果比照，确定 CSV 文件没有被批改，保障较量偏心，这些都须要大量的测试人员参加，作为定位全栈 AI 开发的极栈平台来说，要在平台上开发万千算法，急需升高测试的人工成本。

为解决这些问题，2018 年中决定引入 Kubernetes 对平台进行重构，但过后团队没有精通 Kubernetes 的人员，Kubernetes 的学习老本也不低，重构停顿受到肯定影响；起初咱们发现了由青云科技开源的容器治理平台 KubeSphere，它把很多 Kubernetes 底层细节都屏蔽了，用户只须要像用私有云一样，用可视化的形式应用，能够升高应用 Kubernetes 的老本。同时社区的保护团队也十分认真负责，最开始把 KubeSphere 部署到咱们测试环境，集群运行一段时间会解体，开源社区的同学手把手帮忙咱们解决了问题，起初又陆续引入了 QingStor NeonSAN 来代替 Ceph，极大地晋升了平台稳定性。

KubeSphere v3.0.0 反对了多集群治理、自定义监控，提供了欠缺的事件、审计查问及告警能力；KubeSphere v3.1.x 新增对 KubeEdge 边缘节点治理的性能、新增多维度计量计费的能力、重构了告警零碎，提供了兼容 Prometheus 格局的告警设置、新增了包含企业微信 / 钉钉 / 邮件 /Slack/Webhook 等泛滥告诉渠道、同时对利用商店和 DevOps 也进行了重构；还在开发当中的 KubeSphere v3.2 将对运行 AI 工作负载提供更好的反对包含 GPU 工作负载调度、GPU 监控等；将来 KubeSphere v4.0.0 将降级为可插拔架构，前后端将都会取得可插拔的能力，基于此能够构建可插拔到 KubeSphere 的机器学习平台。

云原生 AI 平台实际

进步算力资源利用

  1. GPU 虚拟化

首先针对开发者编码算力利用率低的状况，咱们将编码和训练算力集群离开，同时应用 GPU 虚拟化技术来更好利用 GPU 算力，这方面市场上曾经有成熟的解决方案。在技术调研之后，抉择了腾讯云开源的 GPUManager 作为虚拟化解决方案。

GPUManager 基于 GPU 驱动封装实现，用户须要对驱动的某些要害接口（如显存调配、cuda thread 创立等）进行封装劫持，在劫持过程中限度用户过程对计算资源的应用，整体计划较为轻量化、性能损耗小，本身只有 5% 的性能损耗，反对同一张卡上容器间 GPU 和显存应用隔离，保障了编码这种算力利用率不高的场景开发者能够共享 GPU，同时在同一块调试时资源不会被抢占。

  1. 训练集群算力调度

在 Kubernetes 外面应用 Job 来创立训练任务，只须要指定须要应用的 GPU 资源，联合音讯队列，训练集群算力资源利用率能够达到满载。

    resources:
        requests:
            nvidia.com/gpu: 2
            cpu: 8
            memory: 16Gi
        limits:
            nvidia.com/gpu: 2
            cpu: 8
            memory: 16Gi
  1. 资源监控

资源监控对集群编码、训练优化有要害指导作用，KubeSphere 不仅能对 CPU 等传统资源监控，通过自定义监控面板，简略几个步骤配置，便可顺利完成可察看性监控，同时极栈平台也在 Kubernetes 根底上，依照我的项目等维度，能够限度每个我的项目 GPU 总的使用量和每个用户 GPU 资源分配。

<center>GPU 资源监控 </center>

当初，比方算法大赛的场景，咱们监控到的 GPU 均匀使用率在编码集群达到了 70%，训练集群达到了 95%。

存储：QingStor NeonSAN RDMA

咱们采纳 NVMe SSD+25GbE（RDMA）的 NeonSAN 来替换开源的 Ceph，NeonSAN 的体现很惊艳：比方随机读写的 IOPS，读达到了 180K，是 Ceph 的 6 倍，写也能够达到 75.7K，是 Ceph 的 5.3 倍，之后 AI 平台最高 1000 个 Pod 并发训练，没有再呈现存储挂载卷开释不了引起的卡顿问题。

数据集平安

咱们做了数据安全沙箱来解决数据集平安的问题，数据安全沙箱实现了在不透露数据的同时，又能让算法开发者基于客户数据训练模型和评估算法品质。

数据安全沙箱要解决两个问题：

  1. 平安隔离问题：对外集群不能连通外网，把数据传出去；在平台外部，能够通过程序把数据传输到开发者可能拜访的环境。比方在开发者能够管制的编码环境外面起个 http 服务接管训练集群传输过去的训练数据。KubeSphere 提供了基于租户的可视化网络安全策略管理，极大地升高了容器平台在网络层面的运维工作压力。通过网络策略，能够在同一集群内实现网络隔离，这意味着能够在 Pod 之间设置防火墙，如果多个策略抉择了一个 Pod, 则该 Pod 受限于这些策略的入站（Ingress）/ 出站（Egress）规定的并集，它们不会抵触，所以这里只有设置一个限度拜访外网的策略和禁止拜访编码 Pod 的策略即可。

  1. 训练体验问题：隔离之后，开发者要可能实时晓得训练和测试状态，训练和测试不能是一个黑箱，否则会极大影响模型训练和算法测试效率，如下图。
  • 开发者发动训练或者测试，工作在算力集群外面跑了起来，EFK 收集和存储容器日志，针对不同数据集，能够设置不同等级的黑白名单过滤策略，避免图片数据转码成日志泄露进去，比方高安全性数据集间接设置白名单日志展现。
  • 咱们开发了 EV_toolkit 可视化工具包，来查看训练的指标如精度、损失函数（比方穿插熵）等，原理是训练指标通过 toolkit 的 API 接口写入到指定地位，再展现到界面上。
  • 训练监控：反对无人值守训练，谬误音讯告诉，训练停顿定制化揭示，训练完结告诉。

自动测试

要实现算法的自动测试须要解决 3 个问题：

  1. 各个算法框架开发进去的模型格局不对立，怎么规范化对立调用。
  2. 所有算法输出要对立、标准化。
  3. 客户对算法要求越来越高，算法输入的数据结构也越来越简单，算法输入怎么跟数据标注的正确后果比对。

先来看看咱们自研的推理框架 EVSdk，它解决了前两个问题，一是制订了算法对立封装规范，不同于其余 AI 平台针对单模型进行评估，极栈自动测试零碎针对封装好的算法进行评估，因为随着算法越来越简单，一个算法有多个模型的状况也越来越常见，只是对单模型进行评估并不能评估交付给客户的成品品质，另外对模型评估还要思考各种开发框架模型格局兼容问题；二是 EVSdk 形象出了算法输出接口，比方针对视频剖析，第一个参数是创立的检测器实例，第二个参数是输出的源帧，第三个参数是可配置的 json，比方 roi、置信度等，通过 EVSdk 制订标准实现了算法输出的标准化。除了解决自动测试的两个问题，EVSdk 还提供工具包, 比方算法受权，另外有了对立的推理框架，里面一层的算法工程化工作也能够标准化，由平台对立提供，以安装包模式装置进去，不必开发者来做了，比方解决视频流、算法对外提供 GRPC 服务等。

还要解决算法输入的问题，算法输入就是要找到输入 JSON 或者 XML 的节点外面的算法预测数据，找到之后和标注的正确数据做比照。自动测试零碎引入了两个概念：

  • 模版：定义了算法输入的数据结构，这个数据结构中蕴含若干个变量和如何从原始数据中获取到具体值的路由门路，依据模版解析原始数据之后，模版中的所有变量将被填充具体的值。
  • 路由门路：一种针对数据查问的路由规定，应用这种规定能够把 xml / json 等不同的数据对象映射到雷同的数据结构。对于不同起源或者不同构造的测试数据，就能够通过扭转配置文件，失去雷同数据结构的数据，从而能够对同一类型的工作应用同一个解析器来计算算法指标。

下图示例外面截取了一个模板外面最小单元，但足以阐明自动测试原理。自动测试程序要在算法输入里找到年龄这个值，来和图片或视频标注的标签外面的年龄做比照。route_path 字段通知零碎有个根节点的 key 是 people，age 这个字段的 value 就是咱们要找的路由门路了，[0] 代表了这是一个数组，这也很好了解，因为能够有多集体呈现在一帧视频外面，. 代表了下一级，[] 里如果不是 0，比方 age 代表这是个对象，key 名叫做 age，@num 就是他的数据类型，至此程序就找到了 age 在算法输入的地位，找到后拿去和标注的正确数据作比照。当然有更简单的评判规范，例如年龄误差在 3 岁以内零碎认为算法剖析后果是正确的。

极栈平台现状

PaaS 层用 KubeSphere 作为底座打造了三个平台：数据平台，开发平台，推理平台。采集到原始数据之后对数据大类进行打标，再用算法对数据进行去重，以及把低质量数据去除掉等初筛工作，人工再进行筛选。因为 AI 训练数据量十分大，咱们还反对对数据生命周期进行设置，比方依据数据重要性进行保留，而后到数据标注，标注是十分占用工夫的工作，须要做工作的调配和对标注人员做绩效治理，通过再训练的模型进行主动标注和人工调整标注。数据标注好之后流转到开发平台，开发平台反对两种开发模式，一是交互式开发，二是低代码的开发。最初算法生产进去之后上架到推理平台的算法商店，推理平台的客户端能够部署到用户侧，用户只须要输出激活码就能够装置算法，而后剖析本地实时视频流或图片。

极栈平台将来瞻望

  1. 计算机视觉算法和其他软件不同在哪里呢，比如说 KubeSphere，给咱们用的产品和给另外公司用的是统一的。然而对于算法来说，在 A 客户那里成果很好，到 B 客户摄像头距离远一些、角度不同，或者是检测物体多了个色彩，成果就不达标了，要从新采集数据来训练模型。算法可复制性不强，难以标准化、产品化。对于解决通用场景的问题，每进步一个百分点识别率须要的算力和数据老本要翻倍，所以目前业界总共花了百亿老本才让人脸识别达到产品化，针对万千算法，如何大规模可复用，这是咱们要攻克的难题。
  2. 既然适配通用场景十分难，回到事实场景中来，咱们真的须要一直去优化一个算法适配所有用户的场景吗？对于每个用户来说，他真正关怀的是算法在他本人场景下的算法成果。而在实践中，对于新场景，咱们会将新场景数据集退出到训练集外面，对算法进行再训练来解决。如果零碎可能实现不让算法工程师染指再训练过程，而是由客户通过简略的操作来实现, 就解决了这个问题。

  1. 咱们下一步会开发行业低代码套件，算法开发者在平台内只需开发算法和保护算法在行业的当先性，用户拿本人场景数据来标注，训练模型，适配本人的场景，无需任何编码工作，就能够实现算法优化，优化成果不达标的场景，再由开发者染指。模型优化的工作如果无奈防止，放到用户侧，算法就相当于用户喂养的宠物，这其实会从新定义用户和算法之间的关系，只有这样走，算法能力产品化，万千场景能力关上。

Serverless 在 AI 畛域的利用

下面具体论述了 Kubernetes 在 AI 的利用实际，其实 AI 也须要 Serverless 技术，具体来说 AI 的数据、训练、推理等都能够同 Serverless 技术相结合而取得更高的效率并降低成本：

  • AI 离不开数据，以 Serverless 的形式解决数据老本更低。
  • 能够通过定时或者事件触发 Serverless 工作负载的形式进行 AI 训练以及时开释低廉的 GPU。
  • 训练好的模型能够用 Serverless 的形式提供服务。
  • AI 推理后果能够通过事件的形式触发 Serverless 函数进行后续的解决。

Serverless 是云原生畛域不容错失的赛道，以此为出发点，青云科技开源了云原生 FaaS 平台 —— OpenFunction。

FaaS 平台次要蕴含 Build、Serving 及 Events 几个局部。其中 Build 负责将函数代码转换成函数镜像；Serving 局部负责基于生成的函数镜像提供可伸缩的函数服务；Events 局部负责对接内部事件源并驱动函数运行。

Kubernetes 曾经启用 Docker 作为默认的 container runtime，从此不能在 K8s 集群里用 Docker in Docker 的形式 docker build 去 build 镜像，须要有别的抉择。OpenFunction 当初默认反对 Cloud Native Buildpacks，前面还将陆续反对 buildah、buildkit、kaniko 等。

Dapr 是微软开源的分布式应用程序运行时，提供了运行分布式应用程序须要的一些通用根底能力。OpenFunction 也把 Dapr 利用到了 OpenFunction 的 Serving 和 Events 里。

函数服务最重要的是 0 与 N 正本之间的主动伸缩，对于同步函数，OpenFunction 反对 Knative Serving 作为同步函数运行时，前面还打算反对 KEDA-HTTP ; 对于异步函数来说，OpenFunction 联合 Dapr 与 KEDA 开发了名为 OpenFunction Async 的异步函数运行时。

函数的事件治理咱们调研了 Knative Eventing 之后感觉它尽管设计的比拟好，然而有点过于简单，不易学习和应用；Argo Events 架构尽管简略了许多，但并不是专为 Serverless 而设计，并且要求所有事件都必须发往它的事件总线 EventBus。基于以上调研，咱们本人开发了函数事件治理框架 OpenFunction Events。

OpenFunction Events 充分利用了 Dapr 的能力去对接泛滥事件源、对接更多的 MQ 去作为 EventBus，蕴含 EventSource、EventBus 和 Trigger 几个组件：

  • EventSource：用于对接泛滥内部事件源如 Kafka、NATS、PubSub、S3、GitHub 等。在获取到事件之后，EventSource 能够间接调用同步函数进行解决，也能够将事件发往 EventBus 进行长久化，进而触发同步或者异步函数。
  • EventBus：利用 Dapr 可能以可插拔的形式对接泛滥音讯队列如 Kafka、NATS 等。
  • Trigger：从 EventBus 中获取事件，进行过滤选出关怀的事件后，能够间接触发同步函数，也能够将过滤出的事件发往 EventBus 触发异步函数。

Serverless 除了能够利用到上述 AI 畛域之外，还能够利用到诸如 IoT 设施数据处理、流式数据处理、Web / 挪动终端后端 API backend (Backend for Frontend) 等畛域。
OpenFunction 曾经在 GitHub 开源，次要仓库包含: <b/>OpenFunction[1]、functions-framework[2]、builder[3]、samples[4]

也欢送大家到 KubeSphere 和 OpenFunction 社区的 中文 Slack 频道 [5] 交换。

脚注

[1]. OpenFunction:https://github.com/OpenFuncti…

[2]. functions-framework:https://github.com/OpenFuncti…

[3]. builder:https://github.com/OpenFuncti…

[4]. samples:https://github.com/OpenFuncti…

[5]. 中文 Slack 频道: https://kubesphere.slack.com/…

作者

极视角科技技术合伙人 黄河、青云科技 KubeSphere 资深架构师 霍秉杰

退出移动版