从Notebook到生产：机器学习模型上线的工程化实战指南

1. 项目概述：这不是“跑通模型”，而是让模型在真实世界里活下来

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句行话暗号，老手一眼就懂：前面三篇已经蹚过了数据清洗、特征工程、模型训练和验证的浅水区，而这一part，是真正把脚踩进泥里，开始面对生产环境那套冷酷又琐碎的生存法则。它不讲怎么调高0.5%的AUC，而是直击一个所有ML工程师最终都绕不开的硬核问题：你花三个月在Jupyter里调得闪闪发光的模型，一旦脱离本地GPU和干净数据集，放进每天要处理百万级请求、数据格式随时漂移、上游服务可能凌晨两点挂掉的线上系统里，它还能不能呼吸？会不会直接窒息？会不会反向污染整个业务链路？这才是Part 4的核心战场。

我做过不下二十个从实验室走向产线的模型项目，最深的体会是：模型上线那一刻，不是终点，而是运维噩梦的起点。Part 4讲的，就是如何把那个在Notebook里被宠坏的“模型宝宝”，训练成能扛住流量洪峰、能识别数据腐烂、能自我诊断异常、甚至能在出问题时优雅降级的“生产级老兵”。它涉及的不是单一技术点，而是一整套工程化思维的切换——从“结果正确”转向“过程可靠”，从“单次推理快”转向“长期服务稳”，从“我本地能跑”转向“它在K8s集群里7×24小时不掉链子”。关键词里的“Production”三个字母，背后是监控告警、资源调度、版本灰度、AB测试、数据漂移检测、模型回滚、依赖隔离、日志追踪……一整条看不见却至关重要的生命支持系统。如果你还在用model.predict()直接塞进Flask API然后就去喝咖啡，那Part 4就是给你递来的一份生存指南，而且是带血渍的那种。它适合所有已经能把模型训出来的同学，尤其是那些正被产品经理追着问“模型什么时候能上？”、又被运维同事拉进群问“刚才那批预测为啥全返回NaN？”的实战派。这不是理论课，这是急诊室手册。

2. 核心设计思路拆解：为什么必须放弃Notebook式思维？

2.1 从“单次执行”到“持续服务”的范式跃迁

在Notebook里，一次model.fit()加一次model.predict()，流程就结束了。但生产环境里，模型不是被执行一次的函数，而是一个永远在线、持续响应、状态可追溯的服务进程。这带来了根本性差异：

• 生命周期管理：Notebook里模型加载一次，内存常驻；生产中，服务进程可能因OOM被K8s自动重启，模型必须支持快速热加载，且加载失败不能导致整个服务崩溃。我见过一个项目，因为模型文件路径写死在代码里，当CI/CD流水线把模型放到新路径后，服务启动时直接panic退出，整个API不可用长达47分钟——根源就是没把“模型加载”当成一个需要重试、超时、降级的独立服务环节。

• 输入输出契约化：Notebook里你传个pandas DataFrame，模型爱怎么处理怎么处理。生产中，API必须定义严格的JSON Schema输入（比如{"user_id": "str", "features": [float]}）和输出（{"score": float, "confidence": float, "version": "str"}）。任何字段缺失、类型错误、数组长度越界，都不能让模型内部抛出KeyError或ValueError，而必须由前置网关统一拦截，返回400 Bad Request并附带清晰错误码。这要求你在服务框架层就做schema校验，而不是等模型代码报错。

• 可观测性内建：Notebook里print(model.score)就够了；生产中，每一次预测请求必须打点：请求ID、输入特征摘要（采样）、模型版本、推理耗时、CPU/GPU利用率、输出分布统计（如score均值、方差、分位数）。这些不是锦上添花，而是故障定位的唯一线索。去年一个金融风控模型突然误拒率飙升，靠的就是实时看板里“score < 0.1的请求占比”曲线在凌晨3点陡增，结合日志里同一时段大量feature_x is null告警，5分钟就定位到上游数据管道某节点配置变更漏发了空值过滤逻辑。

提示：别幻想靠事后查日志。生产级ML服务的黄金法则是——所有关键决策点，必须有结构化指标埋点，且指标必须能实时聚合、下钻、告警。没有指标，等于在黑暗中开车。

2.2 模型封装：为什么不能直接暴露sklearn或torch.nn.Module？

很多新手会直接把训练好的sklearn.ensemble.RandomForestClassifier对象塞进FastAPI的predict()方法里。这看似简单，实则埋雷无数：

• 依赖地狱：sklearn1.2.0和1.3.0对稀疏矩阵的处理逻辑有细微差异，你的Notebook用1.2.0训的模型，如果生产环境装了1.3.0，预测结果可能漂移。更糟的是，torch不同小版本间nn.Linear的初始化种子行为也可能不同。生产环境必须锁定模型序列化格式+运行时依赖版本的精确组合。

• 无状态陷阱：sklearn模型对象本身不保存训练时的StandardScaler参数，你必须把scaler和model一起序列化。但joblib保存的scaler对象，在Python 3.9环境下用pickle加载到3.11环境，可能因__reduce__协议变化而失败。解决方案不是升级Python，而是将预处理逻辑固化为纯函数：把scaler.transform()的计算过程（均值、标准差）硬编码成lambda x: (x - mean) / std，这样模型包里只存数字，不存对象，彻底规避序列化兼容性问题。

• 性能墙：sklearn的predict_proba()在高并发下会因GIL锁住整个Python进程。我们实测过，一个4核CPU的Pod，纯sklearn服务QPS卡在320左右；换成onnxruntime加载ONNX模型后，QPS直接飙到2100+，且CPU利用率更均衡。这不是玄学，是ONNX Runtime针对推理做了极致的算子融合和内存池优化，而sklearn是为训练场景设计的。

所以Part 4的模型封装，核心原则是：模型即二进制，预处理即代码，服务即容器。模型必须导出为与语言无关、版本无关的中间表示（ONNX是当前工业界事实标准），预处理逻辑必须用确定性、无副作用的纯函数实现，服务必须打包成Docker镜像，镜像里只含最小必要依赖（onnxruntime,numpy,fastapi），杜绝任何pip install -r requirements.txt式的动态安装。

2.3 架构选型：为什么Kubernetes + FastAPI + Prometheus是当前最优解？

有人问，为什么不用Serverless（如AWS Lambda）？Lambda冷启动延迟高达300-800ms，对毫秒级响应的推荐系统是致命伤；且内存限制（10GB上限）无法承载大模型。也有人问，为什么不用TensorFlow Serving？它对TF生态友好，但对PyTorch/Scikit-learn支持弱，且配置复杂（需写.config文件定义模型签名），调试成本高。

我们团队过去三年踩坑后沉淀的架构是：Kubernetes作为底座，FastAPI作为服务框架，Prometheus+Grafana做监控，MLflow做模型注册与追踪。理由很实在：

• K8s的弹性伸缩是刚需：电商大促时流量可能突增5倍，K8s的HPA（Horizontal Pod Autoscaler）能根据CPU/自定义指标（如请求队列长度）自动扩缩Pod数量。我们给一个风控模型设了targetCPUUtilizationPercentage: 60%，当CPU持续高于60%，30秒内自动起新Pod；流量回落，5分钟内自动缩容。这比手动改服务器配置快10倍，且零人工干预。

• FastAPI的异步IO和自动文档是生产力：它的async def predict()能高效处理I/O密集型任务（如调用外部特征库），生成的OpenAPI文档让前端同学不用问后端就能直接调试接口。更重要的是，它的依赖注入系统，让你能把模型加载、数据库连接、缓存客户端都声明为Depends()，服务启动时自动初始化，失败则整个Pod健康检查失败，K8s自动重启，形成闭环。

• Prometheus的多维标签是灵魂：它不只记录http_request_duration_seconds，而是打上{service="fraud-model", version="v2.3.1", endpoint="/predict", status_code="200"}这样的多维标签。这意味着你能瞬间查出：“v2.3.1版本在/predict接口上，status_code=500的错误率是否显著高于v2.2.0？”——这种细粒度对比，是传统监控工具做不到的。

这套组合不是为了炫技，而是每一步都解决了一个具体痛点：K8s管生死，FastAPI管效率，Prometheus管真相。当你在凌晨三点收到告警说“fraud-model v2.3.1的P99延迟突破2s”，你能立刻在Grafana里切到对应版本、对应Pod、对应时间窗口，看到是CPU打满还是GC停顿，而不是在日志里大海捞针。

3. 核心细节解析与实操要点：从模型导出到服务部署的完整链路

3.1 模型导出：ONNX不是万能钥匙，但它是目前最可靠的桥梁

把训练好的模型转成ONNX，绝不是skl2onnx.convert_sklearn(model)一行命令就完事。关键细节决定成败：

• 输入输出签名必须显式声明：ONNX不理解pandas，只认tensor。你需要明确告诉转换器：“我的输入是一个形状为(1, 128)的float32张量，代表128维特征；输出是(1, 2)的float32张量，代表两类概率”。代码示例：

  from skl2onnx import convert_sklearn from skl2onnx.common.data_types import FloatTensorType # 定义输入类型：batch_size=1, feature_dim=128 initial_type = [('float_input', FloatTensorType([1, 128]))] # 转换，指定目标opset（ONNX算子集版本） onnx_model = convert_sklearn( model, initial_types=initial_type, target_opset=15, # 必须与onnxruntime版本匹配 options={id(model): {'zipmap': False}} # 关键！禁用zipmap，输出原始tensor而非dict ) with open("model.onnx", "wb") as f: f.write(onnx_model.SerializeToString())

  这里target_opset=15必须查证你的onnxruntime版本支持的最高opset（pip show onnxruntime看Requires: onnx>=1.13.0，再查ONNX官网对应关系），否则加载时会报Unsupported opset version。

• 预处理必须同步导出：模型只负责核心计算，标准化、One-Hot编码等必须在ONNX之外完成。但为了保证一致性，我们把预处理逻辑也写成ONNX模型（用skl2onnx转换StandardScaler），然后用ONNX Runtime的InferenceSession串联两个模型：先跑预处理ONNX得到标准化特征，再喂给主模型ONNX。这样整个pipeline就是一个原子化的ONNX图，彻底避免Python层预处理和ONNX模型间的数据类型/精度误差。

• 量化压缩是上线前必做动作：FP32模型体积大、推理慢。我们对风控模型做INT8量化后，体积从127MB降到32MB，P99延迟从180ms降到65ms。量化不是简单调API，而是要：

  1. 用真实业务数据（非训练集）做校准，收集各层激活值分布；
  2. 用onnxruntime.quantization的QuantFormat.QDQ模式（Quant-Dequant），保留部分关键层为FP32；
  3. 量化后必须用全量线上流量样本做回归测试，确保AUC下降<0.001。我们曾因在校准数据上AUC达标，但线上新用户特征分布偏移，导致量化后误判率上升，紧急回滚。

注意：量化不是银弹。对小模型（<10MB）或对精度极度敏感的场景（如医疗影像分割），INT8可能引入不可接受的误差。务必以线上效果为准，而非单纯追求速度。

3.2 服务框架：FastAPI不只是“快”，更是“稳”的基石

一个生产级FastAPI服务，骨架代码远不止@app.post("/predict")。核心加固点：

• 健康检查端点必须包含模型就绪状态：/healthz不能只返回{"status": "ok"}，而要检查模型文件是否存在、ONNX Runtime Session是否初始化成功、预处理函数能否正常执行。代码片段：

  @app.get("/healthz") async def health_check(): try: # 检查模型session if not model_session: raise RuntimeError("Model session not initialized") # 检查预处理 _ = preprocess(np.random.rand(1, 128).astype(np.float32)) return {"status": "ok", "model_version": MODEL_VERSION} except Exception as e: logger.error(f"Health check failed: {e}") raise HTTPException(status_code=503, detail="Service unavailable")

  K8s的livenessProbe和readinessProbe都指向此端点。当模型加载失败，Pod会立即被标记为NotReady，流量不会打进来；若加载成功但后续崩溃，liveness探针失败会触发Pod重启。

• 请求体必须强校验，拒绝一切模糊地带：用Pydantic定义严格Schema：

  class PredictRequest(BaseModel): user_id: str = Field(..., min_length=1, max_length=64, regex=r'^[a-zA-Z0-9_]+$') features: List[float] = Field(..., min_items=128, max_items=128) timestamp: int = Field(..., ge=0) # Unix timestamp @app.post("/predict") async def predict(request: PredictRequest): # 此处request.features已是严格校验后的list[float] ...

  这样，当客户端传{"features": [1,2]}（只有2维）时，FastAPI自动返回422 Unprocessable Entity，并附带详细错误信息"features: ensure this has at least 128 items"，无需你写一行if判断。

• 异常处理必须分级捕获：不能让任何未捕获异常穿透到框架层。

  @app.exception_handler(RequestValidationError) async def validation_exception_handler(request, exc): # Pydantic校验失败 return JSONResponse( status_code=422, content={"error": "Invalid input format", "details": str(exc)} ) @app.exception_handler(StarletteHTTPException) async def http_exception_handler(request, exc): # 404, 500等 return JSONResponse( status_code=exc.status_code, content={"error": exc.detail} ) # 全局兜底 @app.middleware("http") async def catch_exceptions_middleware(request: Request, call_next): try: return await call_next(request) except Exception as e: logger.exception("Unhandled exception") return JSONResponse( status_code=500, content={"error": "Internal server error"} )

  这种分层异常处理，让错误归因清晰，也防止敏感信息（如堆栈）泄露给客户端。

3.3 监控告警：指标不是越多越好，而是要能回答“发生了什么？”

我们只采集4类核心指标，但每类都经过千锤百炼：

关键实践：

• score_bin的分桶必须业务驱动：风控模型中，score在0.0-0.1区间代表极高风险，这个桶的占比突增，比整体均值变化更有预警价值。我们用histogram_quantile(0.95, sum(rate(model_prediction_score_bucket[1h])) by (le))计算P95分数，再用rate(model_prediction_score_bucket{le="0.1"}[1h]) / rate(model_prediction_score_count[1h])计算该桶占比。

• 告警必须带上下文：Prometheus告警规则里，annotations字段必须包含可操作信息：

  annotations: summary: 'High error rate for {{ $labels.service }} v{{ $labels.version }}' description: 'P99 latency > 1s for 5m. Check Grafana dashboard: https://grafana.example.com/d/ml-model?var-service={{ $labels.service }}&var-version={{ $labels.version }}'

  运维同学收到钉钉告警，点击链接直接跳转到对应服务、对应版本的实时看板，无需再手动筛选。

• 日志必须结构化且低开销：用structlog替代logging，每条日志是JSON：

  {"event": "prediction_start", "request_id": "req_abc123", "model_version": "v2.3.1", "timestamp": "2023-10-05T02:15:33.123Z"}

  这样ELK或Loki能按request_id一键串联整个请求链路（从API入口到模型输出），排查耗时瓶颈。

4. 实操过程与核心环节实现：一个风控模型的72小时上线实录

4.1 Day 0：模型准备与验证（2小时）

• 步骤1：确认ONNX兼容性
  在训练环境（Python 3.9, sklearn 1.2.2）中，用skl2onnx导出模型，指定target_opset=15。用onnx.checker.check_model()验证ONNX文件无语法错误。关键动作：用onnx.shape_inference.infer_shapes()推断输出shape，确认是(1,2)而非(None,2)——动态batch size在生产中是灾难。

• 步骤2：本地ONNX Runtime推理验证
  写一个最小验证脚本：

  import onnxruntime as ort import numpy as np sess = ort.InferenceSession("model.onnx") # 用训练集第一行数据 input_data = X_train[0:1].astype(np.float32) outputs = sess.run(None, {"float_input": input_data}) print("ONNX output:", outputs[0]) # 应为[0.12, 0.88]类 print("Sklearn output:", model.predict_proba(X_train[0:1])) # 对比

  实测心得：必须用X_train[0:1]（保持batch维度），不能用X_train[0]（变成1D array），否则ONNX Runtime会报Invalid shape。我们第一次就栽在这里，花了40分钟debug。

• 步骤3：量化与回归测试
  用线上最近7天的10万条真实请求特征做校准，生成INT8模型。然后用全量校准数据跑回归测试，计算ONNX INT8与原始sklearn的AUC差异。结果：AUC从0.9213降到0.9211，ΔAUC=-0.0002 < 0.001阈值，通过。

4.2 Day 1：服务开发与容器化（6小时）

• 步骤1：构建最小FastAPI服务
  创建main.py，实现/healthz、/predict，集成ONNX Runtime Session加载（带重试）。关键技巧：Session加载放在lifespan事件中，而非全局变量，确保每次启动都重新加载：

  @asynccontextmanager async def lifespan(app: FastAPI): global model_session for i in range(3): # 最多重试3次 try: model_session = ort.InferenceSession("model.onnx") logger.info("Model loaded successfully") break except Exception as e: logger.warning(f"Model load attempt {i+1} failed: {e}") if i == 2: raise await asyncio.sleep(1) yield model_session = None

• 步骤2：编写Dockerfile
  采用多阶段构建，减小镜像体积：

  # 构建阶段 FROM python:3.9-slim COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . /app WORKDIR /app # 运行阶段 FROM python:3.9-slim RUN apt-get update && apt-get install -y libglib2.0-0 && rm -rf /var/lib/apt/lists/* COPY --from=0 /usr/local/lib/python3.9/site-packages /usr/local/lib/python3.9/site-packages COPY --from=0 /app /app CMD ["uvicorn", "main:app", "--host", "0.0.0.0:8000", "--port", "8000", "--workers", "4"]

  注意：libglib2.0-0是onnxruntime的C++依赖，缺了会报ImportError: libglib-2.0.so.0: cannot open shared object file。这个坑我们踩了两次。

• 步骤3：本地Docker测试
  docker build -t fraud-model:v2.3.1 . && docker run -p 8000:8000 fraud-model:v2.3.1，用curl调用/healthz和/predict，确认返回正常。实测发现：默认uvicornworkers=1，压测时QPS仅180；改为--workers 4后，QPS达720，CPU利用率达75%，证明多进程生效。

4.3 Day 2：K8s部署与灰度发布（8小时）

• 步骤1：编写K8s Deployment YAML
  关键配置：

  apiVersion: apps/v1 kind: Deployment metadata: name: fraud-model-v2-3-1 spec: replicas: 3 selector: matchLabels: app: fraud-model version: v2.3.1 template: metadata: labels: app: fraud-model version: v2.3.1 spec: containers: - name: model image: registry.example.com/fraud-model:v2.3.1 ports: - containerPort: 8000 livenessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 5 periodSeconds: 5 resources: requests: memory: "512Mi" cpu: "250m" limits: memory: "1Gi" cpu: "500m"

  经验：requests和limits必须设置。我们曾因没设memory limit，模型在高负载下OOM被K8s kill，但Pod状态显示Running（因liveness探针仍通），导致流量持续打进来，形成雪崩。

• 步骤2：Service与Ingress配置
  创建ClusterIP Service暴露端口，再配Ingress路由：

  apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: fraud-model-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: api.example.com http: paths: - path: /fraud/predict pathType: Prefix backend: service: name: fraud-model-service port: number: 8000

• 步骤3：灰度发布与流量切分
  不直接全量。先用kubectl patch deployment fraud-model-v2-3-1 -p '{"spec":{"replicas":1}}'起1个Pod，通过Ingress的canaryannotation（需Nginx Ingress Controller支持）将1%流量导向新版本：

  nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "1"

  监控重点：在Grafana看新旧版本的http_request_duration_seconds_bucket和model_prediction_score分布。实测结果：v2.3.1的P99延迟比v2.2.0低35%，且score_bin="0.9-1.0"占比稳定在12.3%±0.1%，无漂移。确认无问题后，逐步将权重升至100%。

4.4 Day 3：监控告警与文档交付（2小时）

• 步骤1：配置Prometheus告警规则
  在alert.rules中添加：

  - alert: FraudModelHighLatency expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service="fraud-model", version=~"v2.3.*"}[5m])) by (le, service, version)) > 1 for: 5m labels: severity: warning annotations: summary: "High P99 latency for {{ $labels.service }} {{ $labels.version }}"

• 步骤2：生成API文档与交付清单
  FastAPI自动生成的/docs页面已足够。但必须交付《生产就绪清单》：

  • ✅ 模型版本：fraud-model:v2.3.1
  • ✅ 部署环境：prod-us-east-1
  • ✅ 接口地址：https://api.example.com/fraud/predict
  • ✅ 请求示例：

    curl -X POST https://api.example.com/fraud/predict \ -H "Content-Type: application/json" \ -d '{"user_id":"u123","features":[0.1,0.2,...],"timestamp":1696464000}'

  • ✅ 告警联系人：#ml-ops-alertsSlack频道
  • ✅ 回滚方案：kubectl set image deployment/fraud-model-v2-3-1 model=registry.example.com/fraud-model:v2.2.0

整个72小时，核心不是技术多炫，而是每个环节都有明确的准入/准出标准：ONNX导出必须通过shape校验，Docker镜像必须通过本地curl测试，K8s部署必须通过1%灰度且指标达标。这种工业化流水线思维，才是Part 4想传递的终极答案。

5. 常见问题与排查技巧实录：那些深夜救火的真实案例

5.1 “模型预测结果和Notebook里完全不一样！”——数据管道漂移

• 现象：上线后第一天，模型输出score普遍偏低，AUC从0.92跌到0.85。
• 排查路径：
  1. 查model_input_feature_null_ratio指标，发现feature_age缺失率从0.01%飙升至35%；
  2. 查上游数据管道日志，发现ETL作业因上游数据库锁表超时，跳过了age字段填充；
  3. 查模型输入日志，确认feature_age字段确实为null，但预处理代码未做null填充，导致ONNX Runtime将null转为0，而训练时age的均值是32，0远低于均值，模型判定为异常低龄用户，给出低分。
• 根治方案：
  • 在预处理函数中强制填充：if pd.isnull(x): x = TRAINING_AGE_MEAN；
  • 在K8s中为数据管道作业配置restartPolicy: OnFailure和backoffLimit: 3，避免单点失败；
  • 增加数据质量监控：feature_age_null_ratio > 1%触发告警。

实操心得：永远假设上游数据是恶意的。生产环境里，null不是异常，而是常态。你的预处理代码必须对每个字段声明“如果null，我填什么”，而不是依赖上游保证不null。

5.2 “服务突然503，但Pod状态是Running！”——健康检查假阳性

• 现象：/healthz返回200，但/predict全部超时。
• 排查路径：
  1. kubectl exec -it <pod> -- sh进入容器；
  2. curl -v http://localhost:8000/healthz确认通；
  3. curl -v http://localhost:8000/predict卡住——说明模型Session加载成功，但推理卡死；
  4. top发现Python进程CPU 100%，strace -p <pid>显示在futex系统调用上等待；
  5. 定位到ONNX Runtime的InferenceSession.run()在多线程下被阻塞，原因是session_options.intra_op_num_threads = 0（默认使用所有CPU），而K8s限制了Pod的CPU为500m（0.5核），多线程争抢导致死锁。
• 根治方案：
  • 显式设置线程数：session_options.intra_op_num_threads = 1；
  • 在Dockerfile中设置环境变量：ENV OMP_NUM_THREADS=1（防OpenMP干扰）；
  • K8s资源限制与ONNX线程数必须匹配：cpu limit=500m→intra_op_num_threads=1。

5.3 “为什么同样的请求，两次调用结果不同？”——随机性未关闭

• 现象：对同一user_id连续调用/predict，返回的score有微小浮动（如0.8721 vs 0.8723）。
• 排查路径：
  1. 检查模型代码，发现RandomForestClassifier的n_estimators=100，但random_state未固定；
  2. ONNX Runtime在多线程下，树的遍历顺序受线程调度影响，导致浮点累加误差累积；
  3. 训练时random_state=42，但ONNX导出未固化该状态。
• 根治方案：
  • 训练时必须设random_state=42；
  • ONNX导出时，用options={id(model): {'random_state': 42}}传递；
  • 更彻底：改用XGBoost或LightGBM，它们的ONNX导出天然支持确定性推理。

5.4 “模型版本更新后，旧版API还活着！”——服务发现未刷新

• 现象：v2.3.1已上线，但部分请求仍打到v2.2.0的Pod。
• 排查路径：
  1. kubectl get endpoints fraud-model-service，发现endpoints列表里仍有v2.2.0的Pod IP；
  2. kubectl describe pod <v2.2.0-pod>，发现其status.phase是Running，但readinessProbe失败（因/healthz返回503）；
  3. 原因：v2.2.0的Deployment未删除，Pod虽不健康，但K8s未主动驱逐，Endpoint Controller仍将其IP保留在Endpoints中。
• 根治方案：
  • 每次发布新版本，必须kubectl rollout restart deployment/fraud-model-v2-2-0（触发滚动更新）或kubectl delete deployment/fraud-model-v2-2-0；
  • 在Ingress配置中启用nginx.ingress.kubernetes.io/affinity: "cookie"，确保同一用户始终打到同一版本，避免混流。

5.5 “磁盘空间爆满，Pod反复Crash！”——日志未轮转

• 现象：Pod频繁OOMKilled，kubectl top pods显示内存使用率100%，但du -sh /var/log/发现日志占了20GB。
• 根治方案：
  • 在Dockerfile中配置logrotate：

    RUN apt-get update && apt-get install -y logrotate && rm -rf /var/lib/apt/lists/* COPY logrotate.conf /etc/logrotate.d/myapp

    logrotate.conf内容：

    /var/log/myapp/*.log { daily missingok rotate 7 compress