2、容器基础：Docker与Kubernetes核心概念、容器生命周期、资源限制

2.1 从镜像到容器：Docker 的核心抽象

在排查容器化 AI 应用性能瓶颈之前，必须先厘清 Docker 与 Kubernetes 在系统中所扮演的角色。Docker 提供了“构建一次，随处运行”的打包能力，其核心抽象是镜像（Image）与容器（Container）。镜像是只读的静态模板，包含应用代码、运行时、系统库和依赖配置；容器则是镜像的运行实例，拥有独立的文件系统、网络栈和进程空间。

理解镜像分层机制对性能排查至关重要。Docker 镜像由多个只读层叠加而成，每一层对应 Dockerfile 中的一条指令。当容器启动时，Docker 在镜像层之上添加一个可写层（容器层）。AI 应用中常见的性能陷阱是：在容器运行期间写入大量日志或临时文件，导致可写层膨胀，进而拖慢 I/O 性能。排查时应使用 docker stats 观察块 I/O 指标，并考虑将高频写入路径挂载为数据卷（Volume）。

关键命令速查：

# 查看容器实时资源占用
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.BlockIO}}"

# 查看镜像分层信息
docker history <image_name>

# 检查容器可写层大小
docker system df -v

2.2 容器生命周期与状态迁移

容器的生命周期管理是性能排查的基础。一个容器从创建到销毁会经历多个状态：Created（已创建未启动）、Running（运行中）、Paused（暂停，进程挂起）、Exited（已停止）和 Dead（异常终止）。在 Kubernetes 中，Pod 内的容器还额外受 Waiting、Terminating 等状态约束。

性能瓶颈往往与状态迁移的异常有关。例如，容器频繁重启（CrashLoopBackOff）可能源于资源限制过紧导致 OOM Kill；容器长时间处于 Terminating 状态则可能因为进程未响应 SIGTERM 信号，强制等待宽限期超时。排查时需结合 docker inspect 中的 State 字段与 RestartCount，判断是资源问题还是代码问题。

2.3 资源限制：cgroup 与 Kubernetes 的 Request/Limit

容器资源限制的底层机制是 Linux cgroup（Control Groups）。Docker 通过 --cpus、--memory 等参数为容器设置 cgroup 配额。在 Kubernetes 中，这些参数被抽象为 resources.requests 和 resources.limits。理解两者的区别是性能排查的分水岭：

Requests：调度器依据它决定 Pod 落在哪个节点，相当于“预留量”。
Limits：运行时强制约束，超过后触发 CPU 节流（Throttling）或 OOM Kill。

AI 推理服务常见的误区是只设置 limits 而不设置 requests，导致调度器将多个高负载 Pod 堆叠在同一节点，引发 CPU 竞争。排查时应使用 kubectl describe node 查看节点资源分配情况，并关注 container_cpu_cfs_throttled_seconds_total 指标。

资源类型	Docker 参数	K8s 字段	超限后果	排查命令
CPU	--cpus=2.5	limits.cpu: "2.5"	CFS 节流，延迟升高	docker stats / kubectl top
内存	--memory=4g	limits.memory: 4Gi	OOM Kill，容器重启	dmesg \| grep -i oom
磁盘 I/O	--device-read-bps	无原生支持（需 CSI）	I/O 延迟，吞吐下降	iostat / docker stats

常见误区：不要将 limits.memory 设置得过高而忽略节点可用内存。Kubernetes 的 OOM Killer 基于 cgroup 内存上限触发，但节点物理内存耗尽时，内核会优先杀死占用内存最大的进程——即使该容器未达到自身 limit。排查时务必同时检查节点级 kubelet 日志与 /sys/fs/cgroup/memory 下的统计。

2.4 实战案例：GPU 推理容器的资源争抢

某 AI 团队部署了 3 个 TensorFlow Serving 容器，每个容器设置 limits.cpu: "4"、limits.memory: 8Gi，但未设置 requests。运行一周后，模型推理 P99 延迟从 45ms 飙升至 320ms。初步排查发现容器并未重启，CPU 使用率也未超过 80%。

进一步使用 kubectl top pod 和 docker stats 对比发现：三个容器实际 CPU 使用量分别为 3.8、3.9、3.7 核，而节点总 CPU 为 8 核。由于未设置 requests，调度器将三个 Pod 全部调度到同一节点，导致 CPU 竞争。虽然每个容器未超过 4 核 limit，但三者叠加超过节点容量，触发 CFS 节流。

解决方案：为每个容器设置 requests.cpu: "2"，并调整部署策略，将 Pod 分散到不同节点。同时增加 container_cpu_cfs_throttled_seconds_total 监控告警，当节流时间超过运行时间的 5% 时触发预警。

修正后的资源配置片段：

resources:
  requests:
    cpu: "2"
    memory: 4Gi
  limits:
    cpu: "4"
    memory: 8Gi

2.5 复盘：资源排查的三层递进法

从上述案例可以提炼出容器资源排查的通用路径。第一层是现象层：确认是延迟升高、连接超时还是容器重启；第二层是指标层：通过 docker stats、kubectl top、Prometheus 等获取 CPU、内存、网络、磁盘的量化数据；第三层是内核层：当指标层无法解释问题时，深入 cgroup 文件系统、内核日志和 eBPF 追踪。

一个容易被忽略的细节是：docker stats 显示的 CPU 百分比是相对于宿主机的，而 Kubernetes 的 kubectl top 显示的是相对于 Pod 请求值的。两者口径不同，直接对比会产生误导。建议统一使用 Prometheus 的 container_cpu_usage_seconds_total 指标，并除以 container_spec_cpu_quota 计算真实使用率。

最后，务必为每个容器设置合理的 requests 与 limits，并保持监控告警。资源限制不是性能瓶颈的根源，而是定位瓶颈的标尺——没有标尺的排查，如同在黑暗中摸索。