数据科学家在AWS上用Kubernetes跑通ML训练Pipeline实战

1. 这不是给运维工程师看的Kubernetes入门——而是一个数据科学家在AWS上真正跑通模型训练 pipeline 的实操手记“Kubernetes”这个词对很多数据科学家来说像一堵贴着代码编辑器边缘缓缓升起的雾墙知道它很重要听说它能管集群、能扩缩容、能保障服务稳定但一打开官方文档满屏的 Pod、Service、Ingress、CRD、Operator……瞬间让人想关掉终端转头去调参。更现实的问题是我手头只有三台 spot 实例一个正在迭代的 PyTorch 训练脚本一份要下周交付的 A/B 测试报告以及老板刚发来的 Slack 消息“能不能让模型每天自动重训一次”——这时候Kubernetes 是解药还是另一道待解的微分方程我花了整整 7 周时间在 AWS 上从零搭建、调试、压测、踩坑、重构最终把一个原本需要手动 SSH 登录三台机器、改路径、杀进程、查日志、等 GPU 显存释放的训练流程变成一条点击按钮或触发 webhook就能全自动执行、失败自动重试、资源用量实时可视、模型版本可追溯的 pipeline。整个过程没碰过kubectl apply -f一百次以上也没写过一行 YAML 来定义 StatefulSet 或 HorizontalPodAutoscaler——因为那不是数据科学家该优先掌握的起点。真正的起点是搞懂Kubernetes 在 AWS 上到底替你接管了哪几类重复性高、出错率高、又毫无建模价值的劳动答案很具体环境一致性conda vs pip vs system lib 冲突、GPU 资源抢占jupyter lab 和训练任务抢卡、训练中断恢复spot 实例被回收后如何续跑、日志与指标分散每台机器 tail -f 不同文件、以及最痛的一点——每次换模型结构都要重新打包镜像、推到 ECR、更新部署配置。这篇指南不讲 etcd 原理不画 control plane 架构图不对比 EKS vs Kops vs self-managed。它只聚焦一件事一个真实的数据科学家在 AWS 上用 Kubernetes 解决他明天就要面对的五个具体问题。你会看到如何用eksctl三分钟创建一个带 GPU 节点组的最小可用集群怎么把本地 JupyterLab 无缝迁移到集群里且支持.ipynb文件实时同步如何用 Argo Workflows 编排一个含数据预处理 → 模型训练 → 模型评估 → 模型注册的四步 pipeline并让每一步失败时自动告警到 Slack怎么设置 spot 实例中断前的优雅退出让训练跑到第 87% 时被回收重启后能从 checkpoint 继续而非从头开始以及最关键的——所有这些操作背后对应的 AWS 资源成本是多少按月估算是否真的比 EC2 Auto Scaling Group 更划算。全文所有命令、配置、截图逻辑文字描述版、参数取值依据均来自我在一家中型 SaaS 公司生产环境落地的真实记录已剔除所有敏感信息保留全部技术细节。适合正在被“环境不一致”、“GPU 抢占”、“训练中断”、“pipeline 手动维护”折磨的 ML 工程师、数据科学家、以及想把 notebook 项目升级为可交付产品的算法负责人。2. 为什么数据科学家不该从“学 Kubernetes”开始而该从“定义自己的最小可行集群需求”开始很多数据科学家第一次接触 Kubernetes是被一篇《K8s 是未来》的公众号文章点燃热情然后兴致勃勃地照着某教程在本地用 Minikube 启动一个单节点集群接着发现连kubectl get nodes都报错再查半天是 Docker Desktop 的 k8s 功能没开……热情耗尽回归tmux ssh。这不是你的问题是路径错了。Kubernetes 本质是一个分布式系统协调器它的价值不在“运行一个容器”而在“可靠地协调成百上千个容器协同完成一件复杂任务”。对数据科学家而言这个“复杂任务”从来不是抽象概念而是非常具体的五件事任务隔离JupyterLab 占用 1 张 V100训练脚本需要 2 张推理 API 又要 1 张——它们不能互相挤占显存也不能因一个 OOM kill 掉另一个。状态延续训练到第 3 天spot 实例被 AWS 回收checkpoint 存在 EBS 上但新实例挂载不到同一块盘——如何让新 Pod 自动找到并加载上次的权重依赖固化本地 conda 环境装了cudatoolkit11.3但集群节点默认是11.8torch.cuda.is_available()返回 False——如何确保每个训练任务启动时CUDA 版本、cuDNN 版本、PyTorch 编译 ABI 完全一致可观测性想知道当前所有训练任务的 GPU 利用率、显存占用、IO 等待时间而不是登录每台机器nvidia-smi逐个看。触发自动化数据仓库每天凌晨 2 点更新fact_orders表如何让模型训练在表更新完成后 5 分钟内自动启动且失败时发钉钉消息这五件事就是你的“最小可行集群需求”Minimum Viable Cluster Requirements, MVCR。它决定了你不需要一开始就理解kube-scheduler的 predicate 和 priority 函数但必须清楚要实现任务隔离你需要启用 Kubernetes 的ResourceQuota和LimitRange并为每个命名空间比如ml-dev、ml-prod设置 GPU 限额要实现状态延续你得放弃直接挂载 EBSEBS 不支持多节点读写转而使用 Amazon EFS支持 POSIX并发读写或 S3对象存储需适配 checkpoint 加载逻辑要实现依赖固化你必须把所有环境封装进 Docker 镜像且镜像基础层必须与节点 AMI 的 CUDA 驱动兼容——这意味着你选的 EKS 优化 AMI 版本直接锁定了你能用的 PyTorch 版本范围要实现可观测性你不必自建 Prometheus但必须安装amazon-cloudwatch-metrics-collectorDaemonSet并配置cloudwatch-agent将nvidia-smi输出指标推送到 CloudWatch要实现触发自动化你可以跳过复杂的 EventBridge Lambda EKS API 调用链直接用 Argo Events 监听 S3 新对象事件触发 Argo Workflow。提示不要试图一次性满足全部五点。我的建议是严格按优先级落地先解决“依赖固化”镜像化和“任务隔离”命名空间资源限制这是零成本、零风险、立竿见影的改进再攻克“状态延续”EFS/S3 集成这需要改少量代码但收益巨大最后做“可观测性”和“触发自动化”它们提升的是长期运维效率而非当下交付能力。为什么强调“从需求出发”因为 AWS 上的 Kubernetes 有太多可选项而错误的选择会把你拖入无底深渊。比如你选了EKS Managed Node Groups却没开启capacity-type: SPOT结果 GPU 实例账单每月 $12,000而业务实际只用了 30% 时间你用了Fargate启动训练任务却发现 Fargate 不支持 GPU所有深度学习任务直接报错No available GPU device你手动创建了Self-Managed Control Plane结果某天etcdleader 选举失败整个集群 API Server 不可用而你既不会修也不会备份——此时模型重训 deadline 还剩 4 小时。所以第一步不是敲命令而是拿出一张纸写下你接下来三个月内最常做的三件计算密集型任务例如1. 每日特征工程 LightGBM 训练2. 每周 PyTorch 图神经网络全量重训3. 每月大促前的实时推荐模型 A/B 测试流量切分然后针对每件事问自己它卡在哪个环节是环境不一致是资源不够是人工操作太慢把答案填进上面的五点 MVCR 表格里。这张表就是你后续所有技术选型的唯一判据。3. 用 eksctl 创建生产就绪集群避开那些 AWS 控制台里根本找不到的隐藏参数很多人以为创建 EKS 集群点点控制台就完事了。事实是AWS 控制台创建的 EKS 集群默认不开启任何安全加固、不绑定 IRSAIAM Roles for Service Accounts、不配置 GPU 节点组、不启用 cluster autoscaler——它只是一个“能跑起来”的空壳离“数据科学家能用”差了至少十步。真正高效的做法是用eksctl——一个由 Weaveworks 开发、被 AWS 官方背书的 CLI 工具它把所有底层 CloudFormation 模板、IAM 策略、节点组配置封装成人类可读的 YAML。下面是我目前在用的、经过 3 个生产环境验证的cluster.yaml配置它会在 8 分钟内创建一个开箱即用的 ML 集群# cluster.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: ml-prod-cluster region: us-west-2 version: 1.28 # 必须与 EKS 支持的最新稳定版对齐1.28 是 2024 年 Q2 最佳实践 vpc: cidr: 10.192.0.0/16 nat: gateway: Single # 一个 NAT Gateway 足够省钱 iam: withOIDC: true # 必开这是 IRSA 的前提让 Pod 能安全获取 IAM 权限 serviceAccounts: - metadata: name: efs-csi-controller-sa namespace: kube-system wellKnownPolicies: ebs: true - metadata: name: cloudwatch-agent-sa namespace: amazon-cloudwatch wellKnownPolicies: cloudWatchFullAccess: true fargateProfiles: - name: fp-default selectors: - namespace: default nodeGroups: - name: gpu-ng instanceType: g4dn.xlarge # 1x T4 GPU, 4 vCPU, 16 GiB RAM —— 性价比之王 minSize: 1 maxSize: 5 desiredCapacity: 2 volumeSize: 100 # 根盘大小足够存镜像层 amiFamily: AmazonLinux2 # 必须AL2 预装 NVIDIA 驱动和 nvidia-container-toolkit labels: { role: ml-gpu } tags: nodegroup-role: ml-gpu iam: withAddonPolicies: imageBuilder: true autoScaler: true ebs: true fsx: true # 关键spot 实例配置直接决定成本 capacityType: SPOT # spot 中断前 2 分钟发送 SIGTERM给应用留出保存 checkpoint 时间 # 这个参数在控制台里根本找不到只能通过 eksctl 设置 instanceMetadata: httpEndpoint: enabled httpPutResponseHopLimit: 2 # 启用节点自动伸缩无需手动增删节点 scalingConfig: minSize: 1 maxSize: 5 desiredCapacity: 2 addons: - name: vpc-cni version: latest resolveConflicts: OVERWRITE - name: coredns version: latest resolveConflicts: OVERWRITE - name: kube-proxy version: latest resolveConflicts: OVERWRITE - name: aws-ebs-csi-driver version: latest resolveConflicts: OVERWRITE - name: aws-efs-csi-driver # 必装用于挂载 EFS 作为共享存储 version: latest resolveConflicts: OVERWRITE现在我们逐行拆解这个配置里那些“控制台里找不到但对数据科学家生死攸关”的参数3.1amiFamily: AmazonLinux2—— 为什么不能选Ubuntu2004EKS 节点 AMI 是预装了特定驱动和工具的定制镜像。AmazonLinux2AMI 默认包含nvidia-driver525.85.122024 年 6 月最新版完美兼容pytorch2.0.1cu117nvidia-container-toolkit让容器 runtimecontainerd能识别--gpus all参数nvtop一个比nvidia-smi更直观的 GPU 监控工具支持按进程排序。而Ubuntu2004AMI 虽然也能装驱动但需要你手动执行sudo apt install nvidia-driver-525且不同 Ubuntu 版本的驱动包名、依赖关系、内核模块签名方式完全不同。我曾在一个客户环境里因为 Ubuntu 20.04 的nvidia-dkms与 EKS 节点内核版本不匹配导致modprobe nvidia失败GPU 设备在/dev/下完全不可见排查了 17 小时才发现是 AMI 选型错误。AmazonLinux2是 AWS 官方测试并保证兼容的省下的时间够你调完两个 learning rate。3.2capacityType: SPOTinstanceMetadata.httpPutResponseHopLimit: 2—— spot 实例中断的黄金 120 秒AWS spot 实例被回收前会向实例元数据服务http://169.254.169.254/latest/meta-data/spot/termination-time写入一个终止时间戳格式为YYYY-MM-DDTHH:MM:SSZ。这个时间戳提前 2 分钟写入。关键在于默认情况下这个 HTTP 端点的响应跳数hop limit是 1意味着只有本机 curl 能访问Pod 里的容器无法访问。如果你没设httpPutResponseHopLimit: 2那么你的训练脚本永远收不到中断信号checkpoint 来不及保存就被强制 kill。实测数据在g4dn.xlarge实例上从收到 termination-time 到实例真正 shutdown平均间隔 118 秒。这 118 秒就是你保存 checkpoint、上传到 S3、清理临时文件的全部时间。我在训练脚本里加了这段逻辑import requests import time import torch def check_spot_termination(): try: resp requests.get(http://169.254.169.254/latest/meta-data/spot/termination-time, timeout2) if resp.status_code 200: print(f[SPOT] Termination scheduled at {resp.text}. Saving checkpoint...) torch.save(model.state_dict(), /mnt/efs/checkpoints/latest.pth) # 上传到 S3使用 boto3 return True except: pass return False # 在训练循环中每 30 秒检查一次 for epoch in range(num_epochs): for batch in dataloader: train_step(batch) if epoch % 10 0 and check_spot_termination(): break3.3aws-efs-csi-driveraddon —— 为什么不用 EBS而必须用 EFSEBS 是块存储一个 EBS 卷只能挂载到一台 EC2 实例上。而你的训练任务可能被调度到任意 GPU 节点如果 checkpoint 存在 EBS 上新 Pod 启动时根本找不到那个卷。EFS 是文件存储支持 NFSv4.1 协议允许多个 Pod 同时以读写模式挂载同一目录。更重要的是EFS 有Performance Mode: maxIO模式专为高并发小文件 IO如 checkpoint 的千级.pt文件优化。实测对比在g4dn.xlarge节点上从 EFS 读取一个 500MB 的.pth文件平均耗时 1.8 秒从通用型 EBSgp3, 3000 IOPS读取平均耗时 4.3 秒。别小看这 2.5 秒一个训练任务每天 save/load 20 次 checkpoint就多花 50 秒一个月就是 25 分钟——够你跑完一个 baseline 实验。安装 EFS CSI Driver 后你只需创建一个PersistentVolume和PersistentVolumeClaim然后在 Pod spec 里声明挂载# efs-pv.yaml apiVersion: v1 kind: PersistentVolume metadata: name: efs-pv spec: capacity: storage: 1Ti accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain storageClassName: efs-sc csi: driver: efs.csi.aws.com volumeHandle: fs-xxxxxxxxxx:/ml-data # EFS 文件系统 ID 路径 --- # efs-pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: efs-claim spec: accessModes: - ReadWriteMany storageClassName: efs-sc resources: requests: storage: 1Ti然后在你的训练 Job YAML 里volumeMounts: - name: efs-storage mountPath: /mnt/efs volumes: - name: efs-storage persistentVolumeClaim: claimName: efs-claim这样无论 Pod 被调度到哪个节点/mnt/efs/checkpoints/目录始终指向同一份数据。4. 数据科学家的第一站把 JupyterLab 搬进集群且让它比本地更快、更稳、更协作对绝大多数数据科学家“上 Kubernetes” 的第一个刚需不是跑训练而是把 JupyterLab 从本地笔记本搬到集群里。原因很实在本地笔记本内存只有 16GB跑不了全量特征公司数据在 VPC 内网本地连不上 Redshift同事想复现你的 notebook却因为pandas1.3.5和1.4.0的 groupby 行为差异结果对不上。但直接kubectl create deployment jupyter --imagejupyter/scipy-notebook是灾难的开始——你会发现每次重启 Jupyter所有已安装的包pip install transformers都丢失上传的.ipynb文件存在容器里Pod 重启就清空想用%matplotlib inline画图但容器里没装tkinter报错TclError: no display name and no $DISPLAY environment variable多人同时访问同一个 Jupytersession 互相污染。真正的解决方案是构建一个“有状态、可持久、带 GUI 依赖、支持团队协作”的 JupyterLab 部署。以下是我在生产环境使用的完整方案它解决了上述所有问题4.1 构建一个“自带轮子”的 JupyterLab 镜像不要用官方jupyter/scipy-notebook。它太轻量缺了数据科学家真正需要的东西。我基于jupyter/tensorflow-notebook它预装了 CUDA 工具链做了深度定制Dockerfile 核心片段如下FROM jupyter/tensorflow-notebook:spark-3.4.1 # 安装 tkinter解决 matplotlib 显示问题 RUN apt-get update apt-get install -y \ tk-dev \ rm -rf /var/lib/apt/lists/* # 安装 AWS CLI v2 和 s3fs-fuse方便直接读写 S3 RUN curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip \ unzip awscliv2.zip \ sudo ./aws/install \ rm -rf awscliv2.zip aws # 安装 s3fs-fuse让 S3 像本地目录一样挂载 RUN apt-get update apt-get install -y \ s3fs \ rm -rf /var/lib/apt/lists/* # 预装常用 ML 库避免每次 notebook 里 pip install RUN pip install --no-cache-dir \ pandas1.5.3 \ scikit-learn1.2.2 \ lightgbm3.3.5 \ xgboost1.7.5 \ boto31.26.159 \ s3fs2023.6.0 \ fsspec2023.6.0 \ pyarrow11.0.0 \ dask[dataframe]2023.6.0 # 创建非 root 用户符合 Kubernetes 最佳安全实践 ARG NB_USERjovyan ARG NB_UID1001 ENV USER${NB_USER} ENV NB_UID${NB_UID} ENV HOME/home/${NB_USER} # 拷贝自定义配置 COPY jupyter_notebook_config.py /home/${NB_USER}/.jupyter/jupyter_notebook_config.py COPY start.sh /usr/local/bin/start.sh RUN chmod x /usr/local/bin/start.sh # 暴露端口设置工作目录 EXPOSE 8888 WORKDIR /home/${NB_USER} USER ${NB_USER} CMD [start.sh]其中jupyter_notebook_config.py关键配置# 启用密码认证而非 token方便团队统一管理 c.NotebookApp.password sha1:xxxxxxxxxxxxxxxxxxxxxxxxxxxx # 用 jupyter notebook password 生成 # 允许跨域让前端 UI如 JupyterHub能调用 c.NotebookApp.allow_origin * c.NotebookApp.disable_check_xsrf True # 自动保存间隔缩短到 30 秒防丢代码 c.NotebookApp.autosave_interval 30000 # 默认打开 terminal方便快速 git pull c.NotebookApp.terminals_enabled Truestart.sh脚本负责启动前的初始化#!/bin/bash # 检查 /mnt/efs 是否挂载未挂载则创建并挂载 if [ ! -d /mnt/efs ]; then mkdir -p /mnt/efs # 使用 s3fs 挂载 S3 bucket 到 /mnt/s3供 notebook 直接读写 s3fs my-company-ml-data /mnt/s3 -o passwd_file/home/jovyan/.passwd-s3fs -o urlhttps://s3.us-west-2.amazonaws.com -o use_path_request_style fi # 启动 JupyterLab exec jupyter lab --ip0.0.0.0 --port8888 --allow-root --no-browser --NotebookApp.token --NotebookApp.passwordsha1:xxx这个镜像构建好后推送到 ECRaws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-west-2.amazonaws.com docker build -t 123456789012.dkr.ecr.us-west-2.amazonaws.com/ml-jupyter:2024q2 . docker push 123456789012.dkr.ecr.us-west-2.amazonaws.com/ml-jupyter:2024q24.2 用 StatefulSet 部署绑定 EFS 持久卷Deployment 适合无状态服务JupyterLab 是有状态的——用户上传的 notebook、安装的包、修改的配置都需要持久化。StatefulSet 是唯一能保证 Pod 名字、网络标识、存储卷一一绑定的控制器。# jupyter-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: jupyter-server namespace: ml-dev spec: serviceName: jupyter-headless replicas: 1 selector: matchLabels: app: jupyter-server template: metadata: labels: app: jupyter-server spec: serviceAccountName: jupyter-sa # 绑定 IRSA让 notebook 能访问 S3 containers: - name: jupyter image: 123456789012.dkr.ecr.us-west-2.amazonaws.com/ml-jupyter:2024q2 ports: - containerPort: 8888 env: - name: JUPYTER_ENABLE_LAB value: true volumeMounts: - name: efs-storage mountPath: /home/jovyan/work # 所有 notebook 存放在此 - name: s3-mount mountPath: /mnt/s3 volumes: - name: efs-storage persistentVolumeClaim: claimName: efs-claim # 复用前面创建的 PVC - name: s3-mount emptyDir: {} # s3fs 挂载点用 emptyDir 即可 volumeClaimTemplates: - metadata: name: notebook-storage spec: accessModes: [ReadWriteOnce] resources: requests: storage: 50Gi4.3 用 Ingress 暴露服务集成公司 SSO直接用NodePort或LoadBalancer暴露 Jupyter意味着每个用户都要记一个 IP端口且无法做统一身份认证。正确做法是创建一个Ingress资源将jupyter.mycompany.com域名路由到jupyter-serverService在 Ingress Controller我用的是 ALB Ingress Controller前挂载 AWS Cognito 用户池实现 SSO 登录Cognito 认证成功后将用户身份如cognito:username注入到请求 headerJupyterLab 通过c.NotebookApp.trust_xheaders True读取实现单点登录。ALB Ingress 配置片段apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: jupyter-ingress namespace: ml-dev annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip # 启用 Cognito 认证 alb.ingress.kubernetes.io/auth-type: cognito alb.ingress.kubernetes.io/auth-scheme: https alb.ingress.kubernetes.io/auth-on-unauthenticated-request: authenticate alb.ingress.kubernetes.io/auth-domain-prefix: jupyter-auth alb.ingress.kubernetes.io/auth-user-pool-arn: arn:aws:cognito-idp:us-west-2:123456789012:userpool/us-west-2_xxxxxxxx alb.ingress.kubernetes.io/auth-scope: openid spec: rules: - host: jupyter.mycompany.com http: paths: - path: /* pathType: Prefix backend: service: name: jupyter-service port: number: 8888这样团队成员只需访问https://jupyter.mycompany.com用公司邮箱登录即可进入自己的专属 JupyterLab 环境所有 notebook 自动保存到 EFS所有 S3 数据通过/mnt/s3目录无缝访问。实测下来从点击登录到 notebook 加载完成平均耗时 2.3 秒比本地 M1 MacBook Pro 还快——因为 EFS 的maxIO模式 NVMe 根盘IO 延迟远低于本地 SSD 的随机读写。5. 编排你的第一个 ML Pipeline用 Argo Workflows 实现“数据更新 → 训练 → 评估 → 上线”全自动闭环当 JupyterLab 稳定运行后下一个痛点自然浮现如何把 notebook 里手动执行的步骤变成一条可靠的、可审计的、可重试的 pipeline比如一个典型的推荐模型迭代流程数据准备从 Redshift 导出过去 30 天用户行为日志到 S3路径s3://my-bucket/raw/events/2024-06-01/特征工程用 Spark SQL 计算用户兴趣向量输出 Parquet 到s3://my-bucket/features/user_emb/2024-06-01/模型训练用 PyTorch 加载特征训练 24 小时保存 checkpoint 到s3://my-bucket/models/recsys/2024-06-01/模型评估用 AUC、Recall10 指标评估新模型若 AUC 0.85则触发上线模型上线将新模型权重复制到s3://my-bucket/models/recsys/prod/并更新 SageMaker Endpoint 配置。手动执行这套流程一次要 2 小时且极易出错比如忘了改日期路径导致覆盖旧数据。Argo Workflows 是 Kubernetes 原生的 workflow 引擎它用 YAML 定义 DAG有向无环图每个 step 是一个独立的 Pod失败可重试状态可追踪日志可查询——完美匹配 ML pipeline 需求。5.1 安装 Argo Workflows 和 Argo Events# 安装 Argo Workflows带 UI kubectl create ns argo kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo-workflows/stable/manifests/install.yaml # 安装 Argo Events用于监听外部事件 kubectl create ns argo-events kubectl apply -n argo-events -f https://raw.githubusercontent.com/argoproj/argo-events/stable/manifests/install.yaml5.2 定义一个端到端的推荐模型 pipeline以下是一个精简但完整的recsys-pipeline.yaml它实现了上述五步# recsys-pipeline.yaml apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: recsys-train- namespace: ml-prod spec: entrypoint: main # 全局参数可被所有 steps 引用 arguments: parameters: - name: date value: 2024-06-01 - name: model-name value: recsys-v2 # 定义所有需要用到的容器镜像 templates: - name: main dag: tasks: - name:>