Seldon Core 是 Seldon Technologies 开源的 Kubernetes 原生模型服务框架,用于在 Kubernetes 集群上部署、扩展和管理机器学习模型。它解决的问题很直接:生产环境中的模型格式多样(TensorFlow、PyTorch、SKLearn、XGBoost 等),部署方式各不相同,还要支持灰度发布、A/B 测试和监控,靠手工运维根本不可持续。Seldon Core 通过自定义资源 SeldonDeployment 声明式描述推理服务,由 Seldon Operator 统一编排,把多框架模型、组合推理图、实验策略和监控指标收敛到一套 Kubernetes 原生的工作流中。与 KServe、BentoML 等同类工具相比,它的核心优势是推理图(DAG)编排和内置的实验管理(金丝雀、A/B、多臂老虎机)能力。本篇攻略从安装、跑通第一个模型讲起,覆盖核心能力、生产部署、选型对比与常见坑,读者按步骤操作即可在 Kubernetes 上完成模型上线。
对 AI 从业者而言,掌握 Seldon Core 意味着你具备了在 Kubernetes 生产环境规模化交付模型的能力——这是 MLOps 工程师和机器学习平台团队的核心技能要求之一。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Seldon Core:Kubernetes 上模型部署碎片化 → 一套声明式平台统一管理
在 Kubernetes 上部署模型服务,最直接的方案是把模型包装成容器、编写 Deployment 和 Service 手动管理。这套做法在模型数量少时可行,一旦团队同时维护几十上百个模型,问题就暴露出来:每个框架的启动命令和端口约定不同,TensorFlow Serving 和 SKLearn 的 HTTP 接口格式不一致,调用方需要为每个模型写不同的客户端;灰度发布只能靠改 Kubernetes 原生的 deployment 比例,无法按请求流量精细控制;监控指标散落在各容器日志里,没有一个统一的模型维度视图。
Seldon Core 的解决思路是引入一层「模型服务抽象」:用户用一份 SeldonDeployment YAML 描述模型镜像、推理图结构和实验策略,Seldon Operator 负责把这份声明翻译成实际的 Deployment、Service、HPA 等 Kubernetes 资源,并统一暴露 REST 和 gRPC 两种调用接口。发布、回滚、扩缩容都归结为修改 YAML 后执行 kubectl apply,不需要关心底层网络和服务编排细节。内置的 Prometheus 指标(如请求数、延迟、返回值分布)从部署完成那一刻就自动上报。
与 KServe 等同类工具相比,Seldon Core 的气质更偏「实验驱动」:它的核心场景是 A/B 测试、金丝雀发布和多臂老虎机这类需要精细流量控制和持续对比的功能,而不是追求 Serverless 自动扩缩容。如果你的团队对模型上线后的实验迭代有强需求,Seldon Core 的匹配度更高。
安装与环境配置:3 步就绪
前置要求:Kubernetes 集群 1.21+,已安装 Helm 3。可以通过 kind、minikube 或云厂商托管集群进行验证。
步骤一:安装 Seldon Core Operator。 Operator 是控制平面的核心组件,负责监听 SeldonDeployment 资源的变化并创建底层工作负载。使用官方 Helm Chart 安装到 seldon-system 命名空间。
步骤二:准备外部访问入口(可选但推荐)。 Seldon Operator 只管理模型服务的生命周期,不负责对外暴露流量。生产环境需要配置 Ingress(如 NGINX Ingress Controller、Istio、Ambassador 等)来承接外部请求。本地验证可以用 kubectl port-forward 跳过这一步。
步骤三:验证安装。 确认 Operator Pod 运行正常、SeldonDeployment 对应的 CRD 已注册。
# 1. 添加官方 Helm 仓库helm repo add seldonio https://storage.googleapis.com/seldon-chartshelm repo update # 2. 安装 Seldon Core Operator到 seldon-system 命名空间kubectl create namespace seldon-systemhelm install seldon-core-operator seldonio/seldon-core-operator \ --namespace seldon-system # 3. 验证:Operator Pod 处于 Running 状态,CRD 已创建kubectl get pods -n seldon-systemkubectl get crd | grep seldon
快速上手:10 分钟跑通第一个 SKLearn 模型
最小可用流程的思路是:用一份 SeldonDeployment YAML 声明「我要部署一个 sklearn 分类器」,然后 apply 到集群,再通过 REST 接口发送一次预测请求。官方提供了开箱即用的 sklearnserver 镜像,无需写任何业务代码。
步骤一:创建 SeldonDeployment 定义文件。 下面的 YAML 声明了一个名为 iris 的模型服务,graph 中只有一个 MODEL 类型的节点 classifier,镜像使用官方 sklearnserver。
步骤二:提交并确认服务就绪。 执行 kubectl apply 后,使用 kubectl get seldondeployments 观察状态,模型镜像拉取和容器启动通常需要 1-2 分钟。
步骤三:调用预测接口。 本地验证时先 port-forward 服务端口,再发送 JSON 格式的预测请求。Seldon 的 REST 路径格式为 /seldon/<namespace>/<model-name>/api/v1.0/predictions,请求体采用 Seldon 的 ndarray 数据格式。
请求返回的 data.ndarray 字段即为模型分类结果。进阶阶段可以用官方 Python SDK 替代手写 curl,SeldonClient 封装了 REST/gRPC 的调用细节,适合集成到测试脚本或业务代码中:
# iris.yamlapiVersion: machinelearning.seldon.io/v1kind: SeldonDeploymentmetadata: name: iris namespace: defaultspec: name: iris predictors: - name: default graph: name: classifier type: MODEL parameters: - name: method value: predict type: STRING componentSpecs: - spec: containers: - name: classifier image: seldonio/sklearnserver:1.18.1
# 创建 SeldonDeploymentkubectl apply -f iris.yamlkubectl get seldondeployments iris # 端口转发到本地kubectl port-forward svc/iris-default-classifier 8000:8000 # 发送一次预测请求curl -s http://localhost:8000/seldon/default/iris/api/v1.0/predictions \ -H 'Content-Type: application/json' \ -d '{"data":{"ndarray":[[5.1,3.5,1.4,0.2]]}}'
from seldon_core.seldon_client import SeldonClient client = SeldonClient( deployment_name="iris", namespace="default", gateway_endpoint="localhost:8000", gateway="seldon",)resp = client.predict( transport="rest", shape=(1, 4), data=[[5.1, 3.5, 1.4, 0.2]],)print(resp)
核心能力详解:5 大支柱
支柱一:SeldonDeployment CRD 与推理图编排。 SeldonDeployment 是 Seldon 的绝对核心,除了单模型部署,它还支持把多个节点组合成一张有向无环图(DAG)。图节点类型有 MODEL(模型打分)、TRANSFORMER(输入/输出转换)、ROUTER(流量路由)、COMBINER(多结果融合)和 OUTLIER(异常检测),节点之间通过参数传递数据。这张图在 YAML 中声明,Operator 负责把图展开为实际的容器拓扑。推荐系统中的「特征转换 → 模型 → 后处理」流水线就能用一个 SeldonDeployment 表达,不需要分别部署三个服务再手工拼接。
支柱二:多框架推理服务器与自定义模型。 官方预置了 sklearnserver、xgboostserver、tensorflowserver、mlflowserver、onnxruntime server 等推理服务器镜像,对应框架的模型文件挂载或打包进镜像即可直接运行。官方服务器覆盖不了的场景,可以用 Seldon Core 的 Python 库实现自定义模型类——只需要实现 predict(X, features_names=[]) 方法,再通过 seldon-core-microservice 命令启动成 HTTP/gRPC 服务。这使得任意语言训练的模型(包括 R、Java)都能以容器形式接入 Seldon 的统一管理。
支柱三:高级部署策略——金丝雀、A/B 与多臂老虎机。 这是 Seldon Core 与多数竞品拉开差距的地方。金丝雀发布在 SeldonDeployment 中通过 canary 字段指定流量百分比(如 10%),配合 canaryMetrics 可以根据指标自动调节比例;A/B 测试使用 AB 类型的图节点,把请求随机分配到两个或多个模型分支,各分支独立打分、独立统计;多臂老虎机(MAB)节点更进一步,根据每次请求返回的奖励分数动态调整各模型臂的流量权重,实现收益驱动的自动实验。这些策略全部通过 YAML 声明,不需要额外开发路由服务。
支柱四:可观测性——Prometheus 指标与 Grafana 面板。 Seldon 为每个模型服务自动暴露标准化的 Prometheus 指标,主要包括 seldon_api_client_requests(客户端请求数)、seldon_api_server_responses(服务端响应数)、seldon_api_latency(响应延迟)等,按 deployment、predictor、模型名称打标签。官方提供了 Grafana dashboard 配置,部署后即可在面板上按模型维度查看流量、延迟和返回码分布。指标是后续做金丝雀自动化、模型告警的数据基础。
支柱五:模型漂移检测与可解释性。 生产模型效果下滑往往源于输入分布漂移(即线上数据分布与训练时不一致)。Seldon 的 OUTLIER 节点可以挂载 Alibi Detect 算法对输入做异常/分布检测;EXPLAINER 节点则提供模型预测解释(如 Anchor、LIME 等算法),用于审计和合规。这个能力把「模型部署」延伸到了「模型治理」,在金融、医疗等强监管场景是刚需。需要说明的是,漂移检测能力需要通过额外的镜像和配置接入,并非部署模型时自动启用。
生产部署与监控:从上线到运维
部署方式一:Ingress 接入外部流量。 生产环境通常在集群内已有 Ingress Controller(NGINX、Istio 或 Ambassador)。SeldonDeployment 创建后,通过给资源添加 ingress 相关注解,即可让外部请求按 host 或路径路由到模型服务。建议为所有模型服务统一域名规范(如 <model>-<namespace>.example.com),并在 Ingress 层启用 TLS。若涉及跨集群容灾,可以在多个集群各部署一套 Seldon,上层由 DNS 或流量网关做分发。
部署方式二:GitOps 流程管理模型版本。 SeldonDeployment 是纯声明式资源,天然适合接入 ArgoCD 或 Flux。模型的镜像版本、金丝雀比例、副本数都以 YAML 形式存放在 Git 仓库,变更走 PR 评审,由 ArgoCD 自动同步到集群。好处是模型发布的流程与代码发布对齐,任何人改动都有审计记录,回滚只需 revert 一次提交。
可观测性:指标采集与告警。 在集群中部署 Prometheus 和 Grafana,通过 ServiceMonitor 采集 seldon-system 命名空间下所有模型服务的指标。基于 seldon_api_latency 和 seldon_api_server_responses 设置告警规则(例如 P99 延迟超过阈值或 5xx 比例突增),能在模型服务劣化的第一时间通知到值班工程师。金丝雀发布时,把 canaryMetrics 关联到这些指标,可以实现在新版本指标劣化时自动回滚流量。
<p class=“para-label“>避坑清单:</p><ul class=”dash-list”><li>升级 Seldon Operator 前一定先核对官方升级文档:新版本 CRD 的 API 版本(如 machinelearning.seldon.io/v1 → v1alpha2)可能不兼容,直接覆盖安装会导致存量 SeldonDeployment 无法被识别,升级前先备份 CRD 定义与资源清单。</li><li>自定义 Python 模型不要手写任意 Web 服务:Seldon 的探针、协议解析和 DAG 调用依赖 seldon-core 约定的接口与端口,必须通过 seldon-core-microservice 启动,否则出现「服务已启动但始终不健康」的诡异现象。</li><li>不要把金丝雀百分比理解成 Pod 比例:canary: 10 表示入口处 10% 的请求进入新版本,所有 Pod 始终在运行,这与 Kubernetes Deployment 的滚动更新逻辑完全不同,误用会导致流量分配与预期不符。</li></ul>
| 维度 | Seldon Core | KServe | BentoML | Ray Serve |
|---|---|---|---|---|
| 定位 | Kubernetes 原生模型服务框架 | 基于 Knative 的 Serverless 推理平台 | 模型打包与部署框架 | 分布式计算引擎上的模型服务 |
| 编排范式 | CRD(SeldonDeployment)+ Operator | CRD(InferenceService)+ Knative | Python Bento 打包 + 容器化产物 | Python Actor + 声明式部署 |
| 类型约束 | 多框架服务器 + 自定义包装器,支持 DAG 编排 | 多框架标准推理协议,单模型为主 | Python 为主,打包后部署 | Python 为主,模型即 Actor |
| 学习曲线 | 偏高,需熟悉 Kubernetes 与 CRD | 高,依赖 Knative + Istio 生态 | 偏低,pip 安装即可上手 | 中等,需理解 Ray 概念 |
| 生态集成 | Alibi 漂移检测、内置 Prometheus、GitOps 友好 | Kubeflow 生态、KServe v1/v2 协议 | MLflow、Docker、多云平台 | Ray 生态、RLlib、与 K8s 集成 |
| 生产部署 | A/B、金丝雀、MAB 实验能力丰富 | Serverless 自动扩缩容、GPU 弹性 | 多环境管理与 API Server | 在线离线统一、可灵活扩展 |
| License | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| 适合谁 | 已有 K8s、重实验与监控的团队 | 平台型团队追求 Serverless 弹性 | 开发体验优先的快速交付团队 | 已用 Ray、需统一范式的团队 |
选型建议:在 Kubernetes 上需要复杂的多模型编排、A/B 实验和漂移监控,首选 Seldon Core;追求 Serverless 自动扩缩容与 GPU 弹性,选 KServe;团队以 Python 开发为主、想最快把模型变成可交付的服务,BentoML 上手成本最低;若已有 Ray 做分布式训练、希望训练与服务同栈,Ray Serve 更自然。四个工具均为 Apache 2.0 协议,选型主要看团队基础设施与运维偏好。
版本迭代
Seldon Core 自 2020 年发布 1.0 稳定版以来,主线始终围绕「多框架模型服务标准化 + 实验驱动」演进;2023-2024 年的 v1 系列以维护稳定和云原生兼容为主;官方在 2024 年宣布了基于 Rust 数据平面与 Kafka 的 v2 重写方向,但截至本文,v1.18.x 仍是生产环境采用的最新正式稳定版。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v1.0.0 | 2020-02 | 首个稳定版 | 确立 SeldonDeployment CRD + Operator 架构,支持 REST/gRPC 接口与主流框架 |
| v1.5.x | 2021 | 推理服务器与协议完善 | 扩展 sklearn/xgboost/tensorflow 等官方服务器,完善金丝雀与 A/B 实验配置 |
| v1.12.x | 2022 | 云原生环境适配 | 更新 Kubernetes 版本兼容矩阵,强化 executor 与推理图执行稳定性 |
| v1.16.x | 2023 | 维护与安全更新 | 依赖升级与安全修复,持续兼容新版 Kubernetes |
| v1.18.x | 2024 | 最新 v1 正式版 | 稳定维护与安全更新,为 v2(Rust + Kafka 重写)过渡做准备 |
Seldon Core 的 v1 路线图以稳定性和云原生生态兼容为主,功能层面的重大创新已趋缓,官方重心转移到 v2 的流式架构重写。对新建项目,建议直接以 1.18.x 为基础搭建;若对性能极致敏感且愿意跟进新技术,可关注 v2 的 alpha/beta 进展,但生产环境应等待其正式发布后再迁移。
AI 应用场景
金融风控模型的灰度发布与 A/B 实验
解决的问题:风控模型更新频繁,每次上线都担心效果回退。传统方式人工切流量、手工观察报表,发布周期长且难以精细控制。Seldon Core 用声明式金丝雀(canary)和 A/B 节点将流量按百分比自动分配,新旧模型同时在线、独立统计。
具体案例:某风控团队将新模型作为 A/B 分支与旧模型并存,Seldon 自动分流并上报 seldon_api_client_requests 等指标到 Prometheus。对比两周的 AUC 和通过率后决定全量,回滚只需把 YAML 中金丝雀字段改回 0 并再次 apply。
推荐系统多模型推理流水线编排
解决的问题:线上推荐服务由特征转换、候选召回、精排多个模型串行组成,独立部署意味着多个服务和调用链,运维复杂、故障点多。Seldon Core 的推理图(DAG)能力把 TRANSFORMER 与 MODEL 节点编排进同一个 SeldonDeployment。
具体案例:推荐团队将特征转换器(TRANSFORMER)与两个精排模型(A/B 分支)组合为一张推理图,一次部署同时完成预处理、打分和分流,调用方只需请求一个端点多模型流水线。
信贷审批模型的漂移监控与合规告警
解决的问题:信贷模型的输入分布随时间漂移(如客群结构变化),导致不良率上升,人工巡检难以第一时间发现。Seldon 的 OUTLIER 节点接入 Alibi Detect 的漂移检测算法,实时评估输入分布与训练集的偏差。
具体案例:某信贷团队为审批模型配置漂移检测后,当输入分布偏移超过阈值时自动标记异常请求并触发 Prometheus 告警,数据团队在模型指标劣化前介入分析,满足内部模型风险管理要求。
常见误区
误区我以为执行完 helm install,模型服务就会自动获得一个公网地址可以调用,结果等了半天 curl 不通。
正解Seldon Operator 只负责管理 SeldonDeployment 的创建和编排,不包含外部流量入口。外部访问需要额外部署和配置 Ingress(NGINX、Istio、Ambassador 等),或者开发阶段用 kubectl port-forward 临时打通。官方文档将 ingress 作为独立前置章节,跳过它必然踩坑。
为何常见:很多部署类工具「安装即暴露服务」,容易把这种默认行为迁移到 Seldon 上,忽略了它把流量入口完全交给用户自定义的架构选择。
误区Seldon 支持自定义模型,那我用 Flask 起一个 HTTP 接口、实现 predict 方法应该就能被调用。
正解Seldon 对自定义模型有明确的接口约定:需要实现 predict(X, features_names=[]) 等生命周期方法,再通过官方 seldon-core-microservice 命令启动容器。Seldon 的探针检查、REST/gRPC 协议解析和推理图参数传递都依赖这套约定,绕开它会导致服务「容器已启动但永远不健康」。
为何常见:把 Seldon 的「支持任意框架」误解为「协议格式无要求」,忽略了框架提供方与被集成方之间必然存在的接口规范。
误区把 canary 设为 50,应该就是一半 Pod 跑新版本、一半跑旧版本。
正解Seldon 的金丝雀与 Kubernetes Deployment 滚动更新是两套机制。canary 的百分比是指入口处按比例转发请求——所有 Pod 都在运行,只是 50% 的请求被路由到新版本模型。这在 Seldon 中通过 graph 的流量分发实现,与 Pod 副本数无关。
为何常见:从 Kubernetes 原生滚动发布经验迁移而来,把「流量比例」和「实例比例」混为一谈。
误区文档里全是 sklearnserver、xgboostserver,是不是其他模型就跑不了。
正解官方推理服务器只是开箱即用的便捷镜像。任何模型只要用 seldon-core Python 库实现 predict 接口、构建成容器镜像,就能以自定义 MODEL 节点形式接入 SeldonDeployment,与官方服务器享受同样的路由、实验、监控能力。
为何常见:官方文档和示例大量使用预置镜像,容易让人误以为能力边界就在那里,忽略了自定义包装器这个核心扩展机制。
面试题
Q1. SeldonDeployment 是 Seldon Core 描述模型服务的核心资源,它的本质是什么?
- A.Kubernetes Deployment 的别名封装
- B.由 Seldon Operator 管理的自定义资源← 正确答案
- C.Helm Chart 中的模板渲染产物
- D.Knative Service 的另一种写法
答案:B。SeldonDeployment 是 Seldon 定义的自定义资源(CRD,属于 machinelearning.seldon.io API 组),由 Seldon Operator 监听并翻译成底层的 Deployment、Service 等 Kubernetes 资源。它不是 Deployment 的别名,与 Helm 和 Knative 也没有直接关系。
Q2. Seldon Core 向客户端提供预测调用时支持哪两种网络协议?
- A.REST(HTTP/JSON)← 正确答案
- B.gRPC(protobuf 序列化)← 正确答案
- C.WebSocket 长连接
- D.GraphQL 查询语言
答案:AB。Seldon 的 API 层支持 REST 和 gRPC 两种协议,REST 用于简单集成和调试,gRPC 适合高性能与强类型场景。WebSocket 和 GraphQL 均不属于 Seldon 的预测接口协议。
Q3. 在默认配置下,通过 REST 调用 Seldon 模型预测的完整路径格式是?
- A./api/v1.0/predictions/{model-name}
- B./seldon/{namespace}/{model-name}/api/v1.0/predictions← 正确答案
- C./predict/{namespace}/{model-name}/v1.0
- D./v1/models/{model-name}:predict
答案:B。Seldon 的 REST 接口路径统一为 /seldon/{namespace}/{deployment-name}/api/v1.0/predictions,路径中包含命名空间和模型名,便于多租户场景下的路由。另外三个路径分别属于 KServe、部分自研服务和 TensorFlow Serving 的约定。
Q4. Seldon 的多臂老虎机(MAB)图节点根据什么动态调整不同模型分支的流量权重?
- A.预先设定的固定权重轮询
- B.请求返回的奖励分数与尝试次数← 正确答案
- C.各分支节点的 CPU 利用率
- D.客户端请求中的自定义标头
答案:B。MAB 节点实现了多臂老虎机算法(如 epsilon-greedy),每次请求由模型返回的奖励分(reward)反馈驱动权重调整,在探索与利用之间平衡,最终让流量向效果更好的模型倾斜。固定权重、CPU 利用率和请求标头都不是其调权依据。
Q5. 以下哪一项不属于 SeldonDeployment 推理图(graph)中的合法节点类型?
- A.MODEL
- B.TRANSFORMER
- C.ROUTER
- D.SERVER← 正确答案
答案:D。Seldon 推理图的合法节点类型为 MODEL、TRANSFORMER、ROUTER、COMBINER、OUTLIER。SERVER 不是图节点类型,Seldon 中「server」通常指推理服务器镜像(如 sklearnserver),属于实现层面的概念,graph 中声明的是逻辑节点。
Q6. 构建 Seldon Core 生产级模型监控体系,通常需要组合以下哪些组件?
- A.Prometheus 采集模型指标← 正确答案
- B.Alibi Detect 检测数据漂移← 正确答案
- C.Grafana 可视化指标面板← 正确答案
- D.MLflow 管理实验参数
答案:ABC。Seldon 自动暴露 Prometheus 指标,Grafana 负责面板展示与告警,Alibi Detect 通过 OUTLIER 节点提供输入漂移检测,三者构成完整的监控闭环。MLflow 是实验跟踪与模型注册工具,与在线服务监控无直接关系。
Q7. 自定义 Python 模型接入 seldon-core-microservice 时,必须实现的预测方法签名是?
- A.def model(self, X, label=None)
- B.def predict(self, X, features_names=[])← 正确答案
- C.def serve(self, X, request=None)
- D.def score(self, X, y=None)
答案:B。Seldon 的自定义模型约定要求实现 predict 方法,接收特征矩阵 X 和可选的 features_names 参数并返回预测结果,microservice 会按此签名反射调用。其他方法名不符合 seldon-core Python 库的接口约定,不会被识别。
Q8. 安装 Seldon Core Operator 的官方支持方式有哪些?
- A.Helm Chart 安装← 正确答案
- B.Kustomize 声明式安装← 正确答案
- C.pip install seldon-core 自动安装
- D.Docker Compose 一键部署
答案:AB。官方文档提供的部署方式是 Helm Chart(seldonio/seldon-core-operator)和 Kustomize(operator/config 目录)。pip install 只安装 Python 客户端 SDK 和数据模型,不会安装 Operator;Seldon 面向 Kubernetes 设计,Docker Compose 不是支持的方式。
Q9. 推理图中 OUTLIER 节点承担的核心职责是什么?
- A.将请求流量分发到不同模型分支
- B.对输入做异常检测与分布偏移评估← 正确答案
- C.融合多个模型节点的输出结果
- D.为模型预测结果生成可解释性说明
答案:B。OUTLIER 节点用于检测输入异常或分布漂移,常与 Alibi Detect 等算法集成,在异常输入进入模型前标记风险。流量分发是 ROUTER 的职责,结果融合是 COMBINER,可解释性是 EXPLAINER 节点。
Q10. 关于 Seldon Core v2 的架构方向,下列描述正确的是?
- A.用 Rust 重写数据平面并引入 Kafka 作为流式骨干← 正确答案
- B.完全向后兼容 v1 的全部 CRD 与参数
- C.移除 Kubernetes 依赖改为独立进程部署
- D.以 Knative Serverless 替代原有 Operator 架构
答案:A。Seldon v2 是一次重大架构重写:数据平面改用 Rust 实现以提升性能,消息骨干引入 Kafka 凸显流式处理导向,并非对 v1 的渐进兼容。v2 仍面向 Kubernetes 部署,且 Operator 模式并未被 Knative 取代,B、C、D 均与官方公开路线不符。
参考来源
- webpage官方示例 Notebooks从 sklearn 部署到漂移检测的完整示例
- webpageSeldon 官网产品线介绍与官方博客(含 v2 动态)