1. 项目概述这不是“跑通模型”而是让模型在真实世界里活下来“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句行话暗号老手一眼就懂前面三篇已经蹚过了数据清洗、特征工程、模型训练和验证的浅水区而这一part是真正把脚踩进泥里开始面对生产环境那套冷酷又琐碎的生存法则。它不讲怎么调高0.5%的AUC而是直击一个所有ML工程师最终都绕不开的硬核问题你花三个月调出来的那个在Jupyter里闪闪发光的模型怎么才能不崩在凌晨三点的线上订单预测接口里怎么才能在用户上传一张模糊照片时不返回“NaN”而是给出可解释的置信度怎么才能让运维同事不再半夜打电话问“你们那个Python服务又占满CPU了到底啥时候能修好”这本质上是一场从学术思维到工程思维的范式迁移。在Notebook里“模型效果好”是唯一KPI在生产环境里“模型效果好”只是及格线后面还排着一长串更难伺候的指标延迟p95 200ms、吞吐量≥500 QPS、资源稳定性内存波动15%、故障恢复时间MTTR 3分钟、模型漂移检测灵敏度72小时内捕获概念漂移。我带过三个落地项目最惨的一次是某金融风控模型上线后第三天因特征管道中一个未处理的时区转换bug导致全量用户评分集体偏移业务方直接暂停了整条信贷审批流——而这个bug在本地测试和A/B测试里完全没暴露。原因很简单测试数据是静态快照生产数据是永不停歇的河流而我们的监控只盯着模型输出没盯住输入源头。所以Part 4的核心从来不是“如何部署”而是“如何构建一套让模型能自主呼吸、自我诊断、受控演化的生命支持系统”。它覆盖的领域横跨MLOps工具链选型、模型服务化架构设计、实时特征计算、可观测性埋点、A/B测试框架搭建、以及最关键的——人与流程的协同机制。适合两类人深度参考一类是刚从算法岗转战MLOps的工程师需要避开我当年踩过的“只重模型轻基建”的坑另一类是技术负责人正为团队交付周期长、线上事故频发、算法与工程撕扯不断而头疼。这篇文章不提供银弹但会把每个关键决策背后的血泪账本摊开给你看。2. 核心思路拆解为什么放弃“FlaskGunicorn”单体部署转向KFServingKServe2.1 从“能跑”到“稳跑”的底层逻辑跃迁很多团队的第一反应是模型训练完用Flask写个APIGunicorn起几个workerNginx做反向代理再加个Prometheus监控——这确实能“跑起来”。我在2019年也这么干过当时给一个电商推荐模型做POCQPS不到200延迟毛刺偶尔飙到800ms运维说“还能忍”。但当业务方要求将该模型接入APP首页Feed流承载日均300万UV、峰值QPS 1200时这套方案立刻暴露出三个致命短板弹性伸缩失灵Gunicorn的worker进程是预分配的面对流量脉冲比如双十一大促开场扩容需手动触发或依赖笨重的K8s HPA规则响应延迟常超2分钟而流量高峰往往在30秒内达到峰值模型版本混杂多个实验模型v1.2, v1.3-beta, v2.0-rc共用同一套Flask代码靠URL路径区分/predict/v1 /predict/v2一旦路由配置出错或前端调用路径写错A/B测试组别直接乱套资源隔离失效不同模型如图像分类和文本情感分析部署在同一Pod里一个模型因OOM崩溃整个服务进程挂掉影响其他业务线。这些不是理论风险而是我们被逼着在凌晨三点紧急回滚时反复验证过的现实。于是我们彻底重构了服务架构核心决策是放弃通用Web框架拥抱专为机器学习设计的服务层。最终选定KServe原KFServing作为底座而非Triton或Seldon。这个选择背后有三重算计提示KServe不是“另一个模型服务器”它是Kubernetes原生的ML服务控制平面其价值在于将“模型即服务”抽象为K8s CRDCustom Resource Definition。这意味着你定义一个模型服务写的不是Python代码而是一份YAML声明“我要部署XGBoost模型v2.1镜像地址是xxx最小副本2最大副本10健康检查路径是/healthz金丝雀发布比例10%”。2.2 KServe为何胜出用K8s原生能力解决ML特有问题我们对比了Triton、Seldon、BentoML和KServe四套方案最终KServe胜出的关键在于它把ML服务的四个核心痛点精准地映射到了K8s最成熟的原生能力上对比维度TritonSeldonKServev0.12我们的实测结论多框架支持NVIDIA生态强PyTorch/TensorRT优先支持广SKLearn/XGBoost/TF/PyTorch同Seldon且通过sklearnserver等标准server无缝集成无明显差距但KServe的server插件机制更透明升级框架版本时无需改服务代码自动扩缩容依赖K8s HPA需手动配置指标如CPU支持基于QPS的KEDA扩缩容原生集成KEDA支持QPS、延迟、GPU显存利用率等多维指标关键胜出项我们用KServe的autoscaling.kserve.io/target字段直接设p95延迟≤200msKEDA自动调节副本数扩缩容响应15秒金丝雀发布需配合Istio或自研流量分发逻辑支持但配置分散在多个CRD中单YAML文件内声明canaryTrafficPercent: 10canaryConfig运维效率提升3倍。上线新模型v2.1时只需改一行数字10%流量切过去其余90%仍走v2.0失败则自动回滚可观测性埋点Prometheus指标有限仅推理吞吐/错误率提供基础指标但自定义标签需改代码全链路OpenTelemetry原生支持自动注入trace_id关联模型输入/输出/特征故障定位时间从小时级降到分钟级。曾用trace_id快速定位到某次延迟飙升源于特征服务Redis连接池耗尽而非模型本身问题这个表格不是纸上谈兵。我们曾用KServe部署一个实时反欺诈模型当遭遇黑产团伙发起的短时高频请求模拟攻击KServe的KEDA控制器在12秒内将副本从3个扩至18个p95延迟稳定在180ms而同样场景下Triton依赖CPU指标的HPA花了92秒才完成扩容期间大量请求超时。KServe的价值不在于它多炫技而在于它把K8s的成熟能力以ML工程师能理解的语言封装成了可声明、可审计、可回滚的基础设施。2.3 架构图景KServe如何嵌入你的现有技术栈很多人误以为采用KServe就得推翻重来。实际上它是一个极低侵入性的“胶水层”。我们的生产架构是这样分层的[用户端] → [API网关Kong] → [KServe InferenceService CRD] ↓ [模型服务层] ← [KServe内置Predictor/Transformer/Explainer] ↓ [特征平台] ← [Feast Feature Store Redis缓存] ↓ [模型存储] ← [MinIO对象存储S3兼容] ↓ [训练平台] ← [Kubeflow Pipelines MLflow Tracking]关键点在于KServe不碰你的训练逻辑也不接管你的特征计算。它只做一件事当你提交一个InferenceServiceYAML它就去MinIO拉取模型文件启动对应框架的server容器如sklearnserver:v0.12.0并自动注入特征服务地址、配置健康检查探针、挂载监控指标端口。Transformer组件则负责在请求到达时调用Feast SDK实时拉取用户最新特征拼接到原始请求中——这部分代码由你编写KServe只提供标准化的HTTP/gRPC接口契约。这种解耦带来的好处是算法团队可以专注优化transformer.py里的特征拼接逻辑工程团队则维护KServe的CRD模板和K8s集群双方修改互不影响。我们曾让算法同学在不惊动运维的情况下独立完成了Transformer的三次迭代从同步Feast调用→异步预加载→本地Redis缓存每次只需更新YAML里的transformer镜像地址。这种协作效率是Flask时代无法想象的。3. 实操要点解析从零部署一个KServe模型服务的完整链路3.1 环境准备K8s集群不是“有就行”而是“必须这样配”KServe对K8s环境有明确的硬性要求很多团队卡在这一步数周。我们踩过的坑足够写本书这里只列最关键的三项配置第一K8s版本与CRD兼容性KServe v0.12要求K8s ≥ 1.22且必须启用CustomResourceValidation和CustomResourceSubresources两个API组。我们曾在一个1.20集群上强行安装结果InferenceServiceCRD创建后始终处于Pending状态。排查发现是apiextensions.k8s.io/v1API未启用。解决方案# 检查API组是否启用 kubectl api-versions | grep apiextensions # 若无输出则需升级K8s或联系云厂商开启注意阿里云ACK、腾讯云TKE默认已启用但私有云OpenShift需手动配置。别省这步否则后面所有操作都是空中楼阁。第二节点资源规格的“黄金配比”模型服务对CPU/内存/GPU的诉求与普通Web服务截然不同。我们测试了8种组合最终确定CPU密集型模型XGBoost/LightGBM节点需≥16核内存≥64GBCPU:内存 1:4例8核/32GB。原因树模型推理时大量cache miss内存带宽成瓶颈GPU加速模型ResNet/Transformer必须使用NVIDIA GPU节点且单节点GPU卡数≤2。我们试过A100×4节点结果因PCIe带宽争抢单卡吞吐反而比A100×2低18%通用型节点部署KServe控制平面建议3节点集群每节点8核/32GB避免控制平面与模型服务争抢资源。第三存储插件的强制选择KServe默认使用minio作为模型存储后端但生产环境必须替换为S3兼容存储。我们选MinIO自建非AWS S3因为成本可控S3按请求次数和存储量收费日均亿级请求下费用惊人网络延迟低MinIO与K8s集群同机房部署模型加载速度比S3快3.2倍实测1.2GB模型加载MinIO 8.3s vs S3 27.1s权限精细MinIO的Bucket Policy可精确到model-v2.1/*路径避免模型文件被越权访问。配置要点在KServe安装时通过--set storageHelper.s3.endpointhttp://minio-service:9000指定地址并用storageHelper.s3.secretName挂载AccessKey/SecretKey。3.2 模型打包不是“保存pkl文件”而是构建可复现的OCI镜像这是算法工程师最容易忽略的环节。很多人把joblib.dump(model, model.pkl)扔进MinIO就以为完事了。但KServe要求模型必须以标准化镜像形式存在且镜像内需包含完整的推理环境。我们制定了一套铁律步骤1冻结依赖生成可复现的requirements.txt不用pip freeze requirements.txt会包含dev依赖而是用pip-compile# pyproject.toml中声明核心依赖 [tool.poetry.dependencies] python ^3.9 scikit-learn 1.2.0,1.3.0 pandas 1.5.0,1.6.0 # 生成严格锁定的requirements.txt pip-compile pyproject.toml --output-filerequirements.txt这样生成的requirements.txt包含hash校验确保pip install时下载的包版本100%一致。步骤2编写Dockerfile遵循多阶段构建# 第一阶段构建环境 FROM python:3.9-slim AS builder COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 第二阶段运行环境极致精简 FROM python:3.9-slim # 复制编译好的依赖不复制源码 COPY --frombuilder /usr/local/lib/python3.9/site-packages /usr/local/lib/python3.9/site-packages # 复制模型文件从CI/CD流水线注入 COPY model.pkl /models/model.pkl # 设置KServe标准入口 ENV MODEL_NAMEmodel ENV MODEL_PATH/models CMD [python, -m, sklearnserver]关键点绝不COPY .避免把.git、__pycache__等无关文件打入镜像增大体积模型文件由CI/CD注入Jenkins Pipeline在构建镜像前先从MLflow下载指定版本模型再docker build --build-arg MODEL_FILEmodel-v2.1.pkl传入镜像Tag必须含模型哈希docker tag my-model:sha256-abc123确保镜像内容与模型版本强绑定。步骤3推送镜像并验证# 推送至私有Harbor仓库 docker push harbor.example.com/ml-models/my-model:v2.1-sha256-abc123 # 在K8s集群内验证镜像可拉取 kubectl run test-pod --imageharbor.example.com/ml-models/my-model:v2.1-sha256-abc123 --rm -it --restartNever -- bash -c ls -l /models/这一步必须做我们曾因Harbor仓库网络策略未放行K8s节点IP导致KServe拉取镜像超时服务状态卡在ImagePullBackOff长达2小时。3.3 KServe服务部署YAML不是配置而是“服务契约”一个InferenceServiceYAML本质是你向平台承诺的SLA协议。我们团队内部称之为“服务宪法”每行配置都有法律效力apiVersion: kserve.kserve.io/v1beta1 kind: InferenceService metadata: name: fraud-detect-v2 namespace: ml-serving annotations: # 强制启用OpenTelemetry追踪 opentelemetry.kserve.io/inject: true spec: predictor: # 指定模型镜像必须与Dockerfile构建的镜像一致 containers: - image: harbor.example.com/ml-models/fraud-xgb:v2.1-sha256-abc123 # 资源限制防止模型失控吃光节点资源 resources: limits: cpu: 4 memory: 8Gi nvidia.com/gpu: 0 # CPU模型显卡设为0 # 就绪探针KServe用此判断服务是否可接收流量 readinessProbe: httpGet: path: /v2/health/ready port: 8080 initialDelaySeconds: 60 # 模型加载需时间不能设太小 periodSeconds: 30 # 自动扩缩容策略这才是生产级的灵魂 autoscalerConfig: # 使用KEDA基于p95延迟扩缩 keda: triggers: - type: prometheus metadata: serverAddress: http://prometheus-k8s.monitoring.svc:9090 metricName: kserve_request_duration_seconds_bucket threshold: 200 # p95延迟阈值毫秒 query: histogram_quantile(0.95, sum(rate(kserve_request_duration_seconds_bucket{namespaceml-serving,servicefraud-detect-v2}[5m])) by (le)) # 金丝雀发布10%流量切给新版本 canaryTrafficPercent: 10 canaryConfig: # 新版本模型镜像 containers: - image: harbor.example.com/ml-models/fraud-xgb:v2.2-sha256-def456这份YAML里藏着三个生死攸关的细节initialDelaySeconds: 60XGBoost模型加载需解压、反序列化、预热若设为10秒KServe会误判服务未就绪反复重启容器threshold: 200单位是毫秒字符串格式写成200数字会导致KEDA解析失败扩缩容失效query中的命名空间和服务名必须与实际部署的namespace和InferenceService.name完全一致大小写敏感否则Prometheus查不到指标。部署后用这条命令验证服务状态kubectl get inferenceservice fraud-detect-v2 -n ml-serving -o wide # 正常状态应为ReadyTrue, StatusReady, URLhttp://fraud-detect-v2.ml-serving.example.com3.4 特征服务集成Transformer不是“锦上添花”而是“雪中送炭”KServe的Transformer组件是打通离线训练与在线推理的命脉。我们曾因忽略它导致线上模型效果暴跌。典型场景训练时用的是“用户近30天平均交易额”但线上请求只传了“用户ID”模型拿到空特征直接报错。我们的Transformer实现Python核心逻辑如下import feast from feast import RepoConfig from feast.infra.offline_stores.file_source import FileSource from feast.repo_config import RegistryConfig # 初始化Feast FeatureStore连接生产Redis store feast.FeatureStore( configRepoConfig( registryRegistryConfig(path/data/feature_repo/registry.db), projectfraud_detection, providerredis, online_store{type: redis, redis_type: redis, connection_string: redis://redis-feature:6379} ) ) def handler(data): # 1. 解析原始请求假设是JSON {user_id: U123} user_id data[instances][0][user_id] # 2. 实时拉取特征Feast自动从Redis读取毫秒级 feature_vector store.get_online_features( features[ user_features:avg_transaction_30d, user_features:is_vip, transaction_features:amount ], entity_rows[{user_id: user_id}] ).to_dict() # 3. 将特征注入请求返回给Predictor enriched_instances [] for instance in data[instances]: instance.update(feature_vector) enriched_instances.append(instance) return {instances: enriched_instances}关键实践Redis连接池复用store实例全局单例避免每次请求新建连接特征超时熔断在get_online_features外加timeout0.5若Redis响应超时返回默认特征值如avg_transaction_30d0保证服务不挂本地缓存兜底对VIP用户等高频特征用lru_cache(maxsize1000)缓存最近1000个结果降低Redis压力。部署Transformer时需单独构建镜像并挂载到InferenceServicetransformer: containers: - image: harbor.example.com/ml-transformers/fraud-transformer:v1.0 # 挂载Feast配置文件 volumeMounts: - name: feast-config mountPath: /data/feature_repo volumes: - name: feast-config configMap: name: feast-config-map4. 生产级可观测性没有监控的模型服务等于裸奔4.1 监控指标体系不是“看着好看”而是“故障定位指南”KServe原生暴露20个Prometheus指标但90%团队只看kserve_inference_request_count请求数和kserve_inference_request_duration_seconds延迟。这就像开车只看油表不看水温、胎压、转速。我们构建了三级监控体系L1 基础健康层告警阈值kserve_inference_request_count{status_code~5.*} 5次/分钟 → 立即告警模型或Transformer代码异常kserve_inference_request_duration_seconds_bucket{le0.2}占比 95% → 告警p95延迟超标可能需扩容container_memory_usage_bytes{containerkserve-predictor} / container_spec_memory_limit_bytes 0.85→ 告警内存泄漏风险。L2 模型行为层根因分析kserve_model_load_time_seconds_sum模型加载耗时。若从8s突增至45s说明MinIO网络抖动或模型文件损坏kserve_transformer_request_duration_secondsTransformer耗时。若占总延迟70%以上说明特征服务成瓶颈kserve_predictor_queue_latency_microseconds请求排队等待时间。若50ms说明副本数不足或Predictor处理慢。L3 业务语义层效果归因自定义指标fraud_score_distribution_bucket将模型输出分数分桶0-0.3/0.3-0.7/0.7-1.0监控各桶请求数占比。若“高危桶0.7-1.0”占比从12%骤降至3%说明模型可能失效feature_drift_alert{featureavg_transaction_30d}对接Evidently库每小时计算特征分布JS散度0.2则触发告警。提示所有指标必须打上model_version、canarytrue/false等标签否则无法区分新旧版本效果。我们在Grafana面板中用legend{{model_version}}-{{canary}}动态显示一目了然。4.2 日志与追踪用OpenTelemetry织就一张“请求生命图谱”KServe v0.12默认注入OpenTelemetry Collector但默认配置只采集HTTP头。要真正发挥价值必须做两件事第一统一Trace上下文透传前端调用时必须在Header中带上traceparent// 前端SDK示例 const traceId generateTraceId(); // 16字节十六进制 fetch(http://fraud-detect-v2.ml-serving.example.com/v2/models/fraud-detect-v2/infer, { headers: { traceparent: 00-${traceId}-0000000000000001-01, Content-Type: application/json } });KServe会自动将此trace_id注入到Predictor、Transformer、Explainer的所有日志和指标中。第二日志结构化字段必填在Transformer和Predictor代码中强制记录结构化日志import logging logger logging.getLogger(__name__) def predict_handler(request): # 记录关键字段便于ELK聚合 logger.info(inference_start, extra{ trace_id: request.headers.get(traceparent, ).split(-)[1], user_id: request.json[instances][0].get(user_id, unknown), model_version: v2.1, input_size_bytes: len(request.body) }) result model.predict(...) logger.info(inference_end, extra{ trace_id: request.headers.get(traceparent, ).split(-)[1], prediction_score: float(result[0]), latency_ms: (time.time() - start_time) * 1000, output_size_bytes: len(json.dumps(result)) }) return result在ELK中用trace_id关联所有日志就能还原一次请求的完整路径前端 → Kong网关 → KServe Ingress → Transformer耗时12ms→ Predictor耗时83ms→ 返回。当某次请求延迟飙高直接搜索trace_id5秒定位到是Transformer调用Feast超时而非模型本身问题。4.3 模型漂移检测不是“定期重训”而是“实时预警”模型漂移Concept Drift是生产环境最大的隐形杀手。我们曾有个风控模型上线后3个月AUC稳定在0.82第4个月突然跌至0.61损失数百万坏账。事后复盘发现黑产团伙改变了攻击手法新样本的“设备指纹”特征分布发生偏移但模型毫无感知。我们采用双轨制漂移检测实时流检测Flink Evidently将KServe的kserve_inference_request_duration_seconds指标流通过Kafka接入Flink每10分钟计算一次输入特征的JS散度0.15则触发企业微信告警离线批检测Airflow WhyLogs每天凌晨2点用Airflow调度任务从MinIO拉取昨日全部预测日志用WhyLogs生成数据质量报告重点监控null_rate空值率突增mean/std数值特征均值标准差偏移3σcategory_distribution类别特征分布变化20%检测到漂移后不自动重训而是触发人工审核流程通知算法同学提供漂移特征报告和样本算法在Jupyter中验证漂移是否真实排除数据管道bug若确认漂移启动MLflow实验训练新模型新模型通过KServe金丝雀发布灰度验证72小时全量发布旧模型下线。这套流程将模型衰减响应时间从“月级”压缩到“小时级”。5. 常见问题与避坑指南那些文档里不会写的血泪经验5.1 “服务状态Ready但curl返回404”——URI路径的隐藏陷阱现象kubectl get inferenceservice显示ReadyTrue但curl http://fraud-detect-v2.ml-serving.example.com返回404。根因KServe的InferenceService默认暴露的是v2模型服务协议符合KServe规范其标准路径是健康检查GET /v2/health/ready元数据GET /v2/models/{model_name}/versions/{version}推理POST /v2/models/{model_name}/infer而很多人习惯性curl根路径/自然404。解决方案测试健康curl -v http://fraud-detect-v2.ml-serving.example.com/v2/health/ready测试推理构造标准v2请求体JSON格式{ id: uuid123, inputs: [ { name: input-0, shape: [1, 10], datatype: FP32, data: [0.1, 0.2, ..., 0.9] } ] }实操心得我们把常用curl命令写成Makefilemake health、make infer-sample新人5分钟上手。5.2 “GPU显存显示0但模型推理失败”——NVIDIA Device Plugin的静默失效现象KServe配置了nvidia.com/gpu: 1nvidia-smi在节点上能看到GPU但Predictor容器内nvidia-smi报错“NVIDIA-SMI has failed because it couldnt communicate with the NVIDIA driver”。根因K8s节点上的NVIDIA Device Plugin未正确注册。常见于节点重启后Device Plugin Pod未自动恢复NVIDIA驱动版本与Device Plugin版本不匹配如驱动515Plugin却用v0.11。排查命令# 查看Device Plugin是否运行 kubectl get pods -n kube-system | grep nvidia # 查看节点GPU资源是否注册成功 kubectl describe node gpu-node-name | grep -A 5 nvidia.com/gpu # 正常应显示nvidia.com/gpu: 2修复步骤删除旧Pluginkubectl delete daemonset nvidia-device-plugin-daemonset -n kube-system安装匹配版本从 NVIDIA/k8s-device-plugin 下载对应驱动版本的yamlkubectl apply -f nvidia-device-plugin.yml重启KServe Predictor Podkubectl delete pod -l serving.kserve.io/inferenceserviceyour-model -n ml-serving。5.3 “金丝雀流量10%但新模型收到30%请求”——Istio VirtualService的权重陷阱现象设置canaryTrafficPercent: 10但监控显示新模型处理了30%请求。根因KServe的金丝雀依赖Istio VirtualService而VirtualService的权重是相对权重非绝对百分比。若旧模型服务v2.0的VirtualService权重为100新模型v2.1权重为10则实际分流比为100:10 90.9% : 9.1%。但若旧模型权重被误设为30则10/(3010)25%。解决方案绝对不要手动修改VirtualServiceKServe会自动生成检查KServe生成的VirtualServicekubectl get virtualservice fraud-detect-v2 -n ml-serving -o yaml确认http[0].route中weight字段之和为100http: - route: - destination: host: fraud-detect-v2-predictor-default.ml-serving.svc.cluster.local subset: default weight: 90 # 旧模型 - destination: host: fraud-detect-v2-predictor-canary.ml-serving.svc.cluster.local subset: canary weight: 10 # 新模型注意KServe v0.12已修复此问题权重自动归一化但v0.11及之前版本必须手动校验。5.4 “模型加载成功但首次请求超时”——Python GIL与多线程的隐性冲突现象模型服务Ready但第一个/infer请求耗时30秒后续请求正常100ms。根因XGBoost/LightGBM等库在首次调用predict()时会触发多线程初始化如OpenMP线程池而Python GIL在此过程中被长时间持有阻塞了HTTP请求处理线程。解决方案在模型加载后主动触发一次“热身”预测# sklearnserver的entrypoint.py中添加 if __name__ __main__: # 加载模型后立即热身 dummy_input np.random.rand(1, 10).astype(np.float32) model.predict(dummy_input) # 启动HTTP服务 app.run(host0.0.0.0, port8080)或在KServe的readinessProbe中增加/v2/health/live探针该探针会触发一次热身调用。5.5 “Prometheus查不到KServe指标”——ServiceMonitor的命名空间迷宫现象Prometheus Target页面看不到kserve-*指标。根因KServe的ServiceMonitor默认安装在kubeflow命名空间但你的Prometheus Operator可能只监控monitoring命名空间。解决方案查看ServiceMonitor所在命名空间kubectl get servicemonitor -A | grep kserve编辑Prometheus CR添加监控命名空间apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: k8s namespace: monitoring spec: serviceMonitorNamespaceSelector: