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

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句暗号，专为那些在Jupyter里调通了模型、画出了漂亮ROC曲线、却在部署时被生产环境一记闷棍打懵的工程师准备的。它不是讲怎么写loss函数，也不是教你怎么调参，而是直面一个残酷现实：你笔记本里那个准确率98.7%的模型，在真实世界里可能连API请求都接不住，更别说稳定跑满一周不崩了。我带过三支AI工程团队，亲手把27个模型从实验室推到银行风控、电商推荐、工业质检等一线场景，最常听到的抱怨不是“模型不准”，而是“昨天还好好儿的，今天就503了”“客户说响应慢，我们查日志发现是GPU显存被另一个服务偷偷占光了”“模型版本对不上，A/B测试结果全乱套”。Part 4之所以关键，是因为它跳出了前几部分聚焦的模型封装（Docker）、基础API（Flask/FastAPI）和简单监控（Prometheus），直击生产环境的“脏活累活”：流量洪峰下的弹性伸缩、多模型共存时的资源隔离、灰度发布中的流量染色与回滚决策、以及当所有监控告警都亮红灯时，你该先看哪一行日志。它解决的不是“能不能跑”，而是“能不能像自来水一样稳定、像电梯一样可靠、像交通信号灯一样可预期地运行”。适合谁？不是刚学完scikit-learn的新人，而是已经用FastAPI搭过API、用Docker打包过镜像、甚至配过基本Prometheus指标，但一上线就手忙脚乱的中级ML工程师；是数据科学家想转岗MLOps时必须啃下的硬骨头；更是技术负责人评估团队是否真具备模型交付能力的试金石。它不承诺“一键上生产”，但能让你下次面对运维同事那句“这个模型又吃光内存了”，底气十足地回一句：“我来调下cgroup限制，顺便把它的QoS等级设成Burstable”。

2. 核心设计思路：为什么放弃“单体API+手动扩缩容”，选择Kubernetes原生调度

2.1 传统方案的三大死穴：从“能用”到“敢用”的鸿沟

很多团队的第一反应是：既然模型能跑在Flask里，那就用Nginx做反向代理，再配个简单的负载均衡，流量大了就手动加几台服务器——这套方案在POC阶段确实快，但一旦进入真实业务线，立刻暴露三个无法回避的硬伤：

第一是资源争抢不可控。想象一下，你的电商推荐模型（CPU密集型）和实时图像质检模型（GPU密集型）都部署在同一台物理机上。某天大促开始，推荐服务流量暴涨，CPU使用率冲到95%，操作系统开始疯狂swap，结果连带把质检服务的GPU推理延迟从50ms拖到800ms，产线质检报警直接停机。传统方案里，你得靠人肉盯监控，再ssh上去kill进程，这中间的分钟级延迟，就是客户流失和产线停工的时间。而Kubernetes的ResourceQuota和LimitRange能从Pod创建那一刻起，就强制钉死每个模型实例的CPU/内存/GPU上限，比如给质检服务分配nvidia.com/gpu: 1且limits.memory: 4Gi，系统会直接拒绝超限申请，把争抢扼杀在摇篮里。

第二是扩缩容决策滞后且粗糙。手动扩缩容依赖运维经验，往往等CPU飙到80%才加机器，此时用户已感知卡顿；而基于CPU平均值的自动扩缩容（HPA）又太迟钝——一个突发的秒杀请求可能让CPU瞬间冲到100%，但HPA需要连续30秒采样达标才触发扩容，这30秒足够订单流失。Part 4采用的是多维度指标驱动的分层扩缩容：底层用K8s HPA监听CPU/内存，中层用自定义指标（如model_latency_p95）触发快速扩容，顶层则接入业务指标（如“每分钟未处理的预测请求队列长度”）。我实测过一个金融风控模型，当队列长度>50时，HPA能在8秒内启动新Pod，比纯CPU策略快4倍，且避免了“为防抖动而过度扩容”的资源浪费。

第三是发布风险无法收敛。传统“全量发布”模式下，一个有bug的模型版本上线，影响的是100%用户。Part 4强制推行金丝雀发布（Canary Release），通过Istio服务网格将1%的流量切给新版本，同时实时对比新旧版本的error_rate和latency_p99。一旦新版本错误率超过基线0.5%，系统自动将流量切回旧版，并触发告警。去年我们一个OCR模型升级后，p99延迟突增200ms，这套机制在12秒内完成回滚，而人工发现+决策+操作至少要5分钟。

提示：别迷信“K8s万能论”。我见过团队把单个轻量模型硬塞进K8s，结果运维复杂度飙升，反而不如用AWS Lambda按需执行。判断标准很简单：如果你的模型需要持续在线、低延迟响应、且资源需求波动大，K8s是解药；如果只是每天跑一次批处理，Shell脚本+定时任务更干净。

2.2 架构选型逻辑：为什么是K8s + Istio + Prometheus + Grafana，而不是其他组合

市面上MLOps工具链五花八门，但Part 4锁定这套组合，是经过数十次线上事故复盘后的理性选择：

• Kubernetes（K8s）是事实标准的“操作系统”：它不关心你跑的是Python还是Java，是TensorFlow还是PyTorch，只认容器镜像和YAML声明。这意味着你的模型服务、特征预处理服务、结果后处理服务，可以统一用同一套编排语言管理。更重要的是，K8s的Operator机制允许你封装领域知识——比如我们自研的ModelServingOperator，只要声明apiVersion: ml.example.com/v1 kind: ModelService，它就能自动创建Service、Deployment、HPA、甚至配置GPU节点亲和性，把运维动作变成声明式代码。

• Istio替代Nginx，解决服务网格级治理：Nginx只能做七层路由，而Istio的Envoy代理嵌入每个Pod，能实现请求级流量控制。比如，你可以精确指定“来自user-service的请求走v1版本，来自admin-dashboard的请求走v2版本”，这对AB测试和权限隔离至关重要。更关键的是，Istio的VirtualService和DestinationRule能实现细粒度熔断——当质检服务错误率>10%时，自动将后续请求转发到降级的CPU版模型，而非直接返回500，保障业务连续性。

• Prometheus + Grafana构成“可观测性铁三角”：很多团队只监控服务器CPU，但模型服务的关键指标是model_inference_duration_seconds、model_cache_hit_ratio、gpu_utilization。Prometheus的Pull模型天然适配K8s的动态Pod发现，我们通过prometheus-operator自动注入ServiceMonitor，让每个模型Pod暴露/metrics端点。Grafana看板则按角色定制：给算法同学看accuracy_vs_latency散点图，给运维看pod_restart_count_by_model热力图，给产品看api_success_rate_by_endpoint趋势图。一个真实案例：某次模型性能下降，Grafana看板显示cache_hit_ratio从95%暴跌至30%，我们立刻定位到Redis连接池配置错误，而非盲目怀疑模型本身。

• 为什么不用Kubeflow？Kubeflow功能强大，但它的Pipeline、Katib等组件对中小团队是重型武器。Part 4追求的是“最小可行MLOps”：用原生K8s能力解决80%问题，只在必要处（如超参搜索）引入Kubeflow。就像你不会为了煮一碗面就买整套米其林厨房设备。

3. 核心实操环节：从模型镜像到生产就绪的七步落地法

3.1 步骤一：构建生产级模型镜像——告别“pip install -r requirements.txt”

Jupyter里pip install的随意性，在生产环境是灾难源头。Part 4要求镜像构建必须满足三个硬指标：确定性、最小化、可追溯。

确定性意味着每次构建相同Dockerfile，产出完全一致的镜像ID。我们弃用pip install -r requirements.txt，改用pip-compile生成锁文件：

# 生成requirements.in（只写核心依赖） echo "torch==1.13.1" > requirements.in echo "transformers>=4.25.0" >> requirements.in # 编译出带哈希的锁文件 pip-compile requirements.in --output-file requirements.txt

这样requirements.txt里每一行都包含--hash=sha256:xxx，Docker build时pip install -r requirements.txt会校验哈希，杜绝“本地能跑，线上报错”的玄学问题。

最小化要求镜像体积尽可能小。我们不用python:3.9-slim，而是基于python:3.9-slim-bookworm（Debian 12），并启用多阶段构建：

# 构建阶段：安装编译依赖 FROM python:3.9-slim-bookworm AS builder RUN apt-get update && apt-get install -y gcc && rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install --no-cache-dir --user -r requirements.txt # 运行阶段：仅复制编译产物 FROM python:3.9-slim-bookworm COPY --from=builder /root/.local /root/.local COPY src/ /app/ WORKDIR /app CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "4", "app:app"]

最终镜像体积从1.2GB压到320MB，拉取速度提升3倍，安全扫描漏洞减少70%。

可追溯性则通过Git Commit ID注入实现。在CI流程中，Docker build命令加入参数：

docker build -t my-model:$(git rev-parse --short HEAD) .

这样每个镜像Tag都对应确切代码版本，线上出问题时，docker inspect一眼看到是哪个commit导致的。

注意：GPU镜像必须严格匹配宿主机驱动版本。我们用nvidia/cuda:11.7.1-runtime-ubuntu20.04基础镜像，并在K8s节点上用nvidia-smi验证驱动版本，不匹配则Pod直接Pending，绝不妥协。

3.2 步骤二：编写K8s声明式配置——YAML不是配置，是契约

很多人把K8s YAML当配置文件写，这是最大误区。Part 4强调：YAML是团队间的服务契约，它定义了“这个模型服务承诺提供什么SLA”。一个生产就绪的model-deployment.yaml必须包含：

• 资源请求（requests）与限制（limits）的精确计算：
  以一个BERT文本分类模型为例，我们通过kubectl top pods观察其稳定期资源占用：
  CPU: 1.2 cores, Memory: 2.8Gi, GPU: 0.5
  则设置：

  resources: requests: cpu: "1200m" # 保证最低1.2核 memory: "2800Mi" # 保证最低2.8Gi nvidia.com/gpu: 1 # 请求1块GPU limits: cpu: "2000m" # 防止CPU抢占 memory: "4Gi" # OOM前强制GC nvidia.com/gpu: 1 # GPU不可超分

  关键逻辑：requests决定调度（K8s只把Pod调度到有足够空闲资源的节点），limits决定约束（超出则被Kill）。若只设limits不设requests，K8s会按0资源调度，导致节点资源挤爆。

• 健康探针（Liveness/Readiness）的语义化配置：
  livenessProbe不是检查端口通不通，而是检查“模型是否还能正确推理”。我们在FastAPI中添加/health/live端点，内部执行：

  # 检查模型加载状态 if not model.is_loaded(): return JSONResponse(status_code=503, content={"status": "model_loading"}) # 执行轻量级推理（不走完整pipeline） result = model.quick_infer("test") if result is None: return JSONResponse(status_code=503, content={"status": "inference_failed"})

  readinessProbe则检查“是否准备好接收流量”，比如等待特征缓存预热完成。探针失败时，K8s会重启Pod（liveness）或从Service Endpoint移除（readiness），而非让故障服务继续吸血。

• 节点亲和性（Node Affinity）确保GPU资源精准匹配：

  affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "nvidia.com/gpu.product" operator: In values: ["A10", "A100"] # 只调度到A10/A100节点

3.3 步骤三：实现多模型共享GPU——用NVIDIA Device Plugin和MIG切分

GPU是昂贵资源，但很多团队让每个模型独占一张卡，利用率常年低于30%。Part 4采用两级GPU共享策略：

第一级是时间复用：通过NVIDIA Device Plugin，K8s能识别GPU为可调度资源。我们配置nvidia-device-pluginDaemonSet，使每个GPU节点暴露nvidia.com/gpu: 2（双卡）或nvidia.com/gpu: 4（四卡）。然后在Deployment中按需申请：

# 轻量模型申请0.25卡 resources: limits: nvidia.com/gpu: 1 # 注意：K8s不支持小数，需用MIG

但这不够，因为K8s原生不支持GPU分数申请。所以第二级是空间复用：启用NVIDIA Multi-Instance GPU（MIG）技术。在A100服务器上，一张GPU可切分为7个实例（如1g.5gb, 2g.10gb等）。我们通过nvidia-smi -i 0 -mig 1启用MIG，再用nvidia-smi -L查看实例：

GPU 0; 1g.5gb; MIG UUID: GPU-xxx/1/0 GPU 0; 2g.10gb; MIG UUID: GPU-xxx/2/0

此时K8s Device Plugin会将每个MIG实例识别为独立GPU设备。模型Deployment即可精确申请：

resources: limits: "nvidia.com/mig-1g.5gb": 1 # 申请1个1g.5gb实例

实测效果：一个A100节点（40GB显存）切分为4个1g.5gb实例，可同时运行4个轻量NLP模型，GPU利用率从25%提升至85%，月度云成本降低42%。

实操心得：MIG切分后，不同实例间显存完全隔离，但计算单元（SM）仍存在微弱干扰。我们通过nvidia-smi dmon -s u -d 1监控各实例的sm__inst_executed指标，确保无异常波动。若发现干扰，立即调整MIG配置。

3.4 步骤四：配置Istio金丝雀发布——用流量染色实现零风险上线

金丝雀发布不是简单分流，而是带上下文的智能路由。Part 4的Istio配置包含三个关键层：

1. 流量入口层（Gateway）：定义外部访问入口

   apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: model-gateway spec: selector: istio: ingressgateway servers: - port: {number: 80, name: http, protocol: HTTP} hosts: ["ml-api.example.com"]

2. 服务发现层（VirtualService）：定义路由规则

   apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: text-classifier spec: hosts: - "ml-api.example.com" gateways: - model-gateway http: - match: - headers: x-canary: {exact: "true"} # 通过Header染色 route: - destination: host: text-classifier subset: v2 # 新版本 weight: 100 - match: - headers: user-agent: {regex: ".*curl.*"} # curl请求走新版本 route: - destination: host: text-classifier subset: v2 - route: # 默认走旧版本 - destination: host: text-classifier subset: v1 weight: 100

3. 目标版本层（DestinationRule）：定义子集（Subset）

   apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: text-classifier spec: host: text-classifier subsets: - name: v1 labels: version: v1.0.0 - name: v2 labels: version: v2.0.0

上线时，我们先部署v2版本Pod（带version: v2.0.0标签），再更新VirtualService将1%流量导向v2。同时，通过Prometheus采集istio_requests_total{destination_service="text-classifier", destination_version="v2"}指标，结合Grafana看板实时监控v2的rate(istio_request_duration_seconds_bucket{le="0.5"}[5m])（500ms内响应率）。一旦该指标低于v1基线2个百分点，立即回滚VirtualService配置——整个过程全自动，无需人工干预。

3.5 步骤五：构建模型专属监控看板——从“服务器监控”到“业务监控”

生产环境监控不能只看CPU，必须穿透到模型行为层。Part 4的Grafana看板包含四个核心视图：

• 模型健康视图（Health Dashboard）：
  展示model_load_time_seconds（模型加载耗时）、model_cache_hit_ratio（特征缓存命中率）、gpu_memory_used_bytes（GPU显存使用量）。当cache_hit_ratio低于90%，自动触发告警，提示特征服务异常。

• 推理性能视图（Performance Dashboard）：
  关键指标是model_inference_duration_seconds的p50/p95/p99分位数。我们用Prometheus的histogram_quantile函数计算：

  histogram_quantile(0.95, sum(rate(model_inference_duration_seconds_bucket[5m])) by (le, model_name))

  并设置告警规则：若p99 > 1000ms持续5分钟，则通知算法同学优化模型。

• 业务影响视图（Business Impact Dashboard）：
  将模型指标与业务结果关联。例如，电商推荐模型的recommendation_ctr（点击率）与model_latency_p95做散点图。我们发现当延迟>300ms时，CTR下降12%，这直接证明了优化延迟的商业价值。

• 资源效率视图（Efficiency Dashboard）：
  展示container_cpu_usage_seconds_total与model_inference_count的比值，即“每千次推理消耗的CPU秒数”。该值越低，说明模型越高效。我们曾通过量化INT8将某OCR模型的该值从420降至180，同等硬件支撑请求量翻倍。

常见问题：Prometheus默认只保留15天数据，但模型问题常需回溯30天。解决方案是配置--storage.tsdb.retention.time=30d，或对接长期存储如Thanos。

4. 真实问题排查手册：线上事故的12个高频现场与我的应对清单

4.1 问题一：模型API响应延迟突增300%，但CPU/Memory一切正常

现象：Grafana看板显示model_inference_duration_seconds_p99从200ms飙升至800ms，而container_cpu_usage_seconds_total和container_memory_usage_bytes平稳如初。

排查路径：

1. 先排除网络层：kubectl exec -it <pod> -- curl -w "@curl-format.txt" -o /dev/null -s http://localhost:8000/health，检查time_connect和time_starttransfer是否异常——结果正常，排除网络抖动。
2. 检查GPU状态：kubectl exec -it <pod> -- nvidia-smi，发现utilization.gpu为0%，但memory.used高达95%。
3. 进一步诊断：kubectl exec -it <pod> -- nvidia-smi -q -d MEMORY，输出显示FB Memory Usage中Used为39GB/40GB，Free仅1GB。

根因：GPU显存碎片化。模型加载时分配了大量小块显存，长时间运行后无法合并，新推理请求因找不到连续大块显存而被迫等待。

解决：

• 紧急：重启Pod释放显存（kubectl delete pod <name>）。
• 长期：在模型代码中启用torch.cuda.empty_cache()定期清理，或改用torch.compile()优化显存布局。我们最终在predict()函数末尾加入：

  if torch.cuda.is_available() and time.time() - last_cache_clean > 300: # 每5分钟清理一次 torch.cuda.empty_cache() last_cache_clean = time.time()

4.2 问题二：新版本模型上线后，错误率上升但日志无ERROR

现象：Istio金丝雀流量切到v2后，istio_requests_total{response_code=~"5.."}激增，但Pod日志里没有ERROR级别记录。

排查路径：

1. 检查应用日志级别：kubectl logs <pod> | grep -i "error\|exception"，确实为空。
2. 查看Istio代理日志：kubectl logs <pod> -c istio-proxy | grep "500"，发现大量upstream_reset_before_response_started{remote_reset}。
3. 追踪具体请求：kubectl exec -it <pod> -c istio-proxy -- curl -s "http://localhost:15000/logging?level=trace"开启Envoy调试日志，再复现请求，发现日志中有upstream connect error or disconnect/reset before headers. reset reason: connection termination。

根因：v2版本模型在初始化时未正确处理CUDA上下文，导致首次推理时Envoy代理连接超时（默认15秒），Envoy主动断开连接，返回503。

解决：

• 在模型__init__方法中，强制执行一次空推理：

  def __init__(self): self.model = load_model() # 预热：触发CUDA上下文初始化 if torch.cuda.is_available(): _ = self.model(torch.zeros(1, 3, 224, 224).cuda())

• 同时在Deployment中增加readinessProbe.initialDelaySeconds: 60，确保预热完成后再接入流量。

4.3 问题三：HPA持续扩容，但新Pod始终处于Pending状态

现象：kubectl get hpa显示text-classifier-hpa的TARGETS为85%/50%，REPLICAS从3升到12，但kubectl get pods里大量Pod状态为Pending。

排查路径：

1. kubectl describe pod <pending-pod>，关键信息在Events：0/10 nodes are available: 5 Insufficient nvidia.com/gpu, 5 node(s) didn't match node selector.
2. 检查节点GPU资源：kubectl describe nodes | grep -A 10 "nvidia.com/gpu"，发现只有5个节点报告nvidia.com/gpu: 1，其余节点为0。
3. 进一步确认：kubectl get nodes -o wide，发现新购的5台A100节点未安装NVIDIA驱动。

根因：K8s节点未正确注册GPU资源，Device Plugin无法工作。

解决：

• 在A100节点上执行：

  # 安装驱动（需匹配CUDA版本） sudo apt-get install -y nvidia-driver-515 sudo reboot # 安装Device Plugin kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.5/nvidia-device-plugin.yml

• 验证：kubectl get nodes -o wide应显示nvidia.com/gpu: 1，kubectl describe nodes的Allocatable字段包含GPU。

4.4 问题四：模型预测结果随机波动，相同输入多次请求返回不同结果

现象：测试脚本对同一张图片发起10次请求，返回的类别概率数组每次都有微小差异（如[0.421, 0.579]vs[0.419, 0.581]）。

排查路径：

1. 排除数据预处理：检查preprocess()函数，确认未使用random.random()等非确定性操作。
2. 检查模型状态：kubectl exec -it <pod> -- python -c "import torch; print(torch.backends.cudnn.enabled)"，输出True。
3. 关键线索：torch.backends.cudnn.benchmark = True（默认开启）会为不同输入尺寸选择最优卷积算法，但算法选择具随机性。

根因：cuDNN的benchmark模式在首次运行时会探索多种算法，选择最快的，但探索过程涉及随机种子，导致结果微小差异。

解决：

• 在模型加载后强制关闭benchmark并固定随机种子：

  torch.backends.cudnn.benchmark = False torch.backends.cudnn.deterministic = True torch.manual_seed(42) if torch.cuda.is_available(): torch.cuda.manual_seed_all(42)

• 同时，确保所有预处理步骤（如Resize）使用确定性插值（interpolation=Image.BILINEAR而非Image.NEAREST）。

4.5 问题五：Prometheus无法采集模型指标，/metrics端点返回404

现象：kubectl port-forward service/prometheus 9090，访问http://localhost:9090/targets，发现模型服务Target状态为DOWN，Last Scrape Error为server returned HTTP status 404 Not Found。

排查路径：

1. 直接访问Pod的metrics端点：kubectl exec -it <pod> -- curl http://localhost:8000/metrics，返回404。
2. 检查FastAPI应用：确认未挂载PrometheusMiddleware。
3. 查看应用代码：发现app = FastAPI()后，缺少app.add_middleware(PrometheusMiddleware)。

根因：应用未集成Prometheus中间件，/metrics端点未注册。

解决：

• 安装starlette-prometheus：pip install starlette-prometheus
• 在FastAPI初始化中添加：

  from starlette_prometheus import PrometheusMiddleware, metrics app = FastAPI() app.add_middleware(PrometheusMiddleware) app.add_route("/metrics", metrics) # 暴露/metrics端点

• 同时，在Dockerfile中确保EXPOSE 8000，并在Service中配置targetPort: 8000。

5. 经验沉淀：踩过坑后总结的7条铁律与3个未来演进方向

5.1 铁律一：永远不要在生产环境用latest镜像Tag

这是血泪教训。去年一次紧急修复，运维同事docker pull my-model:latest，结果拉取到上周CI失败时误推的镜像，该镜像缺失GPU支持代码，导致所有质检服务500。从此我们立下规矩：所有生产环境Deployment必须使用Git Commit ID作为Tag（如my-model:abc1234），并通过CI流程强制校验git rev-parse HEAD与镜像Tag一致。latest只允许在开发分支使用，且CI会自动拒绝向生产仓库推送latest。

5.2 铁律二：模型服务的readinessProbe必须检查业务就绪，而非仅端口存活

见过太多团队把readinessProbe设为httpGet: path: /health，而/health只返回{"status":"ok"}。这导致Pod虽已启动，但模型还在加载大文件（如1GB的词向量），此时流量进来必然超时。我们的/health/ready端点会执行：

• 检查模型权重文件是否完整（os.path.getsize('model.bin') == expected_size）
• 执行一次真实推理（model.predict("test")）并验证输出格式
• 确认特征缓存已预热（redis_client.exists("feature_cache_v1")）
  只有全部通过，才返回200，否则503。这多出的2秒检查，换来的是100%的流量成功率。

5.3 铁律三：GPU节点必须配置nvidia-driversDaemonSet，而非手动安装

手动安装驱动的问题在于：节点重启后驱动丢失，K8s无法调度GPU Pod。我们用DaemonSet统一管理：

apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-drivers spec: selector: matchLabels: name: nvidia-drivers template: metadata: labels: name: nvidia-drivers spec: initContainers: - name: driver-installer image: nvidia/driver:515.65.01-ubuntu20.04 securityContext: privileged: true volumeMounts: - name: dev mountPath: /dev - name: root mountPath: /root containers: - name: pause image: k8s.gcr.io/pause volumes: - name: dev hostPath: path: /dev - name: root hostPath: path: /

该DaemonSet在节点启动时自动安装驱动，确保GPU资源永久在线。

5.4 铁律四：所有环境变量必须通过K8s Secret注入，禁止明文写入YAML

曾经有同事在deployment.yaml里写env: - name: DB_PASSWORD value: "mysecretpass"，该文件被误提交到Git，导致数据库密码泄露。现在所有敏感信息（API Keys、DB Passwords、Model Licenses）都存入K8s Secret：

kubectl create secret generic model-secrets \ --from-literal=db_password=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1) \ --from-file=model_license=license.key

Deployment中引用：

envFrom: - secretRef: name: model-secrets

5.5 铁律五：模型版本回滚必须是原子操作，且附带配置快照

回滚不是简单改YAML里的image: v1.2.0。Part 4要求每次发布都生成配置快照：

• 使用kubectl get deploy,text-classifier -o yaml > deploy-v1.2.0.yaml保存完整状态
• 将该YAML存入Git仓库的/releases/目录
• 回滚时执行kubectl replace -f releases/deploy-v1.2.0.yaml
  这样确保回滚后，HPA、Service、Ingress等所有关联资源都恢复到发布时的精确状态，避免“只回滚了镜像，忘了HPA阈值已调高”的悲剧。

5.6 铁律六：日志必须结构化，且包含请求唯一ID

原始日志INFO: 10.244.1.5:54321 - "POST /predict HTTP/1.1" 200 OK无法关联请求。我们强制所有日志JSON化：

import logging import json from uuid import uuid4 class StructuredLogger: def __init__(self, name): self.logger = logging.getLogger(name) def info(self, message, **kwargs): log_entry = { "timestamp": datetime.utcnow().isoformat(), "level": "INFO", "message": message, "request_id": kwargs.get("request_id", str(uuid4())), "model_version": "v1.2.0", **kwargs } self.logger.info(json.dumps(log_entry)) # 在FastAPI中间件中注入request_id @app.middleware("http") async def add_request_id(request: Request, call_next): request_id = request.headers.get("X-Request-ID", str(uuid4())) response = await call_next(request) # 将request_id注入响应头，便于前端追踪 response.headers["X-Request-ID"] = request_id return