1、Kubeflow 初识：什么是 Kubeflow、Kubeflow 的诞生背景与核心价值、Kubeflow 在 MLOps 中的定位
1.1 什么是 Kubeflow？
Kubeflow，说白了，就是一个跑在 Kubernetes 上的机器学习工具包。
我刚开始接触它的时候，第一反应是：「这不就是把 Jupyter Notebook 搬到 K8s 上了吗？」后来才发现，远不止这么简单。
Kubeflow 的核心使命，是让机器学习工作流——从数据准备、模型训练、调参，到模型部署、监控——全部在 Kubernetes 集群上完成。它把容器化、微服务、自动扩缩容这些云原生能力，带到了 ML 领域。
嗯，你可以把它理解成「ML 版的 Kubernetes 原生应用商店」。你不需要自己写一堆 YAML 去编排 Pod、Service、PVC，Kubeflow 帮你把这些都封装好了。
一句话总结：Kubeflow = Kubernetes + 机器学习工具链。
1.2 诞生背景：为什么会有 Kubeflow？
2017 年，Google 开源了 Kubeflow。为什么是那个时间点？
我回想一下当时的行业状态：
- Kubernetes 已经成了容器编排的事实标准
- TensorFlow 火得一塌糊涂，但部署模型到生产环境依然痛苦
- 每个团队都在自己造轮子——写脚本、搭环境、手动部署
Google 内部其实早就在用一套叫 TensorFlow Extended（TFX）的平台。他们想：能不能把 TFX 的经验和 Kubernetes 结合起来，让更多人受益？
于是 Kubeflow 诞生了。它最初的目标很简单：让 TensorFlow 模型在 K8s 上跑起来更顺畅。
后来社区发现，光支持 TensorFlow 不够。PyTorch、MXNet、XGBoost 的用户也嗷嗷待哺。所以 Kubeflow 逐渐演变成了一个多框架、全流程的 ML 平台。
我个人习惯：每次搭建新环境，第一件事就是确认 Kubeflow 版本和 Kubernetes 版本的兼容性。踩过坑的人都知道，版本不匹配能让你怀疑人生。
1.3 核心价值：Kubeflow 到底解决了什么问题？
我把它拆成三个层面来讲：
1.3.1 环境一致性
你在本地 Jupyter 里调好的模型，部署到生产环境就崩了？
这种问题我遇到过太多次了。Kubeflow 用容器把环境固化下来——开发环境、测试环境、生产环境，镜像一模一样。说白了，就是「一次构建，到处运行」的 ML 版。
1.3.2 工作流自动化
传统 ML 流程里，数据预处理、训练、评估、部署，每一步都是割裂的。你手动跑脚本，手动拷贝模型文件，手动更新 API 服务。
Kubeflow Pipelines 把这些步骤串成一条流水线。你定义好 DAG（有向无环图），剩下的交给它自动调度。失败了还能自动重试，或者从断点恢复。
避坑指南：我曾经在 Pipeline 里忘记设置资源限制，结果训练任务把整个集群的 CPU 吃光了。后来我养成了习惯——每个组件都显式声明 requests 和 limits。
1.3.3 多租户与资源隔离
团队里好几个人同时做实验，怎么互不干扰？
Kubeflow 利用 Kubernetes 的 Namespace 做隔离。每个项目、每个用户，都有自己的独立空间。你跑你的实验，我调我的参数，谁也不影响谁。
1.4 Kubeflow 在 MLOps 中的定位
MLOps 这个词，这几年被炒得很热。它到底在讲什么？
我个人的理解是：MLOps = DevOps 的 ML 版本 + 模型生命周期管理。
传统 DevOps 关注的是代码的 CI/CD。MLOps 在此基础上，还要关注：
- 数据版本管理：训练数据变了，模型效果可能天差地别
- 模型版本管理：哪个版本在线上跑？效果如何？
- 实验追踪：超参数、训练日志、评估指标，都要记录下来
- 模型监控：部署上去之后，数据漂移了怎么办？
Kubeflow 在 MLOps 生态里，扮演的是「基础设施层」的角色。它不直接提供数据标注工具，也不做特征存储，但它提供了运行这些工具的平台。
你可以把 Kubeflow 想象成 MLOps 的「操作系统」。上面可以跑各种 ML 工具：
| MLOps 环节 | Kubeflow 组件 | 说明 |
|---|---|---|
| 数据准备 | Kubeflow Pipelines + Notebooks | 在 Jupyter 里做 EDA，用 Pipeline 做数据清洗 |
| 模型训练 | Training Operators (TFJob, PyTorchJob 等) | 分布式训练，自动调度 GPU 资源 |
| 超参调优 | Katib | 自动搜索最优超参数组合 |
| 模型部署 | KServe (原 KFServing) | 一键部署模型为 REST/gRPC 服务 |
| 模型监控 | KServe + Prometheus | 监控推理延迟、吞吐量、数据漂移 |
我建议：刚开始接触 MLOps 的同学，不要试图一步到位。先把 Kubeflow Pipelines 跑通，再慢慢加其他组件。贪多嚼不烂，这个道理在 ML 平台建设上特别适用。
1.5 Kubeflow 整体架构（SVG 图）
下面这张图，是我梳理的 Kubeflow 核心组件关系。你仔细看一遍，就能明白它到底长什么样：
注意：这张图展示的是 Kubeflow 1.x 的经典架构。Kubeflow 2.0 之后，组件集成度更高，但核心逻辑没变。你先把这张图刻在脑子里，后面学起来会轻松很多。
1.6 什么时候该用 Kubeflow？
不是所有场景都需要 Kubeflow。我见过不少团队，就两三个人做模型，硬上 Kubeflow，结果运维成本比开发成本还高。
我个人觉得，出现以下信号时，可以考虑引入 Kubeflow：
- 团队超过 5 人，多人同时做实验
- 需要 GPU 资源，且要动态分配
- 模型上线频率高，每周甚至每天都要部署
- 有多个模型需要同时在线提供服务
- 公司已经在用 Kubernetes，想统一技术栈
反过来，如果你只是一个人做实验，或者模型一年才更新一次，那用 Docker Compose 甚至直接在服务器上跑，可能更省事。
我建议：先从小规模开始。哪怕只用 Kubeflow 的 Notebook 组件，也比裸机 Jupyter 强。等团队和模型多了，再逐步上 Pipelines 和 KServe。
1.7 本章小结
Kubeflow 不是什么神秘的东西。它就是 Kubernetes 上的 ML 工具集，帮你解决环境一致性、工作流自动化、资源隔离这些实际问题。
在 MLOps 的版图里，Kubeflow 扮演的是基础设施层的角色。它不包办一切，但提供了运行一切的基础。
嗯，这一章就到这里。你先把 Kubeflow 的定位和架构理清楚，后面我们一步步深入每个组件。
公众号:蓝海资料掘金营，微信deep3321