2、基础概念：容器化技术（Docker、Kubernetes）与AI训练工作负载的特点

在搭建多云容器化AI训练环境之前，必须先厘清两个层面的基础概念：一是容器化技术本身（Docker与Kubernetes）在AI场景下扮演的角色；二是AI训练工作负载与传统Web服务在资源特征上的本质差异。很多团队在迁移到容器化AI训练时遇到的挫折，往往不是工具使用问题，而是对这两者匹配关系的理解偏差。

2.1 容器化技术：从Docker到Kubernetes的职责分层

Docker解决的是“单个训练任务如何打包与隔离”的问题。它将Python环境、CUDA驱动、cuDNN库、训练脚本、依赖包等一并封装为镜像，使得同一个训练任务可以在开发机、GPU服务器、云主机上以完全一致的方式运行。对于AI训练而言，Docker的核心价值在于环境一致性——它消除了“在我机器上能跑，在服务器上跑不起来”的经典困境。

但Docker本身只管理单机上的容器生命周期。当训练任务需要多机多卡并行、需要自动调度到空闲GPU、需要应对节点故障时，就需要Kubernetes（K8s）承担“集群资源编排与调度”的职责。Kubernetes将多台物理机或虚拟机抽象为一个资源池，通过声明式API描述“我想要什么”，由控制平面负责“如何达成”。

核心理解：Docker是“打包工具”，Kubernetes是“调度系统”。在AI训练场景中，Docker保证训练环境可复现，Kubernetes保证训练资源可编排。两者是互补关系，而非替代关系。

在Kubernetes中，与AI训练最相关的原生资源是Pod、Job和自定义资源定义（CRD）。Pod是调度最小单元，一个Pod可包含一个或多个容器（通常一个训练容器加一个监控Sidecar）。Job适合一次性训练任务，而像PyTorchJob、TFJob这类CRD则扩展了Kubernetes对分布式训练的原生支持，使其能够管理Parameter Server、Worker、Master等不同角色的Pod组。

2.2 AI训练工作负载的四大核心特征

理解AI训练负载的特征，是决定Kubernetes调度策略、存储方案、网络配置的前提。与常见的无状态Web服务相比，AI训练任务在以下四个维度有显著差异：

维度	传统Web服务	AI训练任务	对容器编排的影响
运行时长	秒级 ~ 分钟级请求处理	小时级 ~ 天级持续计算	需支持长运行Pod，不能因节点维护随意驱逐
资源类型	CPU + 内存为主	GPU显存 + 算力 + 高速网络	需GPU调度器、显存感知、拓扑感知
故障恢复	重启即可，无状态	需检查点（Checkpoint）恢复	需挂载持久卷保存模型权重和优化器状态
通信模式	短连接 / HTTP	All-Reduce / PS架构高频同步	需高性能网络（RoCE/IB），Pod间亲和性调度

2.3 分布式训练架构与Kubernetes的映射

当单卡显存不足或需要加速训练时，会采用分布式训练。两种主流架构在Kubernetes中的映射方式如下：

2.3.1 Parameter Server（参数服务器）架构

该架构将模型参数存储在一组PS节点上，Worker节点负责计算梯度并推送给PS，PS更新参数后再广播回Worker。在Kubernetes中，PS和Worker分别对应不同的Deployment或StatefulSet，通过Service进行网络互通。这种架构适合模型参数量极大、网络带宽相对有限的场景。

2.3.2 All-Reduce架构

该架构没有中心节点，每个Worker持有完整模型副本，通过NCCL等库进行梯度聚合。在Kubernetes中，通常使用PyTorchJob或TFJob的CRD来管理，每个Worker是一个Pod，且要求所有Pod调度在同一个网络域内（如同一节点组或同一RDMA网络）。这种架构对网络延迟极为敏感，因此Kubernetes的拓扑调度策略（如Pod间亲和性、GPU拓扑感知）至关重要。

实践建议：在多云环境中，尽量将同一个训练任务的所有Worker调度到同一个云可用区（Availability Zone）内，避免跨AZ的网络延迟导致All-Reduce效率急剧下降。如果必须跨AZ，则优先选择Parameter Server架构。

2.4 容器化AI训练的关键配置示例

以下是一个使用Kubernetes运行PyTorch分布式训练的典型YAML片段，展示了GPU资源声明、环境变量和卷挂载的核心要素：

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
  name: resnet50-train
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          containers:
          - name: pytorch
            image: registry.example.com/train:latest
            resources:
              limits:
                nvidia.com/gpu: 1
            volumeMounts:
            - name: data
              mountPath: /dataset
            - name: checkpoint
              mountPath: /checkpoints
          volumes:
          - name: data
            persistentVolumeClaim:
              claimName: imagenet-pvc
          - name: checkpoint
            persistentVolumeClaim:
              claimName: ckpt-pvc
    Worker:
      replicas: 4
      template:
        spec:
          containers:
          - name: pytorch
            image: registry.example.com/train:latest
            resources:
              limits:
                nvidia.com/gpu: 1
            volumeMounts:
            - name: data
              mountPath: /dataset
            - name: checkpoint
              mountPath: /checkpoints
          volumes:
          - name: data
            persistentVolumeClaim:
              claimName: imagenet-pvc
          - name: checkpoint
            persistentVolumeClaim:
              claimName: ckpt-pvc

2.5 常见误区与复盘

误区一：将GPU当作普通CPU资源进行调度。GPU显存是独占资源，不能像CPU那样进行时间片共享（除非使用MIG或vGPU技术）。如果多个Pod被调度到同一张GPU上，会导致显存溢出（OOM）或性能严重下降。正确做法是使用nvidia.com/gpu资源声明，并配置节点级GPU调度器。

误区二：忽略检查点（Checkpoint）的持久化。训练任务运行数天后，如果Pod因节点故障被重新调度，而检查点只保存在本地磁盘，则所有训练进度将丢失。必须将检查点写入持久卷（PVC）或对象存储，并配置定期保存策略。

误区三：在多云环境中盲目使用默认网络插件。Kubernetes默认的CNI（如Flannel）使用VXLAN封装，网络开销较大。对于需要NCCL通信的分布式训练，应使用支持RDMA或RoCE的网络插件，或使用云厂商提供的弹性网卡直通模式。

2.6 小结

容器化技术为AI训练提供了环境一致性和资源调度的基础，但AI训练负载的长时运行、GPU独占、高通信带宽和故障恢复需求，决定了它不能简单套用Web服务的容器化模式。Docker负责将复杂的训练环境封装为可移植镜像，Kubernetes则通过GPU感知调度、持久卷、CRD扩展和拓扑亲和性策略，为分布式训练提供可靠的运行平台。理解这两者的职责边界和AI负载的特殊性，是后续设计多云训练环境的第一步。