从Jupyter到生产：机器学习模型部署的工程化实践

1. 项目概述：当模型走出Jupyter，真正开始呼吸真实世界空气

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句暗号，专为那些在Jupyter里调通了模型、画出了漂亮ROC曲线、却在部署时被现实迎面一记重拳打懵的工程师准备的。它不是讲怎么写model.fit()，而是讲你凌晨三点收到告警：线上推理延迟从200ms飙到2.3秒，下游服务开始超时熔断，而你的本地.ipynb文件里连一个pip install命令都还带着--user参数。我做过7个从零到上线的ML服务，其中4个在第一周就因“笔记本思维残留”翻过车：模型体积膨胀三倍却没做ONNX转换，特征工程硬编码了训练时的pandas版本，API返回的JSON里混进了numpy.float32导致前端解析崩溃。这类项目真正的战场不在GPU显存里，而在Kubernetes Pod的内存限制、Nginx的超时配置、Prometheus的指标毛刺，以及运维同事发来的那句：“你这个服务占了节点85%的CPU，能不能别让它‘喘粗气’？”它解决的核心问题非常具体：如何把那个在/notebooks/experiment_20240517.ipynb里跑得飞起的模型，变成一个能扛住每秒300次请求、连续运行90天不重启、出问题时能精准定位到某一行特征处理代码的生产级服务。适合三类人深度参考：刚从数据科学岗转岗MLOps的工程师（需补全系统视角）、带团队交付AI项目的TL（要避开团队协作雷区）、以及正在写技术方案争取预算的架构师（这里全是可量化的成本优化点）。它不承诺“一键部署”，但会告诉你为什么docker build时加--no-cache反而让镜像小了47%，为什么把requirements.txt里scikit-learn==1.3.0改成>=1.3.0,<1.4.0能避免下周的线上事故，以及最关键的——当产品经理突然说“把推荐结果按用户最近一次下单时间倒序”时，你该改哪3个地方、测试哪5个边界case、回滚预案怎么写才不会影响订单履约。

2. 内容整体设计与思路拆解：放弃“完美模型”，拥抱“可控衰减”

2.1 为什么必须抛弃Notebook原生路径？——三个血淋淋的现场故障复盘

很多人以为部署难在“技术”，其实首道坎是思维范式切换。我整理了过去两年协助团队上线的12个模型服务，其中8个初期故障根源直指Notebook惯性：

• 案例1：特征漂移无声吞噬准确率
  某风控模型在Notebook中用pd.read_csv('data/train.csv')加载历史数据，特征工程代码里写死df['age'].fillna(35)。上线后，当新用户提交年龄为空的申请时，服务直接抛KeyError。根本原因？Notebook里所有数据都是“已清洗好”的快照，而生产环境是活水——上游ETL任务某天因网络抖动漏传了age字段，但模型服务没做schema校验，错误静默传播了17小时。解决方案不是修代码，而是建立特征契约（Feature Contract）：用Pydantic定义输入Schema，强制校验字段存在性、类型、取值范围，缺失时触发预设降级策略（如返回{"risk_score": 0.5, "reason": "MISSING_AGE_FIELD"}），而非让整个请求失败。

• 案例2：模型热更新引发雪崩
  团队为快速迭代，在K8s中用ConfigMap挂载模型文件，每次更新就滚动重启Pod。某次新模型因torch.compile()兼容性问题，启动耗时从1.2秒涨到8.6秒。而K8s的readiness probe默认3秒超时，导致大量Pod在“启动中”状态被流量打入，503错误率瞬间冲到42%。教训是：模型加载必须与服务启动解耦。我们后来改用“双模型槽位”设计——服务启动时预加载旧模型并监听S3桶事件，新模型下载校验完成后，原子切换内存中的模型引用，全程无请求中断。这要求Notebook产出物必须包含model_version元数据和health_check()方法，而非一个孤零零的.pkl文件。

• 案例3：监控盲区掩盖性能劣化
  某推荐服务上线后A/B测试显示CTR提升2.3%，但两周后订单转化率反降0.8%。排查发现：模型推理延迟P95从320ms升至680ms，但监控只告警“>1s”，未覆盖业务敏感区间。更致命的是，特征计算耗时占总延迟73%，而Notebook里用df.apply(lambda x: ...)写的UDF在生产环境单核CPU上成了瓶颈。这倒逼我们重构为向量化特征流水线：用Polars替代pandas，将UDF编译为Rust函数，延迟压到190ms内。关键认知转变：Notebook里“能跑通”不等于“能稳住”，生产监控必须按业务黄金指标（如“首屏加载完成前的推荐响应”）分层埋点，而非仅看cpu_usage_percent。

这些案例指向同一个设计原则：生产系统不追求模型指标最优，而追求“可控衰减”。即当数据/环境变化时，系统应明确告知“哪里变了、变多少、是否在容忍阈值内”，而非让指标悄悄滑坡。这要求从Notebook第一行代码就植入生产意识——比如用mlflow.log_param("feature_window_days", 30)记录特征时间窗口，比写注释# 注意：这里用30天数据可靠一万倍。

2.2 架构选型逻辑：为什么选FastAPI+Docker+K8s，而不是Flask或Serverless？

面对“怎么部署”，工程师常陷入工具崇拜。但真正决定成败的是约束条件下的权衡艺术。我们团队在Part 4中锁定FastAPI+Docker+K8s组合，并非因为它“最火”，而是它精准匹配了ML服务的四大刚性需求：

• 需求1：异步I/O密集型场景的吞吐保障
  ML服务80%的耗时不在模型推理，而在特征获取（查Redis/MySQL）、结果后处理（调用风控API）、日志上报（发Kafka）。Flask的同步阻塞模型在此类场景下，单实例QPS卡在120左右。而FastAPI基于Starlette，原生支持async/await，我们实测同一服务：Flask版本在300并发下平均延迟1.8s，FastAPI版本仅0.42s。关键技巧在于分层异步：特征加载用await aioredis.get()，模型推理保持同步（GPU计算不适用async），后处理用asyncio.to_thread()包裹CPU密集型操作。这种混合模式让资源利用率提升3.2倍。

• 需求2：模型热更新的原子性与零停机
  Serverless（如AWS Lambda）虽宣称“自动扩缩”，但冷启动延迟（300-1200ms）对延迟敏感型服务（如实时竞价）不可接受。更致命的是，Lambda不支持进程内模型热替换——每次更新必重建执行环境。而K8s+Docker方案中，我们通过Sidecar容器模式实现优雅升级：主容器运行FastAPI服务，Sidecar容器监听模型存储（如MinIO），检测到新模型后，通过Unix Domain Socket通知主容器执行model.load_state_dict()，整个过程在150ms内完成，且不中断现有连接。这需要Notebook导出模型时，额外生成model_signature.json描述输入输出schema，否则Sidecar无法验证新模型兼容性。

• 需求3：可观测性的深度集成能力
  生产环境故障80%源于“不知道哪里慢”。Prometheus生态对FastAPI有原生支持（prometheus-fastapi-instrumentator库），可自动采集http_request_duration_seconds等指标，并按endpoint、model_version、http_status多维标签切片。而Flask需手动埋点，Serverless的指标粒度仅到函数级别，无法定位到“/predict接口中feature_engineering.py第47行耗时异常”。我们甚至用OpenTelemetry将trace链路延伸到特征数据库——当某个请求延迟飙升，可直接下钻看到“redis.get('user_features_12345')耗时840ms”，而非笼统的“API慢”。

• 需求4：团队协作的契约清晰度
  数据科学家习惯在Notebook里写import matplotlib.pyplot as plt; plt.show()，但这在Docker容器里会报错。FastAPI强制要求接口契约先行：用Pydantic定义PredictRequest和PredictResponse，自动生成Swagger文档，前端、测试、运维均可据此工作。而Flask的request.json是动态字典，Serverless的event payload结构随云厂商变化。我们曾因Flask服务未定义输入schema，导致前端传"user_id": "123"（字符串）而模型期待int，线上报TypeError长达6小时——因为错误日志被淹没在千条正常请求中。

选择这套栈的本质，是用框架的约束力对抗人的随意性。它强迫你在Notebook阶段就思考：这个模型需要什么输入格式？哪些字段可为空？预测失败时该返回什么错误码？这些思考沉淀为代码，而非会议纪要。

2.3 核心演进路径：从Part 1到Part 4的渐进式加固

本系列标题强调“Part 4”，暗示这不是孤立方案，而是经过三次实战迭代的结晶。理解其演进逻辑，比直接抄代码更重要：

• Part 1：Notebook到脚本的“保命迁移”
  核心目标：让模型脱离Jupyter，能在Linux服务器上稳定运行。典型动作：将.ipynb转为.py，用argparse接收输入路径，joblib.dump()保存模型。此时痛点是环境不一致——Notebook用Python 3.9.16，服务器只有3.8.10，scikit-learn版本冲突导致RandomForestClassifier预测结果偏差0.3%。解决方案：引入pyenv管理Python版本，pip-compile生成锁定版requirements.txt，确保pip install -r requirements.txt在任何机器上安装完全相同的包。

• Part 2：脚本到API的“可用封装”
  目标：提供HTTP接口供业务方调用。此时暴露新问题：无并发控制。简单用Flask.run()启动，10并发请求就让GIL锁死CPU。我们引入Gunicorn作为WSGI服务器，配置workers=4（CPU核心数+1），worker_class="gevent"启用协程。但很快发现：特征计算仍阻塞主线程。于是加入线程池隔离：用concurrent.futures.ThreadPoolExecutor执行特征加载，主线程专注模型推理，避免I/O拖垮计算。

• Part 3：API到服务的“可靠加固”
  目标：满足SLA要求（如99.95%可用性）。关键升级：

  • 健康检查：/healthz端点不仅检查进程存活，还验证Redis连接、模型加载状态、特征缓存命中率；
  • 限流熔断：用slowapi库对/predict接口限流（如1000 req/min），超限时返回429 Too Many Requests；
  • 配置中心化：将MODEL_PATH、REDIS_URL等从代码移至环境变量，通过K8s ConfigMap注入，避免修改代码发布新镜像。

• Part 4：服务到系统的“智能自治”（当前重点）
  目标：系统具备自适应、自诊断、自愈能力。这是质变：

  • 自适应：根据实时QPS自动调整特征缓存TTL（高流量时缩短TTL保新鲜度，低流量时延长TTL降DB压力）；
  • 自诊断：当预测延迟P95 > 500ms持续5分钟，自动触发profile_feature_pipeline()，生成火焰图定位瓶颈；
  • 自愈：检测到模型AUC在滑动窗口内下降超阈值，自动回滚至前一版本模型，并邮件通知负责人。

这个演进不是线性叠加，而是用新能力解决旧阶段暴露的深层问题。Part 4的“智能自治”，恰恰源于Part 2中手工限流的痛苦——当业务方频繁提“再加100QPS配额”时，你意识到：靠人工调参永远追不上业务增速，必须让系统自己学会呼吸。

3. 核心细节解析与实操要点：把每个“理所当然”变成可验证的契约

3.1 模型导出：为什么.pkl不是生产级格式？ONNX的三重收益与避坑指南

数据科学家交来的第一个“生产件”，通常是.pkl文件。但在我经手的23个上线项目中，17个因.pkl栽过跟头：pandas.DataFrame序列化后体积暴涨4倍；sklearn版本不一致导致transform()方法签名变更；甚至pickle反序列化时执行了恶意代码（虽罕见，但金融客户审计必查）。Part 4强制要求：所有模型必须导出为ONNX格式，并附带完整验证流程。

ONNX的价值远不止“跨框架”——它本质是模型行为的数学契约。我们要求Notebook中必须包含以下验证代码块：

# 在Notebook末尾强制执行 import onnx import onnxruntime as ort import numpy as np # 1. 导出ONNX（以sklearn RandomForest为例） from skl2onnx import convert_sklearn from skl2onnx.common.data_types import FloatTensorType initial_type = [('float_input', FloatTensorType([None, X_train.shape[1]]))] onnx_model = convert_sklearn( model, initial_types=initial_type, target_opset=15, # 明确指定opset，避免版本漂移 options={id(model): {'zipmap': False}} # 禁用zipmap，输出纯numpy数组 ) with open("model.onnx", "wb") as f: f.write(onnx_model.SerializeToString()) # 2. 严格验证：输入输出一致性 sess = ort.InferenceSession("model.onnx") input_name = sess.get_inputs()[0].name output_name = sess.get_outputs()[0].name # 用训练集同分布数据验证 test_input = X_test[:10].astype(np.float32) # 强制float32，ONNX要求 onnx_pred = sess.run([output_name], {input_name: test_input})[0] # 3. 与原始模型对比（允许微小浮点误差） sklearn_pred = model.predict_proba(test_input)[:, 1] assert np.allclose(onnx_pred.flatten(), sklearn_pred, atol=1e-5), \ "ONNX output deviates from sklearn beyond tolerance" # 4. 验证模型元数据（供生产环境读取） meta = onnx_model.metadata_props assert b"model_version" in meta and meta[b"model_version"], "Missing model_version metadata"

这段代码看似繁琐，但它解决了三个生产核心问题：

• 问题1：环境隔离
  ONNX Runtime（ORT）是C++编写的轻量引擎，不依赖Python环境。我们实测：一个XGBoost模型，.pkl加载需1.8s（含xgboost库导入），ONNX加载仅0.03s。更重要的是，ORT Docker镜像仅87MB，而conda环境镜像常超2GB——这意味着K8s滚动更新时，新Pod启动速度提升40倍，极大降低发布风险。

• 问题2：安全审计
  .pkl文件可执行任意Python代码，而ONNX是纯张量计算图。金融客户的安全扫描工具（如Trivy）对ONNX文件直接放行，对.pkl则标记“高危”。我们曾因此避免了一次紧急下线——某外包团队提交的.pkl文件中嵌入了os.system("curl http://malicious.site")。

• 问题3：硬件加速透明化
  ORT支持CUDA、TensorRT、CoreML等后端，无需修改模型代码。在K8s中，我们通过环境变量ORT_PROVIDER=cuda即可启用GPU加速，而.pkl模型需重写model.cuda()逻辑。更妙的是，ORT提供get_providers()方法，服务启动时可自检硬件能力：若检测到GPU但ORT_PROVIDER未设，自动告警并降级到CPU，避免“明明有卡却不用”的资源浪费。

提示：ONNX导出常见陷阱——sklearn的StandardScaler若用fit_transform()而非fit()，导出的ONNX会包含训练数据统计量，导致线上推理时transform()行为异常。正确做法：在Notebook中明确分离scaler.fit(X_train)和scaler.transform(X_test)，导出时仅用fit后的scaler。

3.2 特征服务化：为什么不能在API里写pd.read_sql()？Feast vs 自研的决策树

生产环境中，85%的延迟来自特征获取。新手常在FastAPI的/predict路由里直接写pd.read_sql("SELECT * FROM user_features WHERE id=%s", [user_id])，这在10QPS下尚可，但到100QPS时，数据库连接池瞬间打满。Part 4要求：特征必须服务化，且与模型服务解耦。我们评估过Feast、Hopsworks、自研方案，最终选择轻量级自研+Redis缓存，原因如下：

我们自研的核心是三层特征抽象：

• Layer 1：原子特征（Atomic Features）
  直接映射数据库字段，如user_age、last_order_amount。通过SQL视图定义，保证数据源唯一性。例如：

  CREATE VIEW user_atomic_features AS SELECT id AS user_id, EXTRACT(YEAR FROM AGE(NOW(), birth_date))::INT AS user_age, COALESCE((SELECT amount FROM orders WHERE user_id=u.id ORDER BY created_at DESC LIMIT 1), 0) AS last_order_amount FROM users u;

• Layer 2：衍生特征（Derived Features）
  基于原子特征计算，如age_group（将user_age映射为"18-25"、"26-35"等）。在应用层用Python计算，但强制缓存：

  # features/derived.py def get_age_group(user_id: int) -> str: age = get_atomic_feature("user_age", user_id) # 从Redis读 if age < 18: return "under_18" elif age <= 25: return "18_25" # ... 其他分组 else: return "over_55" # 缓存键设计：f"derived:age_group:{user_id}"

• Layer 3：向量特征（Vector Features）
  多值特征，如用户最近10次订单金额列表。为避免Redis大key，我们采用分片存储：

  # 存储：user_orders:12345:0 -> [120, 85, 200] （第0片） # user_orders:12345:1 -> [150, 90] （第1片） def get_user_orders(user_id: int, limit: int = 10) -> List[float]: # 计算分片数 shards = math.ceil(limit / 5) # 每片存5个 all_orders = [] for shard in range(shards): key = f"user_orders:{user_id}:{shard}" orders = redis.lrange(key, 0, -1) all_orders.extend([float(x) for x in orders]) return all_orders[:limit]

这套设计让特征获取延迟稳定在8ms内（P99），而直连数据库在100QPS下P99达420ms。关键经验：不要追求“大一统”特征平台，先解决最痛的3个特征。我们上线首月只服务user_age、last_order_amount、order_count_30d三个特征，两周后扩展到12个，比一开始就上Feast节省了3人周。

3.3 API设计：Pydantic Schema不是摆设，而是生产环境的“防撞护栏”

很多团队把Pydantic当JSON校验器用，只写class Request(BaseModel): user_id: int。但在Part 4中，它承担着生产环境第一道防线的职责。我们强制要求每个模型服务的Schema包含四层防御：

• 防御层1：业务语义校验（Business Semantics）
  不止检查类型，更要检查业务规则。例如风控模型：

  from pydantic import BaseModel, Field, validator from typing import Optional class PredictRequest(BaseModel): user_id: int = Field(..., ge=1, le=2147483647, description="用户ID必须为正整数") device_fingerprint: str = Field(..., min_length=32, max_length=64, description="设备指纹需32-64位hex字符串") transaction_amount: float = Field(..., ge=0.01, le=1000000.0, description="交易金额0.01-100万") @validator('device_fingerprint') def validate_hex_string(cls, v): try: bytes.fromhex(v) # 确保是合法hex return v except ValueError: raise ValueError('device_fingerprint must be valid hex string')

  这段代码让transaction_amount=-5.0的请求在进入模型前就被422 Unprocessable Entity拦截，避免模型内部if amount < 0: raise ValueError导致的500错误——后者会触发告警，前者只是日志记录。

• 防御层2：性能保护校验（Performance Guard）
  防止恶意请求拖垮服务。例如推荐模型：

  class RecommendRequest(BaseModel): user_id: int top_k: int = Field(default=10, ge=1, le=100) # 严格限制top_k，避免O(n²)计算 context: dict = Field(default_factory=dict) # 上下文信息，但限制大小 @validator('context') def validate_context_size(cls, v): size_bytes = len(str(v).encode('utf-8')) if size_bytes > 10240: # 10KB raise ValueError('context size exceeds 10KB limit') return v

  我们曾遭遇攻击者发送10MB JSON的context字段，导致服务内存溢出OOM。此校验将单请求内存占用控制在128MB内。

• 防御层3：灰度路由校验（Canary Routing）
  为A/B测试预留扩展点：

  class PredictRequest(BaseModel): # ... 其他字段 experiment_id: Optional[str] = Field( None, regex=r'^[a-z0-9]+(-[a-z0-9]+)*$', # 符合K8s label规范 description="实验ID，用于路由到特定模型版本" )

  FastAPI中间件根据experiment_id将请求转发至不同K8s Service（如model-v1、model-v2-canary），无需修改模型代码。

• 防御层4：审计追踪校验（Audit Trail）
  为合规留痕：

  from datetime import datetime import uuid class PredictRequest(BaseModel): # ... 其他字段 request_id: str = Field(default_factory=lambda: str(uuid.uuid4())) timestamp: datetime = Field(default_factory=datetime.utcnow) class Config: # 自动转换datetime为ISO格式，便于日志分析 json_encoders = { datetime: lambda v: v.isoformat(timespec='milliseconds') }

  所有请求日志自动包含request_id，可关联Kafka消息、数据库事务、模型预测结果，满足GDPR“数据可追溯”要求。

注意：Pydantic校验发生在FastAPI的BackgroundTasks之前，这意味着即使你用@app.post("/predict", background=True)，校验失败也会立即返回错误，不会进入后台队列。这是设计精妙之处——把最廉价的校验放在最前端。

4. 实操过程与核心环节实现：从Dockerfile到K8s Manifest的逐行解读

4.1 Dockerfile：为什么基础镜像选python:3.11-slim-bookworm？多阶段构建的5个关键步骤

Docker镜像是生产环境的第一张脸。我们拒绝FROM python:3.11这种“大而全”的基础镜像，坚持python:3.11-slim-bookworm，原因直击痛点：镜像体积每减少1MB，K8s Pod启动时间平均缩短120ms。实测数据：python:3.11镜像2.1GB，slim-bookworm仅127MB，相同服务启动时间从8.3s降至1.2s。

我们的Dockerfile采用五阶段构建法，每一步都有明确目的：

# Stage 1: 构建依赖（Build Dependencies） FROM python:3.11-slim-bookworm AS builder # 安装编译工具（仅构建阶段需要） RUN apt-get update && apt-get install -y --no-install-recommends \ build-essential \ libpq-dev \ libjpeg-dev \ zlib1g-dev \ && rm -rf /var/lib/apt/lists/* # 复制requirements.txt并安装（利用Docker layer cache） COPY requirements.txt . RUN pip wheel --no-cache-dir --no-deps --wheel-dir /wheels -r requirements.txt # Stage 2: 运行时基础（Runtime Base） FROM python:3.11-slim-bookworm # 创建非root用户（安全刚需） RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001 # 复制构建好的wheel包（跳过编译，极速安装） COPY --from=builder /wheels /wheels COPY --from=builder /usr/local/bin/ /usr/local/bin/ RUN pip install --no-cache /wheels/*.whl # 清理构建工具（减小镜像体积） RUN apt-get clean && rm -rf /var/lib/apt/lists/* # Stage 3: 模型与配置（Model & Config） FROM python:3.11-slim-bookworm AS model-stage # 复制ONNX模型和特征schema COPY model.onnx /app/model.onnx COPY features/schema.json /app/features/schema.json # Stage 4: 应用代码（Application Code） FROM python:3.11-slim-bookworm # 复制运行时基础 COPY --from=Stage 2 /usr/local /usr/local COPY --from=Stage 2 /etc/passwd /etc/passwd # 复制应用代码（注意：不复制tests/，减小体积） COPY app/ /app/ WORKDIR /app # Stage 5: 最终镜像（Final Image） FROM python:3.11-slim-bookworm # 复制所有必要组件 COPY --from=Stage 2 /usr/local /usr/local COPY --from=Stage 3 /app/model.onnx /app/model.onnx COPY --from=Stage 3 /app/features/schema.json /app/features/schema.json COPY --from=Stage 4 /app /app # 设置非root用户 USER appuser:appgroup # 健康检查（K8s readiness probe） HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8000/healthz || exit 1 # 启动命令（使用uvicorn，比gunicorn更轻量） CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0:8000", "--port", "8000", "--workers", "4"]

这个Dockerfile的每个选择都经过血泪验证：

• slim-bookworm的选择：Debian Bookworm比Bullseye更新，预装openssl 3.0，避免requests库SSL握手失败（我们曾因此在AWS EKS上故障3小时）；
• 多阶段构建：Stage 1安装build-essential，Stage 2彻底删除，最终镜像不含编译器，攻击面缩小92%；
• pip wheel预编译：requirements.txt中torch==2.1.0+cu118这种带CUDA的包，在Stage 1中编译为wheel，Stage 4直接安装，避免在生产环境下载GB级文件；
• 非root用户：USER appuser是K8s PodSecurityPolicy强制要求，否则集群拒绝部署；
• uvicorn而非gunicorn：Uvicorn原生支持ASGI，启动内存占用比Gunicorn低40%，且--workers 4在4核机器上达到最佳吞吐。

实操心得：在CI/CD中，我们增加docker image ls -s检查镜像体积，若超过180MB自动失败。这迫使团队清理无用依赖——某次发现matplotlib被误引入生产镜像（仅用于Notebook绘图），移除后镜像缩小142MB。

4.2 K8s部署：Service、Deployment、HPA的协同设计与参数精调

K8s不是“把Docker跑起来”那么简单，它是资源、流量、弹性的三维博弈场。我们为ML服务设计的Manifest，核心是三个对象的精密配合：

Deployment：资源请求与限制的黄金比例

apiVersion: apps/v1 kind: Deployment metadata: name: ml-model-service spec: replicas: 3 # 至少3副本，满足K8s滚动更新最小可用性 selector: matchLabels: app: ml-model-service template: metadata: labels: app: ml-model-service spec: containers: - name: model-api image: registry.example.com/ml-model:v4.2.1 ports: - containerPort: 8000 resources: requests: memory: "1Gi" # 必须设置，K8s调度依据 cpu: "500m" # 0.5核，保证最低计算资源 limits: memory: "2Gi" # 防止OOM Killer，但不宜过高 cpu: "1500m" # 1.5核，允许突发计算 # 关键：Liveness/Readiness探针 livenessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 60 # 模型加载需时间，不能太短 periodSeconds: 30 timeoutSeconds: 5 readinessProbe: httpGet: path: /readyz port: 8000 initialDelaySeconds: 30 # 就绪检查可稍快 periodSeconds: 10 timeoutSeconds: 3 # 就绪探针失败时，K8s停止转发流量，但不重启Pod failureThreshold: 3

参数精调逻辑：

• requests.memory: 1Gi：基于模型ONNX文件大小（320MB）+ 特征缓存（512MB）+ Python运行时（256MB）估算，留20%余量；
• limits.memory: 2Gi：若服务内存超2Gi，K8s OOM Killer会杀掉进程，但initialDelaySeconds: 60确保模型加载完成后再开始探针，避免误杀；
• readinessProbe.periodSeconds: 10：高频检查，确保流量只打到健康Pod；
• /readyz端点比/healthz更严格：它检查Redis连接、特征缓存命中率>95%、模型加载成功，任一失败即标记Pod为NotReady。

Service：ClusterIP + Headless的混合模式

# ClusterIP Service：供集群内其他服务调用 apiVersion: v1 kind: Service metadata: name: ml-model-service spec: selector: app: ml-model-service ports: - port: 8000 targetPort: 8000 type: ClusterIP # Headless Service：供模型自身发现（用于分布式特征计算） apiVersion: v1 kind: Service metadata: