📚 课程目录第4章容器化与虚拟化

容器化与虚拟化：Docker、Kubernetes在AI集群中的应用，资源隔离与共享

核心原理：从“物理切分”到“逻辑调度”的范式转变

AI算力集群面临的核心矛盾是：GPU、高速网络、大内存等稀缺资源既需要被多个训练任务共享，又必须防止任务间相互干扰。传统虚拟机通过Hypervisor虚拟化硬件，每个VM包含完整操作系统，隔离性强但开销大——启动分钟级、镜像GB级、GPU直通配置复杂。容器则共享宿主机内核，通过Linux Namespace（命名空间）实现进程、网络、文件系统的视图隔离，通过Cgroups（控制组）限制CPU、内存、GPU显存等资源用量。

在AI场景中，容器化带来的关键价值在于环境一致性：训练依赖的CUDA版本、Python库、系统库被封装进镜像，彻底消除“在我机器上能跑”的困境。而Kubernetes（K8s）作为容器编排平台，将资源调度抽象为声明式API：用户描述“需要什么”，而非“如何执行”。调度器根据节点资源余量、亲和性约束、拓扑感知等策略，决定Pod（容器组）落在哪个物理节点上。

资源隔离与共享的本质：隔离是手段，共享是目的。容器提供的是“软隔离”——进程级边界，而GPU的隔离需要借助NVIDIA Device Plugin将物理GPU切分为MIG（多实例GPU）或按显存配额分配。共享则依赖K8s的调度器将多个Pod复用同一块GPU（时间片或MIG切片），从而将GPU利用率从30%提升至70%以上。

方法流程：AI任务容器化与调度的完整链路

将AI训练任务部署到K8s集群，需要经过镜像构建、资源声明、调度绑定、运行时隔离四个阶段。以下是一个典型的PyTorch分布式训练任务从代码到运行的全流程。

1. 镜像构建：锁定CUDA与Python环境

# Dockerfile
FROM nvcr.io/nvidia/pytorch:23.08-py3
WORKDIR /workspace
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY train.py .
COPY model/ ./model/
# 设置非root用户提升安全性
RUN useradd -m -u 1000 trainer
USER trainer
ENTRYPOINT ["python", "train.py"]

2. 资源声明：通过YAML描述GPU需求

apiVersion: v1
kind: Pod
metadata:
  name: bert-trainer
spec:
  containers:
  - name: trainer
    image: registry.example.com/bert-trainer:v1.2
    resources:
      requests:
        nvidia.com/gpu: 2    # 请求2张GPU
        memory: "32Gi"
        cpu: "16"
      limits:
        nvidia.com/gpu: 2    # 上限与请求一致，保证确定性
        memory: "32Gi"
  nodeSelector:
    gpu-type: a100          # 指定节点类型
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "ai-training"
    effect: "NoSchedule"

3. 调度决策：K8s调度器的核心逻辑

调度器（kube-scheduler）采用过滤→打分两阶段机制。过滤阶段排除资源不足、端口冲突、不满足亲和性的节点；打分阶段根据资源均衡度、镜像本地化、拓扑分布等策略排序。对于AI任务，还需考虑GPU拓扑感知——当请求多卡训练时，优先选择NVLink互联的GPU对，避免跨PCIe通信。

4. 运行时隔离：Cgroups与Device Plugin协作

Kubelet调用运行时（containerd）启动容器时，会为每个容器创建独立的Cgroup目录，写入CPU份额、内存限制等参数。NVIDIA Device Plugin作为DaemonSet运行在每个节点上，向API Server上报GPU资源，并在容器启动时将GPU设备（/dev/nvidia0等）和驱动库注入容器。对于MIG模式，Device Plugin会将物理GPU切分为多个实例（如A100可切为7个1g.5gb），每个实例拥有独立的显存和计算单元。

隔离维度	传统虚拟机	Docker容器	K8s + GPU MIG
启动时间	分钟级	秒级	秒级
镜像大小	GB~数十GB	MB~GB	MB~GB
GPU隔离粒度	整卡直通	整卡或显存配额	MIG切片（1/7卡）
性能损耗	5%~15%	<3%	<5%
多租户安全	强（内核隔离）	中（共享内核）	中+（需额外加固）

案例场景：混合负载下的GPU资源池化

某AI平台同时承载离线训练、在线推理和数据处理三类负载。通过K8s的Namespace + ResourceQuota实现部门级配额管理，再通过PriorityClass区分任务优先级：在线推理服务优先级最高，保证P99延迟；离线训练任务在资源空闲时弹性扩展。

关键实践：将GPU资源池划分为“整卡池”和“MIG池”。大模型训练（需要多卡通信）使用整卡池，并通过nodeAffinity绑定到同一台8卡服务器；小模型推理和数据处理使用MIG池，将一张A100切分为多个实例，供不同团队共享。通过kubectl top nodes监控GPU利用率，当整卡池利用率低于40%时，自动将空闲节点标记为可调度MIG任务。

# 查看GPU分配状态
$ kubectl get nodes -l gpu-type=a100 -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu
NAME          GPU
node-01       8
node-02       8

# 查看MIG设备
$ nvidia-smi -L
GPU 0: A100-SXM4-40GB (UUID: GPU-xxx) MIG 1g.5gb Device 0
GPU 0: A100-SXM4-40GB (UUID: GPU-xxx) MIG 1g.5gb Device 1

误区与复盘：容器化AI集群的常见陷阱

误区一：盲目追求“零共享”。有些团队为绝对隔离，将每个任务独占整卡，导致GPU利用率长期低于30%。复盘发现，通过MIG或时间片共享，在可接受的性能损耗（通常<10%）下，吞吐量可提升2~3倍。

误区二：忽略NUMA拓扑与CPU绑核。容器默认不感知CPU拓扑，当GPU通信频繁时，跨NUMA访问会显著增加延迟。正确做法是使用cpuManagerPolicy: static和topologyManagerPolicy: single-numa-node，确保GPU和CPU在同一NUMA节点。

误区三：镜像管理失控。每个训练实验都构建新镜像，导致仓库膨胀、拉取缓慢。复盘建议：将基础镜像（CUDA+框架）与业务代码分离，代码通过PVC挂载或Git拉取，镜像版本从“每次实验”收敛为“每周稳定版”。

高风险警示：容器共享宿主机内核，一旦内核漏洞被利用，可能影响同节点所有容器。在AI集群中，若多租户共享节点，务必启用seccomp、AppArmor等安全模块，并禁止特权容器。对于涉及敏感数据的训练任务，建议使用安全容器（如Kata Containers）或独立节点池。

复盘总结：容器化与虚拟化在AI集群中的核心价值不是“二选一”，而是分层组合——用虚拟机（或安全容器）隔离不可信租户，用Docker封装环境依赖，用K8s统一调度GPU、CPU、内存等资源。通过MIG、拓扑感知调度、优先级抢占等机制，在隔离与共享之间找到动态平衡点。最终目标是：让每一块GPU都尽可能满负荷运转，同时让每个任务都获得“独占感”的稳定性能。