近期文章
Project Harbor 在盐湖城 KubeCon NA 2024 大放异彩,但伦敦呢?
Harbor v2.11 版本发布 - SBOMs 版本
Bonjour Harbor KubeCon + CloudNativeCon Europe 2024 - 巴黎
Harbor v2.10 版本发布
Harbor 通过关键镜像分发功能和机器学习工件支持扩展其影响力
2020 年 8 月 18 日
Harbor 团队
在 Harbor 宣布成为 CNCF 毕业项目的消息之后,团队正在为另一件大事做准备——即将发布的 Harbor v2.1 版本。Harbor v2.1 专注于通过与 Uber 的 Kraken 和阿里巴巴的 Dragonfly 等 P2P 提供商集成,实现代理缓存功能以及大幅改进的非阻塞垃圾回收功能,从而更好地进行镜像分发。但秉承开源创新的精神,v2.1 版本也见证了 Harbor 在 AI / ML 领域取得进展,成为 Kubernetes 部署中托管机器学习模型的首选容器镜像仓库。让我们深入了解一下。
近年来,Kubernetes 上的机器学习和深度学习取得了快速发展,例如 KubeFlow 等项目旨在将 ML 模型部署在本地或云端的任何 Kubernetes 集群上。由于已经充分利用了松耦合微服务以及自动扩展和调度等原生 Kubernetes 概念,现在是时候使用 Kubernetes 的最佳镜像仓库来完善整个机器学习管道了。
ByteDance 是领先的云提供商之一,致力于 KubeFlow 并成为其早期创始人之一,他们与 Harbor 团队合作,为管理和分发机器学习/深度学习模型提供解决方案。
相对于以二进制文件或其他自包含、良好打包的格式交付的传统应用程序,机器学习工作负载除了实际模型之外,还需要额外的模型推理服务器,以便迭代和发布这些工作负载。
模型推理服务器对于 ML 应用程序,就像 Tomcat 对于 Java Web 应用程序一样。
机器学习模型本身仅包含模型的参数,包括权重和结构,并依赖于模型推理服务器来提供基于 RESTful 或 gRPC 的服务以连接到外部世界。任何使用或部署 ML 模型的请求都将首先路由到模型推理服务器,然后它将使用该模型执行前向计算并将结果返回给调用者。
为了解决 ML 模型分发的问题,ByteDance 最初尝试将模型服务器以及模型一起打包为单个容器镜像以进行发布。
但很快就出现了一些问题
首先,模型服务器本身几乎是一个不可变的基础设施,通常由基础设施团队维护,而模型则由算法团队维护。模型服务器通常非常庞大,以 Nvidia Triton Inference Server 20.03 版本为例,其 Docker 镜像包含 43 层,完全解压缩后占用 6.3 GB。没有现有的 P2P 分发框架可以有效地移动这些内容。
其次,模型更新非常频繁。如果打包过程不能自动化,则算法工程师必须始终参与其中,从而增加部署成本。
第三,无法在镜像中正确捕获模型的关键元数据,例如超参数、训练指标和存储格式,这意味着随着模型及其版本的数量成倍增加,很难很好地扩展。
为了将模型推理服务器与模型本身解耦,并坚持 Docker “构建一次,随处部署” 的理念,ByteDance 选择 Harbor 镜像仓库作为这些模型的仓库和分发平台。用户可以使用类似的 “docker push” 和 “docker pull” 命令轻松存储和检索他们的模型,并充分利用 Harbor 的基于角色的访问控制、身份集成、围绕镜像部署的安全策略以及生命周期管理功能(例如创建保留策略和不变性策略)来管理这些模型。
为了与 Harbor 镜像仓库交互,ByteDance 创建了一个名为 ORMB(基于 OCI 的 ML/DL 模型捆绑注册表)的专用工具,该工具模仿 Docker 客户端,可以轻松创建、版本化和发布机器学习/深度学习模型到 OCI 注册表。它可以拉取这些模型,使用新版本重新打包,并直接从 Harbor 重新部署到 Kubernetes 集群,类似于 Seldon Core 如何直接从 S3 存储部署到 Kubernetes。这适用于 TensorFlow 中使用的 SavedModel 等流行的模型格式,以及潜在的许多其他格式。ORMB 旨在与任何 OCI 分发一起使用,ByteDance 团队选择 Harbor 的部分原因在于它完全符合 OCI 镜像规范和分发规范。机器学习模型被打包为 OCI 镜像,具有自己的 manifest mediaType 和 Image Config mediaType,以便 Harbor 可以解释它们,并且镜像层可以正确地持久化在存储中。
图 1:使用 ORMB 将本地训练的模型保存并推送到 Harbor
具体来说,遵循 OCI 工件 项目中编写 OCI 工件的指南,Harbor 团队与 ByteDance 合作定义了一个新的 Config 模式以及一个在 Harbor 的 UI 和 API 上捕获这些属性的过程。
额外的好处是,这种模式不仅可以被 ByteDance 的机器学习模型工件或通用 ML/DL 工件利用,而且还可以轻松定制以捕获任何其他用户定义工件的关键元数据。您可以在 此处 阅读详细提案。丰富 manifest.config 中内容的原因是为了提供关于如何实例化图层的其他说明,并提供有意义的顶层信息。例如,OCI Image Config 默认存储操作系统、架构和平台,一些镜像仓库运营商可能希望显示这些信息。在这种情况下,Config 将包含典型的 TensorFlow 模型特定信息,例如框架(“TensorFlow”)、格式(“SavedModel”)、签名、训练、数据集等。config 对象也很容易拉取和解析,并且不需要从 URL 检索所有图层来拉取、解压缩和解析。
图 2:Harbor 上显示的 SavedModel 属性
此外,利用 Harbor 的 Webhook,每次模型更新并推送到 Harbor 时,都可以触发通知,以便立即进行模型的重新部署。然后广泛使用 Harbor 复制功能来同步模型训练环境和模型生产环境中各个镜像仓库之间的模型。这标志着 Harbor 首次被用于存储机器学习相关工件,并且很大程度上依赖于我们为成为 OCI 兼容镜像仓库所做的工作。请继续关注,我们将寻找更多方法来为 ML/DL 和 Kubernetes 社区做出贡献!
Harbor 是一个开源镜像仓库,它使用策略和基于角色的访问控制来保护 OCI 工件,确保镜像经过扫描且没有漏洞,并将镜像签名为受信任的。Harbor 扩展了开源 Distribution/Distribution,增加了与第三方镜像仓库的双向复制,并且可以通过 Web 控制台或丰富的 API 集完全管理。Harbor 是一个 CNCF 毕业项目,提供合规性、性能和互操作性,以帮助您一致且安全地管理跨 Kubernetes 和 Docker 等云原生计算平台的工件
在 Twitter 上获取更新 ( @project_harbor) 在 Slack 上与我们聊天 ( #harbor 在 CNCF Slack 上) 在 GitHub 上与我们协作: github.com/goharbor/harbor 参加社区会议: https://github.com/goharbor/community/wiki/Harbor-Community-Meetings
Alex Xu Harbor 维护者 @xaleeks
Yiyang Huang Harbor 贡献者 @hyy0322