1. 项目概述：这不是一次“部署上线”，而是一场从实验室到产线的系统性迁移

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句暗号，老手一眼就懂：它不是在讲怎么调参、怎么画loss曲线，而是在说，你那个在Jupyter里跑得飞起、AUC刷到0.98、连自己都感动的模型，现在得脱下白大褂，穿上工装裤，去流水线上拧螺丝了。我带过7个从0到1落地的ML项目，最常听到的崩溃瞬间不是模型不收敛，而是运维同事发来一条消息：“你本地跑通的那个API，压测一开，内存涨到32G，容器直接OOM被Killed。”或者业务方凌晨三点打来电话：“推荐列表全空了，用户投诉说首页变白板，你们模型是不是挂了？”——而你翻日志发现，只是上游数据源某天多传了一个空格，模型解析时抛了未捕获异常，整个服务链路静默熔断。

这系列文章的Part 4，恰恰踩在最关键的临界点上：它不谈理论，不炫技，只解决一个朴素问题——当模型不再是研究对象，而是一个需要7×24小时稳定输出、能扛住流量洪峰、可被监控告警、出问题5分钟内定位、且迭代过程不影响线上服务的“生产级组件”时，你该构建怎样的工程骨架？它面向的不是刚学完scikit-learn的新人，而是已经把模型训出来、正站在产线门口犹豫要不要推门进去的算法工程师、MLOps实践者，或是被业务倒逼着要“让AI真正产生价值”的技术负责人。核心关键词——模型服务化（Model Serving）、流量治理（Traffic Management）、可观测性（Observability）、灰度发布（Canary Release）——每一个词背后，都是血泪换来的架构选型逻辑和实操细节。接下来的内容，不会教你写一行PyTorch代码，但会告诉你，为什么你写的那行model.predict()在单机笔记本上是魔法，在Kubernetes集群里却可能成为性能瓶颈；为什么一个看似简单的HTTP接口，需要配置6层超时参数；为什么“模型版本”不能只靠Git tag管理，而必须和特征版本、数据Schema、依赖库版本形成强绑定的“部署单元”。这才是真实世界里，让机器学习从PPT走向利润表的最后一公里。

2. 整体设计思路：为什么放弃“Flask+Gunicorn”裸奔，选择KServe+Istio组合？

很多团队的第一反应是：模型导出为ONNX或Triton格式，用Flask写个轻量API，Gunicorn起几个worker，Nginx做反向代理，搞定！我试过，也帮三个客户这么干过。结果呢？第一个项目上线两周后，因并发突增导致Gunicorn worker全部卡死，排查发现是模型推理时Python GIL锁住了CPU密集型计算；第二个项目因不同业务方调用频率差异巨大，一个低频高优先级的风控请求，被高频的推荐请求挤占了所有worker，SLA直接崩盘；第三个最惨，模型更新时只能停服重启，业务方要求“零感知”，我们硬是写了三天热加载脚本，最后发现TensorFlow SavedModel的tf.keras.models.load_model()在多线程下有状态竞争风险，线上出现偶发预测结果错乱。

这些坑逼着我们回归本质：模型服务不是Web服务的简单子集，它是计算密集型、状态敏感、对延迟抖动极度敏感、且需与数据管道深度耦合的特殊中间件。因此，Part 4的设计核心，是构建一个“解耦、分治、可编排”的服务网格。我们最终选定KServe（原KFServing）作为模型服务引擎，Istio作为流量治理底座，而非更轻量的FastAPI或Seldon。理由非常务实：

第一，KServe原生支持多框架、多格式、多版本共存。你的团队可能同时用PyTorch训练图像分类，用XGBoost做信贷评分，用Hugging Face Transformers跑文本生成。KServe的InferenceService CRD（Custom Resource Definition）允许你为每个模型定义独立的predictor、explainer、transformer组件，它们可以运行在不同的容器镜像里，互不干扰。比如，PyTorch模型用pytorch/torchserve镜像，XGBoost用xgboost/xgboost镜像，而Transformer模型则用huggingface/transformers镜像。这种隔离性，远超Flask里if model_type == 'xgb': ... elif model_type == 'pt': ...的手动分支逻辑，它让模型生命周期管理变得原子化。

第二，Istio提供的细粒度流量控制，是灰度发布的物理基础。业务方常说“先切5%流量给新模型”，但传统Nginx的upstream权重配置，无法做到按请求内容（如user_id哈希、设备类型、地域）精准分流，也无法在5%流量中再细分“仅对VIP用户开放”。Istio的VirtualService + DestinationRule组合，让你能写出类似这样的规则：

apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: recommendation-model-vs spec: hosts: - "rec-api.prod.svc.cluster.local" http: - match: - headers: x-user-tier: exact: "vip" route: - destination: host: recommendation-model-v2 subset: v2 weight: 100 - route: - destination: host: recommendation-model-v1 subset: v1 weight: 95 - destination: host: recommendation-model-v2 subset: v2 weight: 5

这段配置意味着：所有VIP用户100%走v2，其余用户95%走v1、5%走v2。这种策略级的控制能力，是任何单体Web框架无法企及的。

第三，可观测性不是“加个Prometheus exporter”就完事，而是指标、日志、链路的三位一体融合。KServe默认暴露/metrics端点，其指标维度包含model_name、model_version、predictor_name、http_status_code、latency_ms_bucket等，这意味着你可以直接查询“v2版本推荐模型在华东节点的P95延迟是否超过800ms”。而Istio的Sidecar自动注入Envoy代理，为每一次HTTP/gRPC调用注入x-request-id，并上报source_workload、destination_workload、response_flags（如UC表示上游连接超时）等标签。当一个请求失败时，你不再需要在三个不同系统里分别查日志、看指标、翻链路追踪，Kiali控制台里一点就能看到：rec-api-v2->feature-store这条链路，response_flags=UC，立刻锁定是特征服务网络抖动，而非模型本身问题。

所以，这个组合不是为了“高大上”，而是为了解决真实痛点：模型迭代快，但线上稳定性要求更高；业务场景杂，但流量治理需求更精细；故障根因深，但排查效率要求更快。KServe负责“模型怎么跑”，Istio负责“流量怎么流”，二者叠加，才构成生产环境的最小可行闭环。

3. 核心细节解析：InferenceService的YAML不是配置文件，而是模型的“数字身份证”

很多人把KServe的InferenceServiceYAML当成一个简单的部署清单，填完name、namespace、predictor就提交了。我在两个项目里因此栽过大跟头：一次是忘记设置minReplicas: 2，流量高峰时单Pod被压垮，自动扩缩容来不及响应；另一次是containerConcurrency设为0（即无限制），导致一个慢请求阻塞了整个Pod的事件循环，后续请求全部排队超时。后来我才明白，这份YAML，本质上是模型在K8s集群里的“数字身份证”，它定义的每一个字段，都在回答一个严肃的生产问题。

3.1 predictor配置：容器资源与并发模型的精确制衡

以一个典型的PyTorch图像分类模型为例，其predictor部分关键配置如下：

apiVersion: "kserve.kserve.io/v1beta1" kind: "InferenceService" metadata: name: "image-classifier" spec: predictor: pytorch: storageUri: "gs://my-bucket/models/image-classifier/v1" resources: limits: memory: "4Gi" cpu: "2" requests: memory: "2Gi" cpu: "1" containerConcurrency: 4 minReplicas: 2 maxReplicas: 10

这里每一项都不是拍脑袋定的：

• storageUri：指向GCS/S3/Azure Blob的模型路径。KServe会自动下载并挂载到容器内。注意，它不支持本地文件路径，这是强制你拥抱云存储的信号。
• resources.limits：这是模型的“物理边界”。我们通过实测确定：该模型单次推理平均消耗1.2Gi内存、0.8核CPU。limits.memory: "4Gi"留了3倍余量，是为了应对batch inference（一次请求多张图）或模型warmup时的峰值内存。cpu: "2"则是基于torch.jit.trace优化后的实测吞吐量——当CPU配额低于1.5核时，QPS会断崖式下跌，因为PyTorch的DataLoader多进程预处理开始争抢CPU时间片。
• containerConcurrency：这是最易被误解的参数。它不是“每个Pod能处理多少并发请求”，而是“每个Pod的主容器进程能同时处理多少个请求”。对于PyTorch/TensorFlow这类基于Python的框架，由于GIL存在，containerConcurrency: 4意味着该Pod最多同时执行4个推理任务，第5个请求会被Knative的queue-proxy排队，直到有空闲slot。我们曾设为0，结果一个慢请求（如GPU显存不足导致的OOM重试）卡住整个Pod，所有请求排队，queue-proxy的queue_depth指标飙升到200+，最终触发Knative的自动驱逐机制，Pod被反复重建。4这个值，是我们用hey -z 10m -q 10 -c 20 http://...压测后，观察container_concurrency和request_count指标平衡点得出的。
• minReplicas/maxReplicas：这是Knative的Autoscaler策略。minReplicas: 2确保永远有2个Pod在线，避免冷启动延迟；maxReplicas: 10是根据历史峰值QPS（1200 QPS）和单Pod极限QPS（150 QPS）计算得出的：1200 / 150 = 8，向上取整为10，留出20%冗余。

提示：containerConcurrency与resources.limits.cpu强相关。CPU配额越低，建议containerConcurrency值越小，否则大量请求排队等待CPU时间片，实际吞吐反而下降。我们有个经验公式：containerConcurrency ≈ (resources.limits.cpu * 1000) / 250（250ms为单次推理平均耗时），再向下取整。

3.2 transformer组件：模型输入的“海关检查站”

模型服务最大的不稳定源，往往不在模型本身，而在输入数据。一个JSON里"image_url"字段少了个s，变成"image_ulr"，模型解析时抛KeyError，整个Pod的健康探针就失败了。KServe的transformer组件，就是专治这种“脏数据”的海关检查站。它是一个独立的容器，部署在predictor之前，所有请求先经过它清洗、校验、转换。

一个健壮的transformerYAML长这样：

transformer: containers: - name: classifier-transformer image: gcr.io/my-project/transformer:v1.2 env: - name: MODEL_NAME value: "image-classifier" ports: - containerPort: 8080 resources: limits: memory: "1Gi" cpu: "1" requests: memory: "512Mi" cpu: "500m"

这个容器的main.py核心逻辑是：

from flask import Flask, request, jsonify import json import requests app = Flask(__name__) @app.route("/v1/models/{MODEL_NAME}:predict", methods=["POST"]) def predict(): try: # 1. 强制JSON解析，拒绝非JSON请求 data = request.get_json(force=True) # 2. 字段校验：必须有image_url，且为字符串 if not isinstance(data.get("image_url"), str) or not data["image_url"].startswith("https://"): return jsonify({"error": "invalid image_url format"}), 400 # 3. URL可达性预检（可选，对延迟敏感场景慎用） # response = requests.head(data["image_url"], timeout=2) # if response.status_code != 200: # return jsonify({"error": "image_url unreachable"}), 400 # 4. 转换为predictor期望的格式（如base64编码） import base64, requests img_bytes = requests.get(data["image_url"]).content data["instances"] = [{"image": base64.b64encode(img_bytes).decode("utf-8")}] # 5. 转发给下游predictor predictor_url = f"http://image-classifier-predictor-default.default.svc.cluster.local/v1/models/image-classifier:predict" resp = requests.post(predictor_url, json=data, timeout=10) return jsonify(resp.json()), resp.status_code except Exception as e: return jsonify({"error": f"transformer error: {str(e)}"}), 500

这个transformer的价值在于：它把所有输入校验、格式转换、错误包装的逻辑，从模型代码里剥离出来。模型predictor容器从此只做一件事：接收标准格式的{"instances": [...]}，返回标准格式的{"predictions": [...]}。当业务方传来一个新字段"user_context"时，你只需升级transformer镜像，无需碰模型代码，更不用重新训练和部署。这就是“关注点分离”在生产环境的落地。

注意：transformer的timeout必须小于predictor的timeout，否则transformer的超时会掩盖predictor的真实问题。我们通常设transformer超时为8秒，predictor为10秒，留出2秒缓冲。

3.3 服务发现与网络策略：为什么必须用ClusterIP + Istio Gateway？

KServe默认为InferenceService创建一个ClusterIPService，它只在集群内部可访问。但业务方需要从外部调用，怎么办？很多团队直接给ClusterIP加NodePort或LoadBalancer，这是危险的。NodePort端口范围有限（30000-32767），且无法做TLS终止；LoadBalancer则绕过了Istio的流量治理能力，所有高级功能（金丝雀、熔断、重试）全部失效。

正确姿势是：用Istio Gateway + VirtualService做统一入口。Gateway定义L4/L7网关（监听443端口、配置TLS证书），VirtualService定义路由规则（将https://api.mycompany.com/rec路由到rec-api.default.svc.cluster.local）。这样，所有外部流量都经过Istio的Envoy代理，享受其完整的安全、可观测、治理能力。

我们曾在一个金融项目里吃过亏：初期用LoadBalancer直连模型Service，结果某天上游支付网关发起大量/health探测请求（每秒200次），直接打爆了模型Pod的健康探针，K8s认为Pod不健康，反复重启。换成Istio后，我们在Gateway层配置了connectionPool：

connectionPool: http: http1MaxPendingRequests: 100 maxRequestsPerConnection: 100 idleTimeout: 60s

并为/health路径单独配置了VirtualService的retries：

retries: attempts: 3 perTryTimeout: "1s" retryOn: "5xx,connect-failure,refused-stream"

从此，探测风暴被Envoy优雅地限流和重试，模型Pod稳如泰山。

4. 实操全流程：从模型导出到灰度上线的12个关键步骤

把一个Notebook里的模型，变成一个可灰度、可监控、可回滚的生产服务，不是一键部署，而是一套严谨的流水线。我们总结出12个不可跳过的步骤，每一步都有其不可替代的工程意义。下面以一个电商搜索排序模型（XGBoost）为例，完整复现。

4.1 步骤1-3：模型资产化——告别“git add model.pkl”

步骤1：模型序列化与元数据绑定
不要直接保存model.pkl。XGBoost模型用model.save_model("model.json")导出为JSON格式（比pkl更跨语言、更易审计）；同时，生成model-metadata.yaml：

model_name: search-ranker model_version: "2.1.0" framework: xgboost framework_version: "1.7.5" input_schema: - name: "user_embedding" type: "float32" shape: [128] - name: "item_features" type: "float32" shape: [64] output_schema: - name: "score" type: "float32" shape: [1] training_data_version: "2023-Q3-full"

这个YAML不是文档，而是CI/CD流水线的输入契约。后续所有步骤（测试、部署、监控）都依赖它。

步骤2：构建可复现的推理镜像
Dockerfile不是FROM python:3.9 && pip install xgboost就完事。必须固化所有依赖：

FROM python:3.9-slim-bookworm # 固化pip源和依赖版本 RUN pip install --no-cache-dir \ xgboost==1.7.5 \ scikit-learn==1.2.2 \ pandas==1.5.3 \ numpy==1.23.5 # 复制模型和元数据 COPY model.json /app/model.json COPY model-metadata.yaml /app/model-metadata.yaml # 启动脚本，验证模型加载 COPY entrypoint.sh /app/entrypoint.sh RUN chmod +x /app/entrypoint.sh ENTRYPOINT ["/app/entrypoint.sh"]

entrypoint.sh关键逻辑：

#!/bin/bash # 1. 验证模型文件存在且可读 if [ ! -f "/app/model.json" ]; then echo "ERROR: model.json missing" exit 1 fi # 2. 尝试加载模型，验证格式 python -c "import xgboost as xgb; xgb.Booster(model_file='/app/model.json')" || exit 1 # 3. 启动服务 exec "$@"

这确保了镜像构建时就完成模型健康检查，而不是等到K8s拉起Pod才发现JSON格式错误。

步骤3：注册模型到中央仓库
我们用MLflow Tracking Server作为模型注册中心。CI流水线在镜像构建成功后，执行：

mlflow models serve \ --model-uri "models:/search-ranker/Production" \ --port 8080 \ --host 0.0.0.0

但这只是本地测试。真正的注册是调用MLflow API：

import mlflow client = mlflow.tracking.MlflowClient() # 创建新版本 version = client.create_model_version( name="search-ranker", source="gs://my-bucket/models/search-ranker/2.1.0/", run_id="abc123", # 关联训练Run description="Q3 full-data retrain, AUC+0.02" ) # 将新版本标记为Staging client.transition_model_version_stage( name="search-ranker", version=version.version, stage="Staging" )

此时，search-ranker模型在MLflow UI里有了明确的Staging版本，它关联了训练代码、参数、指标、以及本次部署的Docker镜像tag（gcr.io/my-project/search-ranker:v2.1.0）。这就是“模型即代码”的起点。

4.2 步骤4-6：服务定义与基础设施准备

步骤4：编写InferenceService YAML模板
用Jinja2模板生成YAML，关键变量来自MLflow元数据：

apiVersion: "kserve.kserve.io/v1beta1" kind: "InferenceService" metadata: name: "search-ranker-{{ model_version }}" spec: predictor: xgboost: storageUri: "gs://my-bucket/models/search-ranker/{{ model_version }}" resources: limits: memory: "{{ memory_limit }}Gi" cpu: "{{ cpu_limit }}" requests: memory: "{{ memory_request }}Gi" cpu: "{{ cpu_request }}" containerConcurrency: {{ concurrency }} minReplicas: {{ min_replicas }} maxReplicas: {{ max_replicas }}

CI流水线读取MLflow中model_version: "2.1.0"和input_schema，自动计算memory_limit=3（基于历史内存Profile），concurrency=8（基于QPS压测），生成最终YAML。

步骤5：配置Istio流量策略
创建DestinationRule定义子集（Subsets）：

apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: search-ranker-dr spec: host: search-ranker-predictor-default.default.svc.cluster.local subsets: - name: v2-1-0 labels: version: v2.1.0 - name: v2-0-0 labels: version: v2.0.0

VirtualService定义初始路由（100%到旧版）：

apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: search-ranker-vs spec: hosts: - "search-api.prod.svc.cluster.local" http: - route: - destination: host: search-ranker-predictor-default.default.svc.cluster.local subset: v2-0-0 weight: 100

步骤6：部署监控告警基线
在Prometheus里配置Recording Rule，预计算关键指标：

# 模型v2.0.0的P95延迟（毫秒） model_latency_p95{model_name="search-ranker", model_version="2.0.0"} = histogram_quantile(0.95, sum(rate(kserve_request_duration_seconds_bucket{model_name="search-ranker", model_version="2.0.0"}[1h])) by (le)) # 错误率（5xx占比） model_error_rate{model_name="search-ranker", model_version="2.0.0"} = sum(rate(kserve_request_count_total{model_name="search-ranker", model_version="2.0.0", http_status_code=~"5.*"}[1h])) by (model_name, model_version) / sum(rate(kserve_request_count_total{model_name="search-ranker", model_version="2.0.0"}[1h])) by (model_name, model_version)

并配置Alertmanager告警规则：

- alert: SearchRankerLatencyHigh expr: model_latency_p95{model_name="search-ranker", model_version="2.0.0"} > 1200 for: 5m labels: severity: warning annotations: summary: "Search ranker v2.0.0 P95 latency > 1200ms"

此时，旧版服务已完全可观测，基线数据开始积累。

4.3 步骤7-12：灰度发布与闭环验证

步骤7：部署新版本InferenceService
提交search-ranker-2.1.0.yaml，KServe创建新Pod组，打上version: v2.1.0标签。此时，新Pod处于“待命”状态，流量仍100%走v2.0.0。

步骤8：金丝雀流量切分
修改VirtualService，切5%流量到新版本：

http: - route: - destination: host: search-ranker-predictor-default.default.svc.cluster.local subset: v2-0-0 weight: 95 - destination: host: search-ranker-predictor-default.default.svc.cluster.local subset: v2-1-0 weight: 5

应用后，Istio Envoy立即生效，无需重启任何Pod。

步骤9：实时对比监控
在Grafana看板里，并排显示v2.0.0和v2.1.0的指标：

关键发现：新版本延迟略高，但错误率更低，且CPU使用率在安全阈值（80%）内。这说明模型更稳健，值得继续放量。

步骤10：自动化健康检查
我们写了一个Python脚本，每5分钟调用一次/health端点，并检查：

• HTTP状态码是否为200
• 响应体是否包含{"status": "ok", "version": "2.1.0"}
• 延迟是否在base_latency * 1.3范围内（base_latency取v2.0.0的P95）

脚本集成到CI/CD，若连续3次失败，则自动回滚VirtualService权重到0%。

步骤11：渐进式放大与业务验证
确认v2.1.0稳定后，按计划放大：

• 第1小时：5% → 20%
• 第2小时：20% → 50%
• 第3小时：50% → 100%

同时，业务方同步验证效果：抽取1000个真实搜索Query，对比v2.0.0和v2.1.0的排序结果，计算NDCG@10提升幅度。我们要求NDCG提升≥0.015才允许全量。

步骤12：全量与旧版本清理
当v2.1.0运行24小时，所有指标达标，且业务验证通过后：

• 更新VirtualService，权重100%到v2.1.0
• 在MLflow中，将v2.1.0版本transition到Production阶段
• 执行kubectl delete inferenceservice search-ranker-2.0.0，清理旧Pod
• 更新文档，标记v2.0.0为Deprecated

至此，一次完整的、可审计、可回滚的模型生产发布闭环完成。整个过程，从镜像构建到全量上线，平均耗时47分钟，其中人工干预仅2次（步骤8和步骤11的确认），其余全部自动化。

5. 常见问题与实战排查技巧：那些文档里不会写的“血泪教训”

在真实产线摸爬滚打多年，我整理出一份高频问题速查表。这些问题，90%的官方文档不会提，但100%的工程师都会撞上。以下全是“踩过坑之后”的独家心得。

5.1 问题1：模型预测结果“偶尔错乱”，日志里找不到报错

现象：99.9%的请求结果正常，但约0.1%的请求，返回的score值是极小的负数（如-1e-8），而模型理论上输出应在[0,1]区间。kubectl logs查不到任何Python异常。

根因分析：这是典型的浮点数精度溢出+TensorFlow/Keras状态污染。当模型使用tf.keras.layers.BatchNormalization时，其moving_mean和moving_variance是可训练变量。在KServe的containerConcurrency > 1场景下，多个推理请求共享同一个Python进程，如果某个请求触发了BN层的training=True路径（如模型被意外调用model.train()），就会污染全局状态，导致后续请求的BN计算出错。

排查技巧：

• 在transformer或predictor容器里，添加/debug端点，返回tf.config.list_physical_devices('GPU')和tf.__version__，确认框架版本。
• 用kubectl exec进入Pod，运行python -c "import tensorflow as tf; print(tf.keras.backend.learning_phase())"，检查learning_phase是否为0（inference模式）。如果不是，说明有代码误设。
• 最有效的办法：在模型加载后，强制冻结BN层：

  for layer in model.layers: if isinstance(layer, tf.keras.layers.BatchNormalization): layer.trainable = False

解决方案：在模型导出前，用tf.keras.models.clone_model()创建一个纯推理副本，并显式设置layer.trainable = False。KServe的predictor只加载这个副本。

5.2 问题2：Istio Sidecar注入后，模型服务延迟飙升300%

现象：InferenceService单独部署时P95延迟800ms，开启Istio自动注入Sidecar后，P95飙升到3200ms，且envoy_cluster_upstream_cx_active指标显示连接数暴涨。

根因分析：Envoy Sidecar默认启用HTTP/1.1连接池，而KServe的predictor容器（如Triton）默认使用HTTP/2。当Envoy以HTTP/1.1代理HTTP/2请求时，会进行协议降级和连接复用，导致大量TIME_WAIT连接堆积，新请求被迫等待连接建立。

排查技巧：

• kubectl exec进入Pod，运行curl -v http://localhost:8080/health，看响应头是否有http/2。
• 查看Envoy日志：kubectl logs <pod-name> -c istio-proxy | grep "http2"，若看到downstream protocol: HTTP/1.1，则确认是协议不匹配。
• 用istioctl proxy-status检查Sidecar配置是否启用了HTTP/2。

解决方案：强制Envoy使用HTTP/2。在DestinationRule中添加：

spec: trafficPolicy: connectionPool: http: h2UpgradePolicy: UPGRADE

并在InferenceService的predictor容器里，确保PORT环境变量设为8080（KServe会自动配置Envoy监听此端口）。

5.3 问题3：模型更新后，transformer服务间歇性503

现象：新transformer镜像部署后，约30%的请求返回503，kubectl describe pod显示transformerPod的Ready状态为False，但kubectl logs无错误。

根因分析：KServe的transformer和predictor是两个独立的Deployment，它们通过Service DNS名通信。当predictor新Pod启动时，其Service的Endpoint可能还未更新，transformer容器里的DNS缓存（glibc的nscd或musl的/etc/resolv.conf）仍指向旧IP，导致连接被拒绝。

排查技巧：

• 在transformer容器里，执行nslookup search-ranker-predictor-default.default.svc.cluster.local，看返回的IP是否与kubectl get endpoints search-ranker-predictor-default一致。
• 检查transformer容器的/etc/resolv.conf，若options ndots:5，则短域名解析会尝试追加多个search domain，增加DNS延迟。

解决方案：在transformer的Deployment里，添加initContainer，等待predictorService就绪：

initContainers: - name: wait-for-predictor image: busybox:1.35 command: ['sh', '-c', 'until nslookup search-ranker-predictor-default.default.svc.cluster.local; do echo waiting for predictor service; sleep 2; done']

并降低DNS解析超时，在transformer容器的args里添加：

args: ["--dns-timeout=2", "--dns-sec=false"]

5.4 问题4：Prometheus抓不到KServe指标，kserve_request_count_total为空

现象：kubectl port-forward svc/prometheus 9090打开Prometheus，查询kserve_request_count_total，返回空。

根因分析：KServe的指标端点/metrics默认只监听127.0.0.1:8080，而Prometheus的ServiceMonitor通过ClusterIP访问，属于0.0.0.0网络，被防火墙拦截。

排查技巧：

• kubectl exec进入predictorPod，运行netstat -tuln | grep 8080，看监听地址是127.0.0.1:8080还是*:8080。
• 检查KServe的ConfigMap kserve-config，确认metrics部分是否配置了bindAddress: 0.0.0.0:8080。

解决方案：编辑KServe ConfigMap：

kubectl edit configmap kserve-config -n kubeflow

找到metrics段，添加：