如何在Kubeflow流水线中实现自定义ML模型的自动部署与更新

1. 云厂商无关的Kubeflow内实现方案 #

完全存在云厂商无关的实现方式，全程不需要绑定任何云服务：

• 封装KFModel：直接使用普通Python KFP组件实现，将训练产出的模型文件、自定义预测逻辑、KFModel封装代码统一打包为镜像构建上下文，传递到后续步骤即可。
• 镜像构建：使用Kaniko作为构建工具，它是当前K8s环境下无根镜像构建的主流方案，不需要Docker daemon也不需要特权权限，安全性远高于DinD（Docker in Docker）方案。KFP官方提供了开箱即用的Kaniko组件，完全不绑定云厂商，支持对接任意OCI标准镜像仓库（如Harbor、自建Registry等）。
• InferenceService创建/更新：使用KFP通用Kubernetes操作组件，或者自行封装轻量Python组件调用KServe API即可，只要你的K8s集群预先部署了KServe（原KFServing）就能正常运行，无云厂商绑定。

2. 更优的实现方案 #

可以根据你的业务场景选择以下优化方案，比原生三步法效率更高：

• 预构建基础镜像：提前将KFModel依赖、模型运行所需的公共库打包为固定的基础镜像，流水线构建时仅需要拷贝模型文件和自定义预测逻辑，不用每次从头安装依赖，能大幅缩短镜像构建耗时。
• 模型与镜像解耦：如果你的模型更新频率很高，可以将训练好的模型上传到云无关的对象存储（如MinIO），KServe的InferenceService配置为启动时拉取对应路径的模型，流水线跑完仅需要触发InferenceService滚动更新，完全省掉镜像构建步骤，流程更轻量。
• 增加版本管控：给每个模型和镜像绑定唯一的流水线运行ID/版本号，避免更新时出现版本错配，也方便后续的问题排查和版本回滚。

3. 外部触发方案的可行性 #

该方案完全可行，也是生产环境常用的部署模式：

• 你可以预先将封装、构建、部署三步封装为独立的CI流水线（用Argo Workflow、Tekton等工具都可以），Kubeflow训练流水线跑完后，只需要新增一个轻量组件，发送包含模型版本、存储路径等信息的事件触发独立部署流水线即可。
• 该方案的核心优势是实现了训练和部署流程的解耦，部署逻辑迭代不需要修改训练流水线，同时可以做权限隔离，避免训练流水线持有过高的K8s集群操作权限，安全性更高。
• 唯一需要注意的点是做好触发参数的校验，确保模型版本、镜像标签等信息传递准确，避免部署错误版本。

内容的提问来源于stack exchange，提问作者Tomasz Cakala