机器学习工程师必须掌握的Docker与Kubernetes实战指南

1. 为什么机器学习工程师现在必须亲手写 Dockerfile 和 YAML，而不是只靠“跑通就行”

我带过三届校招的 MLOps 实习生，也给五家不同行业的 AI 团队做过模型交付咨询。最常听到的一句话是：“模型在本地 Jupyter 里跑通了，但一上服务器就报错——不是缺库，就是路径不对，要不就是 CUDA 版本打架。” 这种情况，90% 不是算法问题，而是环境管理失控。而 Docker 和 Kubernetes，不是锦上添花的“高级配置”，而是把 ML 项目从“能跑”变成“可交付、可复现、可运维”的基础设施底线。

关键词： Docker、Kubernetes、机器学习、容器化、MLOps、模型部署、环境一致性、GPU 容器、CI/CD 集成 ——这些词背后不是抽象概念，而是你明天就要面对的具体问题：比如你训练好的 PyTorch 模型，在同事的 Mac 上 infer 结果对，在 Ubuntu 20.04 的 GPU 服务器上却输出 NaN；又比如你用 conda 装了 cudatoolkit=11.3 ，但服务器上系统级 CUDA 是 11.7，nvidia-smi 显示正常，torch.cuda.is_available() 却返回 False。这些问题，靠“再 pip install 一遍”或“让运维帮忙装个包”根本解决不了，因为它们根植于“环境不可控”这个顽疾。

容器化解决的，正是这个底层信任问题。它不承诺“让你的代码更酷”，而是保证“只要镜像没坏，它在哪跑都一模一样”。这不是理想主义，是工程现实：一个线上推理服务宕机 5 分钟，可能意味着数千次用户请求失败、A/B 测试数据污染、甚至 SLA 违约罚款。而一次成功的容器化迁移，往往能把模型从开发到上线的平均周期从 2 周压缩到 2 天——不是靠加班，而是靠消除环境摩擦。我亲眼见过一家金融风控团队，把原来需要 3 个工程师协同调试 3 天的模型上线流程，变成一个 kubectl apply -f deploy.yaml 命令加一次自动 CI 测试就完成。他们没多写一行模型代码，但交付稳定性提升了 400%。所以，这不是“要不要学”的选择题，而是“什么时候开始动手”的时间点问题。下面，我们就从真实场景出发，拆解每一步该怎么做、为什么这么选、以及踩过哪些坑。

2. Docker：不只是打包，是构建可验证、可审计、可复现的 ML 环境基线

2.1 为什么不能直接用 python:3.9-slim ？Base Image 的选择逻辑

很多初学者看到教程里写 FROM python:3.9 就照抄，结果在 GPU 服务器上 build 失败，或者运行时提示 libcuda.so.1: cannot open shared object file 。这暴露了一个关键误区：Docker 镜像的 base image 不是“越新越好”，而是“与目标运行时环境严格对齐”。

以机器学习场景为例，base image 的选择必须同时满足三个硬约束：

• CUDA 兼容性 ：你的模型训练/推理是否依赖 GPU？如果依赖，base image 必须预装与宿主机 NVIDIA 驱动兼容的 CUDA Toolkit 和 cuDNN。NVIDIA 官方维护的 nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu20.04 是目前最稳妥的选择，它明确标注了 CUDA 版本（11.8.0）、cuDNN 版本（8）、运行时模式（runtime，非 devel）和基础 OS（Ubuntu 20.04）。而 python:3.9-slim 是 Debian 基础，完全不含 CUDA，强行安装会因内核头文件缺失而失败。
• Python 生态成熟度 ： python:3.9-slim 确实体积小，但它删减了 gcc 、 g++ 、 make 等编译工具。当你 pip install 一个需要源码编译的包（如 faiss-cpu 或某些自定义 C++ 扩展），就会卡在 error: command 'gcc' failed 。此时 python:3.9 （非 slim）更合适，它保留了完整构建链。
• 安全与维护性 ： python:3.9 是官方镜像，每月有安全更新；而自己 FROM ubuntu:20.04 再手动 apt update && apt install python3.9 ，等于把所有安全补丁责任揽到自己身上。我们曾为一家医疗客户审计其模型镜像，发现他们自建的 base image 已有 17 个未修复的 CVE 高危漏洞，根源就是绕过了官方维护通道。

因此，我的推荐策略是分层决策：

• 纯 CPU 推理服务 → python:3.9-slim-bullseye （Debian 11，比 Ubuntu 更轻，且 slim-bullseye 包含必要编译工具）
• GPU 训练/推理 → nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu20.04
• 需要极致精简且确认无编译需求 → public.ecr.aws/docker/library/python:3.9-slim-bookworm （AWS ECR 提供的镜像，比 Docker Hub 官方版更新更快）

提示：永远用 docker pull 拉取镜像后，先 docker run -it <image> bash 进去验证 python --version 、 nvcc --version （GPU 镜像）、 which gcc 是否存在。这是防止后续 build 失败的最廉价检查。

22. Dockerfile 编写：不是语法练习，是环境状态的精确声明

一个典型的、用于生产环境的 ML 推理服务 Dockerfile，绝不是教程里那个 6 行的玩具。它必须回答五个核心问题： 依赖怎么装才快？环境变量怎么设才安全？代码怎么放才可审计？日志怎么输出才规范？启动怎么管才健壮？ 下面是一个经过 3 个项目实战打磨的模板，并逐行解释设计意图：

# 第一层：精准 Base Image —— 明确声明 CUDA 和 Python 版本
FROM nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu20.04

# 第二层：系统级依赖 —— 安装非 Python 依赖，如 ffmpeg（视频处理）、libsm6（OpenCV GUI）
RUN apt-get update && apt-get install -y \
    ffmpeg \
    libsm6 \
    libxext6 \
    && rm -rf /var/lib/apt/lists/*

# 第三层：创建非 root 用户 —— 安全强制项，避免容器以 root 权限运行
RUN groupadd -g 1001 -f appuser && useradd -s /bin/bash -u 1001 -m appuser
USER appuser

# 第四层：Python 依赖 —— 分离 requirements.txt 和代码，利用 Docker layer cache
WORKDIR /home/appuser/app
COPY --chown=appuser:appuser requirements.txt .
RUN pip install --no-cache-dir --upgrade pip && \
    pip install --no-cache-dir -r requirements.txt

# 第五层：应用代码 —— 只复制代码，不包含 .git、__pycache__ 等无关文件
COPY --chown=appuser:appuser . .

# 第六层：环境与启动 —— 设置 PYTHONPATH，指定非 root 启动命令
ENV PYTHONUNBUFFERED=1
ENV PYTHONPATH=/home/appuser/app
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "4", "app:app"]

关键设计点解析：

• --chown=appuser:appuser ：确保复制进容器的文件所有权属于非 root 用户，否则 USER appuser 后会因权限不足无法读取代码。
• pip install --no-cache-dir ：禁用 pip 缓存，避免镜像体积膨胀（缓存可达 200MB+），且使每次 build 更可预测。
• ENV PYTHONUNBUFFERED=1 ：强制 Python 输出不缓冲，确保日志实时写入 stdout，便于 docker logs 查看。
• CMD 使用数组格式而非字符串 ： ["gunicorn", ...] 是 exec 模式，PID 1 是 gunicorn 进程，能正确接收 SIGTERM 信号实现优雅退出；而 CMD "gunicorn ..." 是 shell 模式，PID 1 是 /bin/sh ，SIGTERM 会被忽略，导致容器 kill 时进程僵死。

注意：永远不要在 Dockerfile 中写 RUN pip install torch torchvision 。PyTorch 官网明确要求根据 CUDA 版本选择对应 wheel，应将 torch==1.13.1+cu117 这类带 CUDA 标识的版本写入 requirements.txt ，由 pip 自动解析安装。硬编码会导致 CUDA 版本错配。

2.3 构建与验证： docker build 不是终点，而是质量门禁的起点

docker build -t ml-inference:v1.0 . 这条命令执行完，只是生成了一个镜像，远未达到“可交付”标准。真正的验证必须包含三层：

第一层：镜像健康检查

# 检查镜像大小是否合理（GPU 镜像 >2GB 属正常，>5GB 需警惕）
docker images | grep ml-inference

# 检查镜像中是否存在敏感信息（如硬编码密码、API Key）
docker history ml-inference:v1.0

# 检查基础镜像是否有已知 CVE（需配合 Trivy 等扫描工具）
trivy image ml-inference:v1.0

第二层：容器功能验证

# 启动容器并进入交互模式，验证基础环境
docker run -it --rm --gpus all ml-inference:v1.0 bash

# 在容器内执行关键检查
python -c "import torch; print(torch.__version__, torch.cuda.is_available())"
curl http://localhost:8000/health  # 假设应用有健康检查端点

第三层：端到端业务验证

# 启动服务并发送真实请求
docker run -d --name ml-test --gpus all -p 8000:8000 ml-inference:v1.0
curl -X POST http://localhost:8000/predict -H "Content-Type: application/json" \
     -d '{"input": [1.0, 2.0, 3.0]}'
docker stop ml-test

这个验证流程，必须固化为 CI 流水线中的一个 stage。我坚持的原则是： 任何未通过这三层验证的镜像，都不允许打 tag 推送到私有 Registry 。曾经有个项目，因跳过第三层验证，上线后才发现模型输入预处理函数在容器内因 NumPy 版本差异导致数值精度漂移，AUC 下降 0.03，回滚耗时 4 小时。

3. Kubernetes：不是“把 Docker 放上去”，是为 ML 工作负载设计弹性调度与韧性保障

3.1 为什么 K8s 对 ML 不是“可选项”，而是“生存必需品”

很多人认为：“我的模型就一个 API，用 Docker Compose 起三个容器做负载均衡就够了，何必上 K8s？” 这种想法在 PoC 阶段成立，但在生产环境中极其危险。K8s 的价值，不在于它“能起更多容器”，而在于它解决了 ML 工作负载特有的四个刚性需求：

• GPU 资源的精细化调度 ：一台 8xA100 服务器，如何同时运行一个需要 4 张卡的训练任务和两个各需 1 张卡的推理服务？Docker Compose 无法感知 GPU，只能粗暴分配整机；而 K8s 的 nvidia.com/gpu: 1 resource request，配合 Device Plugin，能精确调度到单张卡粒度，并隔离显存与计算单元。
• 故障自愈的确定性 ：当一个推理 Pod 因 OOM 被 kill，Docker Compose 默认不会重启；而 K8s 的 Deployment Controller 会在秒级内拉起新 Pod，并通过 Liveness Probe 主动杀死无响应进程，确保 SLA。
• 流量洪峰的弹性伸缩 ：电商大促时，商品推荐 API QPS 从 1000 突增至 10000。K8s 的 Horizontal Pod Autoscaler（HPA）能基于 CPU 或自定义指标（如 requests_per_second ）自动扩缩 Pod 数量，无需人工干预。
• 多环境配置的统一管理 ：开发、测试、预发、生产环境，只有镜像 tag 和资源配置（CPU/Memory/GPU）不同。K8s 的 ConfigMap/Secret + Helm Chart，能让一套 YAML 文件适配所有环境，杜绝“改配置改到手抖”。

因此，K8s 对 ML 的意义，是把“人肉运维”升级为“声明式自治”。你声明“我要 3 个副本，每个用 2 核 CPU、4GB 内存、1 张 T4 卡”，K8s 就负责找到资源、调度、监控、恢复。你不再需要半夜被 PagerDuty 叫醒去 docker ps | grep down 。

3.2 核心对象深度解析：Pod、Deployment、Service 如何协同支撑 ML 生命周期

3.2.1 Pod：ML 工作负载的原子执行单元，不是“一个容器”，而是“一个协作组”

在 ML 场景中，一个 Pod 很少只包含一个容器。典型结构是 主容器（Model Server） + Sidecar 容器（日志收集/指标上报） 。例如：

apiVersion: v1
kind: Pod
metadata:
  name: ml-predictor
spec:
  containers:
  - name: predictor
    image: registry.example.com/ml-inference:v1.0
    resources:
      requests:
        memory: "2Gi"
        cpu: "1"
        nvidia.com/gpu: 1  # 关键！声明 GPU 需求
      limits:
        memory: "4Gi"
        cpu: "2"
        nvidia.com/gpu: 1
    env:
    - name: MODEL_PATH
      value: "/models/bert-base-uncased"
    ports:
    - containerPort: 8000
  - name: fluentd-sidecar  # Sidecar：统一收集日志
    image: fluent/fluentd-kubernetes-daemonset:v1.14-debian-cloudwatch-1
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

这里的关键洞察是： GPU 资源请求（ nvidia.com/gpu ）必须放在 resources.requests 中，且 requests 和 limits 必须相等 。因为 GPU 是不可超售（non-overcommitable）资源，K8s 调度器只认 requests 值来决定能否调度， limits 设为不同值无意义，反而可能引发调度异常。

3.2.2 Deployment：ML 服务的“状态控制器”，确保你声明的副本数永不偏离

Deployment 的核心价值，在于它把“起几个容器”这件事，从一次性操作变成了持续的状态守护。它的 YAML 不仅定义了 Pod 模板，更定义了 如何升级、如何回滚、如何扩容 ：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-predictor-deployment
spec:
  replicas: 3  # 声明期望的副本数
  selector:
    matchLabels:
      app: ml-predictor
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1      # 升级时最多额外起 1 个 Pod
      maxUnavailable: 0  # 升级时不允许有任何 Pod 不可用（零停机）
  template:
    metadata:
      labels:
        app: ml-predictor
    spec:
      containers:
      - name: predictor
        image: registry.example.com/ml-inference:v1.0
        # ... 其他配置同上 Pod

maxUnavailable: 0 是 ML 服务的关键配置。它意味着滚动更新时，旧 Pod 不会先被杀，而是等新 Pod Ready 后才终止旧 Pod。这对模型服务至关重要——任何瞬间的 503 错误，都可能导致用户请求丢失。我们曾在一个金融实时评分服务中启用此配置，将更新期间的错误率从 0.2% 降至 0。

3.2.3 Service：ML 服务的“稳定入口”，屏蔽后端 Pod 的动态性

Pod 的 IP 是临时的，每次重启都会变。Service 则提供一个固定的 ClusterIP（集群内访问）或 NodePort/LoadBalancer（外部访问），并通过 kube-proxy 实现负载均衡。对于 ML，我们强烈推荐使用 Headless Service + StatefulSet 模式来管理训练作业，但对推理服务，标准 Service 足够：

apiVersion: v1
kind: Service
metadata:
  name: ml-predictor-service
spec:
  selector:
    app: ml-predictor  # 匹配 Deployment 中的 Pod Label
  ports:
  - protocol: TCP
    port: 80            # Service 暴露的端口
    targetPort: 8000    # Pod 容器内实际监听的端口
  type: LoadBalancer     # 对外暴露，云厂商会自动分配公网 IP

提示：永远用 selector 匹配 labels ，而不是 podSelector 。后者是直接匹配 Pod，绕过了 Deployment 的控制，极易导致服务不稳定。

3.3 GPU 资源在 K8s 中的落地：Device Plugin 与 RuntimeClass 的协同

让 K8s 调度 GPU，不是简单加一行 nvidia.com/gpu: 1 就能生效。它依赖两个核心组件：

• NVIDIA Device Plugin ：一个 DaemonSet，运行在每个 GPU 节点上，向 K8s API Server 注册 nvidia.com/gpu 这个扩展资源，并监听 GPU 状态。它相当于 GPU 的“设备驱动翻译官”。
• RuntimeClass ：声明容器运行时。默认是 runc ，但 GPU 容器必须使用 nvidia runtime。需提前在节点上安装 nvidia-container-toolkit ，并在 /etc/containerd/config.toml 中配置：

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]
  runtime_type = "io.containerd.runc.v2"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]
    BinaryName = "nvidia-container-runtime"

然后在 Pod spec 中声明：

apiVersion: v1
kind: Pod
spec:
  runtimeClassName: nvidia  # 关键！指定使用 nvidia runtime
  containers:
  - name: predictor
    image: ...
    resources:
      requests:
        nvidia.com/gpu: 1

没有 runtimeClassName ，即使 nvidia.com/gpu 请求成功，容器也无法访问 /dev/nvidia* 设备文件， torch.cuda.is_available() 仍为 False。这是新手最常见的 GPU 调度失败原因。

4. 从零搭建一个可运行的 ML 推理服务：完整实操 walkthrough

4.1 前置准备：环境与工具链

你需要准备以下环境（以 Ubuntu 22.04 为例）：

• 宿主机 ：安装 Docker CE 24.0+、NVIDIA Driver 525+、nvidia-container-toolkit 1.12+
• K8s 集群 ：本地可用 minikube start --cpus=4 --memory=8192 --gpus=2 （需 minikube 1.30+），生产环境建议 kubeadm 或托管服务
• 工具 ： kubectl 、 helm （可选）、 trivy （安全扫描）

验证 GPU 支持：

# 宿主机上
nvidia-smi  # 应显示 GPU 信息

# 启动一个测试 Pod
kubectl run gpu-test --rm -t -i --restart=Never --image=nvcr.io/nvidia/cuda:11.8.0-base-ubuntu20.04 --limits=nvidia.com/gpu=1 -- bash -c "nvidia-smi"
# 应输出与宿主机一致的 nvidia-smi 结果

4.2 步骤一：编写 ML 应用代码与依赖

创建项目目录 ml-inference-app ：

mkdir ml-inference-app && cd ml-inference-app

app.py （一个极简的 FastAPI 推理服务）：

from fastapi import FastAPI
import torch
import torch.nn as nn

app = FastAPI()

class SimpleModel(nn.Module):
    def __init__(self):
        super().__init__()
        self.linear = nn.Linear(3, 1)
    def forward(self, x):
        return self.linear(x)

model = SimpleModel()
model.eval()

@app.get("/health")
def health():
    return {"status": "ok", "cuda": torch.cuda.is_available()}

@app.post("/predict")
def predict(input_data: list[float]):
    tensor = torch.tensor(input_data).float()
    with torch.no_grad():
        result = model(tensor).item()
    return {"prediction": result}

requirements.txt ：

fastapi==0.104.1
uvicorn==0.23.2
torch==1.13.1+cu117
torchvision==0.14.1+cu117
--find-links https://download.pytorch.org/whl/torch_stable.html
--no-deps

注意： --find-links 和 --no-deps 确保 pip 从 PyTorch 官方源安装带 CUDA 的 wheel，避免安装 CPU 版本。

4.3 步骤二：构建并推送 Docker 镜像

Dockerfile （采用前文推荐的 GPU 安全模板）：

FROM nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu20.04

RUN apt-get update && apt-get install -y \
    && rm -rf /var/lib/apt/lists/*

RUN groupadd -g 1001 -f appuser && useradd -s /bin/bash -u 1001 -m appuser
USER appuser

WORKDIR /home/appuser/app
COPY --chown=appuser:appuser requirements.txt .
RUN pip install --no-cache-dir --upgrade pip && \
    pip install --no-cache-dir -r requirements.txt

COPY --chown=appuser:appuser . .

ENV PYTHONUNBUFFERED=1
ENV PYTHONPATH=/home/appuser/app
CMD ["uvicorn", "app:app", "--host", "0.0.0.0:8000", "--port", "8000", "--workers", "2"]

构建并推送（假设私有 Registry 为 registry.example.com ）：

docker build -t registry.example.com/ml-inference:v1.0 .
docker push registry.example.com/ml-inference:v1.0

4.4 步骤三：编写 Kubernetes 部署 YAML

k8s/deployment.yaml ：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-predictor
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ml-predictor
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: ml-predictor
    spec:
      runtimeClassName: nvidia
      containers:
      - name: predictor
        image: registry.example.com/ml-inference:v1.0
        resources:
          requests:
            memory: "2Gi"
            cpu: "1"
            nvidia.com/gpu: 1
          limits:
            memory: "4Gi"
            cpu: "2"
            nvidia.com/gpu: 1
        env:
        - name: MODEL_PATH
          value: "/models/simple"
        ports:
        - containerPort: 8000
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: ml-predictor-service
spec:
  selector:
    app: ml-predictor
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8000
  type: LoadBalancer

4.5 步骤四：部署与验证

# 部署
kubectl apply -f k8s/deployment.yaml

# 查看 Pod 状态（等待 STATUS 为 Running）
kubectl get pods -l app=ml-predictor

# 查看 Service 外部 IP（minikube 需用 minikube service）
minikube service ml-predictor-service

# 或获取 ClusterIP 并 curl
export SVC_IP=$(kubectl get service ml-predictor-service -o jsonpath='{.spec.clusterIP}')
curl http://$SVC_IP/health

# 发送预测请求
curl -X POST http://$SVC_IP/predict -H "Content-Type: application/json" \
     -d '[1.0, 2.0, 3.0]'

预期输出：

{"prediction": 0.123456}

4.6 步骤五：压力测试与弹性验证

使用 hey 工具模拟高并发：

# 安装 hey
go install github.com/rakyll/hey@latest

# 发起 100 并发，持续 30 秒
hey -z 30s -c 100 http://$SVC_IP/predict

# 观察 HPA（需先部署 HPA，此处略）
kubectl get hpa
kubectl get pods  # 应看到 Pod 数量随负载增加

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

5.1 GPU 相关问题速查表

5.2 网络与服务发现故障

• 问题 ： curl http://ml-predictor-service:80/health 在集群内 Pod 中失败，但 curl http://<pod-ip>:8000/health 成功
  原因 ：Service 的 selector 与 Pod 的 labels 不匹配。
  排查 ： kubectl get svc ml-predictor-service -o wide 查看 ENDPOINTS 字段，若为空，说明无 Pod 被选中。
  解决 ： kubectl get pods --show-labels 对比 app label，确保完全一致（包括大小写）。

• 问题 ：Service 类型为 LoadBalancer ，但 EXTERNAL-IP 一直 <pending>
  原因 ：本地 minikube 未启用 ingress 插件，或云环境未配置 LoadBalancer Controller。
  解决 ： minikube addons enable ingress ；或改用 NodePort 类型，通过 minikube ip :30000 访问。

5.3 镜像与构建陷阱

• “镜像拉取失败：unauthorized” ：私有 Registry 未配置 ImagePullSecret。
  解决 ：创建 Secret 并在 Deployment 中引用：

  kubectl create secret docker-registry regcred \
      --docker-server=registry.example.com \
      --docker-username=your-user \
      --docker-password=your-pass
  

  在 Deployment 的 spec.template.spec 中添加：

  imagePullSecrets:
  - name: regcred
  

• “容器启动后立即退出， kubectl logs 无输出” ：CMD 命令执行完即退出（如 CMD ["python", "app.py"] 是脚本，执行完就结束）。
  解决 ：确保 CMD 启动的是长期运行的进程（如 uvicorn , gunicorn , python -m http.server ），或添加 tail -f /dev/null 作为兜底。

5.4 我踩过的最深的三个坑

1. CUDA 版本“幻觉” ：在 nvidia/cuda:11.8.0-runtime 镜像中 nvcc --version 显示 11.8，但 torch.version.cuda 显示 11.7。这是因为 PyTorch wheel 是预编译的，其 CUDA 版本由构建时的环境决定，与镜像中 nvcc 版本无关。 解决方案 ：永远以 torch.version.cuda 为准，选择 PyTorch 官网提供的、明确标注 CUDA 版本的 wheel。

2. ConfigMap 热更新不生效 ：修改 ConfigMap 后，Pod 中挂载的文件未更新。
   真相 ：ConfigMap 挂载为文件时，K8s 不会主动更新文件内容，只会更新 /var/run/secrets/kubernetes.io/serviceaccount/ 下的 token。 解决方案 ：使用 subPath 挂载单个文件，或在应用层监听文件变化（如 watchdog 库），或更推荐——用 envFrom 将 ConfigMap 作为环境变量注入，环境变量在 Pod 启动时即固定。

3. HPA 基于 CPU 扩容，但 GPU 利用率已 100% ：HPA 看不到 GPU 指标，只看到 CPU 5%，于是不扩容，导致推理延迟飙升。
   破局点 ：必须部署 prometheus-operator + kube-state-metrics + nvidia-dcgm-exporter ，将 DCGM_FI_DEV_GPU_UTIL 指标暴露给 Prometheus，再通过 custom-metrics-apiserver 注册为 K8s 自定义指标，最后在 HPA 中使用 metrics 字段指向它。这是一个完整的可观测性栈，但值得投入。

6. 最后一点个人体会：容器化不是终点，而是 MLOps 的起点

写完这篇近 6000 字的实操指南，我想说的其实很简单：Docker 和 Kubernetes 本身并不创造业务价值，它们只是把 ML 工程师从“环境泥潭”里解放出来的杠杆。真正创造价值的，是你用这个杠杆撬动了什么——是把模型上线周期从两周缩短到两小时？是让 A/B 测试的模型切换从手动改配置变成一个 Git commit？还是让数据科学家能自己提交一个 deploy.yaml 就完成模型发布，而不用等运维排期？

我在去年主导的一个智能客服项目中，推动团队将所有模型服务容器化，并接入 GitOps 流水线（Argo CD）。结果是：数据科学家提交 PR 后，CI 自动构建镜像、扫描漏洞、运行单元测试；CD 自动将新镜像部署到预发环境，触发集成测试；测试通过后，一键同步到生产。整个过程无人工干预，平均交付时间 18 分钟。更重要的是，当某次上线后发现召回率下降，我们能在 3 分钟内通过 Argo CD 的 UI 点击“回滚到上一个版本”，服务瞬间恢复。这种确定性，是任何“跑通就行”的脚本都无法提供的。

所以，别把 Dockerfile 当成一个待填空的语法题，把它看作你对环境的庄严承诺；也别把 kubectl apply 当成一个魔法命令，把它看作你向系统发出的、关于服务状态的清晰声明。容器化和编排，最终极的意义，是让机器学习从一门“艺术”，真正成为一门可重复、可验证、可规模化的工程学科。而你，就是那个执笔写下第一行 FROM 的工程师。