12 - AI 机器人公司基础设施全景规划

一、当前状态与差距分析

现有基础设施

组件	状态	说明
ACK	✅ 已有	容器编排平台
ACR	✅ 已有	容器镜像仓库
CPFS 智算版	✅ 已有	高性能并行文件系统（训练数据）
OSS	✅ 已有	对象存储（数据集、模型归档、日志）
ESSD 云盘	✅ 已有	每台算力机 2TB 本地高速存储
GitLab	🟡 自建未推广	代码托管（需推广或替换）

完整基础设施全景

┌──────────────────────────────────────────────────────────────────────────────┐
│                     AI 机器人公司 - 基础设施全景                                │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        一、计算层                                       │  │
│  │  ACK 集群                                                              │  │
│  │  ├── CPU 通用节点池 (ecs.g7/c7)     ← 业务服务、基础设施               │  │
│  │  ├── GPU 训练节点池 (A100/A800)     ← 分布式训练                      │  │
│  │  ├── GPU 推理节点池 (A10/T4)        ← 在线推理                        │  │
│  │  ├── GPU Spot 节点池 (抢占式)       ← 可容错训练任务                   │  │
│  │  └── 弹性节点 (虚拟节点 ECI)        ← 突发任务                        │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        二、存储层                                       │  │
│  │  ├── CPFS 智算版          ← 高性能训练数据读取            ✅ 已有       │  │
│  │  ├── OSS 对象存储         ← 原始数据、模型归档、日志       ✅ 已有       │  │
│  │  ├── ESSD 云盘 (2TB/机)   ← 算力机本地存储、数据库        ✅ 已有       │  │
│  │  └── NAS 通用型           ← 代码共享、配置文件（可选）     ⬜ 按需       │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        三、网络层                                       │  │
│  │  ├── VPC + VSwitch        ← 网络隔离                ⬜ 需确认           │  │
│  │  ├── SLB/ALB              ← 负载均衡                ⬜ 需补充           │  │
│  │  ├── NAT 网关             ← 集群节点访问外网         ⬜ 需补充           │  │
│  │  ├── DNS (PrivateZone)    ← 内部域名解析            ⬜ 需补充           │  │
│  │  ├── CDN                  ← 静态资源加速（OTA 包分发）⬜ 按需            │  │
│  │  └── VPN/专线             ← 办公室到云端安全连接      ⬜ 按需            │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        四、数据库层                                     │  │
│  │  ├── RDS PostgreSQL       ← 业务数据库              ⬜ 需补充           │  │
│  │  ├── Redis (Tair)         ← 缓存、会话              ⬜ 需补充           │  │
│  │  ├── MongoDB              ← 传感器数据、非结构化日志  ⬜ 按需            │  │
│  │  └── Lindorm/HBase        ← 时序数据（海量遥测数据）  ⬜ 后期            │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        五、CI/CD & 开发工具                             │  │
│  │  ├── GitLab (自建)        ← 代码托管                🟡 未推广           │  │
│  │  ├── GitLab CI / GitHub Actions ← CI 流水线         ⬜ 需建设           │  │
│  │  ├── ArgoCD               ← GitOps 持续部署         ⬜ 需建设           │  │
│  │  ├── ACR (已有)           ← 镜像仓库                ✅ 已有             │  │
│  │  └── Argo Rollouts        ← 灰度发布               ⬜ 后期              │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        六、可观测性                                     │  │
│  │  ├── Prometheus + Grafana ← 指标监控                ⬜ 需建设           │  │
│  │  ├── Loki / SLS           ← 日志聚合                ⬜ 需建设           │  │
│  │  ├── DCGM Exporter        ← GPU 监控               ⬜ 需建设           │  │
│  │  ├── AlertManager         ← 告警                   ⬜ 需建设           │  │
│  │  └── 告警通道             ← 飞书/钉钉/短信/电话     ⬜ 需对接           │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        七、安全                                         │  │
│  │  ├── RAM                  ← 身份与访问管理           ⬜ 需规划           │  │
│  │  ├── KMS                  ← 密钥管理（Secret 加密）  ⬜ 需补充           │  │
│  │  ├── 安全中心             ← 漏洞扫描、入侵检测       ⬜ 按需             │  │
│  │  ├── WAF                  ← Web 应用防火墙           ⬜ 按需             │  │
│  │  ├── SSL 证书             ← HTTPS                  ⬜ 需补充            │  │
│  │  └── 堡垒机 (Bastion)     ← 运维跳板               ⬜ 按需              │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        八、AI/ML 平台                                   │  │
│  │  ├── JupyterHub          ← 开发调试环境             ⬜ 需建设           │  │
│  │  ├── MLflow / W&B        ← 实验追踪                ⬜ 需建设            │  │
│  │  ├── 模型仓库 (Model Registry) ← 模型版本管理       ⬜ 需建设           │  │
│  │  ├── 标注平台             ← 数据标注                ⬜ 需建设/采购       │  │
│  │  ├── Feature Store        ← 特征存储               ⬜ 后期              │  │
│  │  └── Kubeflow / Arena     ← 训练任务管理            ⬜ 需建设           │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
│                                                                              │
│  ┌────────────────────────────────────────────────────────────────────────┐  │
│  │                        九、协作工具                                     │  │
│  │  ├── 文档系统             ← Confluence/飞书文档/Notion ⬜ 需统一         │  │
│  │  ├── 项目管理             ← Jira/Linear/飞书项目     ⬜ 需统一           │  │
│  │  └── 即时通讯             ← 飞书/钉钉/Slack         （假设已有）        │  │
│  └────────────────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────────────────┘

二、各层详细规划

2.1 计算层（ACK 集群增强）

你们已经有 ACK，关键是节点池的合理划分：

ACK 集群节点池规划
─────────────────

┌─────────────────────────────────────────────────────────────┐
│ 节点池名称        │ 规格              │ 数量  │ 用途           │
├─────────────────────────────────────────────────────────────┤
│ cpu-general       │ ecs.c7.2xlarge    │ 3-8   │ API 服务、Web  │
│                   │ (8C16G)           │       │ 基础设施组件    │
├─────────────────────────────────────────────────────────────┤
│ gpu-training      │ ecs.gn7i (A100)   │ 0-N   │ 分布式训练     │
│                   │ 或 ecs.gn7 (V100) │ 弹性  │ 仿真任务       │
├─────────────────────────────────────────────────────────────┤
│ gpu-inference     │ ecs.gn7i (A10)    │ 2-4   │ LLM/视觉推理   │
│                   │ 或 ecs.gn6i (T4)  │       │ 在线服务       │
├─────────────────────────────────────────────────────────────┤
│ gpu-spot          │ 抢占式 GPU 实例    │ 0-N   │ 可容错训练     │
│                   │                   │ 弹性  │ 数据预处理     │
├─────────────────────────────────────────────────────────────┤
│ eci-virtual       │ 虚拟节点 (ECI)    │ 弹性  │ CI/CD 构建     │
│                   │                   │       │ 突发批处理     │
└─────────────────────────────────────────────────────────────┘

关键配置：

yaml

# 节点池 Taint/Label 规划
# GPU 训练节点
taints:
- key: nvidia.com/gpu-type
  value: training
  effect: NoSchedule
labels:
  node-pool: gpu-training
  gpu-type: a100

# GPU 推理节点
taints:
- key: nvidia.com/gpu-type
  value: inference
  effect: NoSchedule
labels:
  node-pool: gpu-inference
  gpu-type: a10

2.2 存储层现状分析

你们的存储配置已经很好：

组件	现状	用途	说明
CPFS 智算版	✅ 已有	训练数据高速读取	核心存储，吞吐 10+ GB/s
OSS	✅ 已有	原始数据、模型归档、日志	容量无限，成本低
ESSD 云盘	✅ 已有	算力机本地存储（2TB/台）	高 IOPS，适合临时数据和缓存
NAS	⬜ 缺失	代码/配置共享	非必须，可用 CPFS 替代

你们的存储架构已具备 AI 训练的最优基础，CPFS 智算版是分布式训练场景的顶配方案。

存储分工建议

CPFS 智算版 (已有)                         OSS (已有) — 训练数据主存储
├── /users/                                ├── datasets/        ← 训练数据集（主存储）
│   ├── zhangsan/projects/  ← 算法代码     │   ├── imagenet/
│   └── lisi/projects/                     │   ├── coco/
├── /datasets/              ← OSS 同步来的  │   └── custom-robotics/
│   ├── imagenet/           热数据缓存      ├── models/          ← 模型归档（长期保存）
│   └── coco/                              │   ├── v1.0/
├── /checkpoints/           ← 训练输出      │   └── v2.0/
│   └── resnet50-20260315/                 ├── logs/            ← 训练日志归档
├── /shared/                ← 公共工具/预训练模型  └── raw-data/   ← 原始采集数据
└── /models/staging/        ← 待部署模型

ESSD 云盘 (每台 2TB)
├── /local-cache/     ← 训练数据本地缓存（加速首次读取）
├── /tmp-workspace/   ← 临时工作空间
└── /docker-data/     ← Docker/容器运行时数据

ESSD 本地缓存加速策略

每台算力机有 2TB ESSD，可以利用本地磁盘做训练数据缓存：

yaml

# 训练 Pod 中同时挂载 CPFS 和 ESSD 本地缓存
apiVersion: v1
kind: Pod
metadata:
  name: training-pod
spec:
  containers:
  - name: trainer
    volumeMounts:
    - name: cpfs-data
      mountPath: /data/cpfs          # CPFS 远程数据
    - name: local-cache
      mountPath: /data/local-cache   # ESSD 本地缓存
    command:
    - python
    - train.py
    - --data-dir=/data/local-cache   # 优先读本地缓存
  initContainers:
  - name: data-sync
    image: busybox
    command:
    - sh
    - -c
    - |
      # 首次启动时将数据从 CPFS 同步到本地 ESSD
      if [ ! -f /data/local-cache/.synced ]; then
        cp -r /data/cpfs/datasets/current/ /data/local-cache/
        touch /data/local-cache/.synced
      fi
    volumeMounts:
    - name: cpfs-data
      mountPath: /data/cpfs
    - name: local-cache
      mountPath: /data/local-cache
  volumes:
  - name: cpfs-data
    persistentVolumeClaim:
      claimName: cpfs-training-data
  - name: local-cache
    hostPath:
      path: /mnt/local-cache         # ESSD 挂载路径
      type: DirectoryOrCreate

缓存收益：

首次训练：从 CPFS 拷贝到 ESSD（一次性开销）
后续训练：直接读 ESSD 本地数据（零网络延迟）
数据更新时：重新同步 CPFS → ESSD

2.3 网络层

必须建设的网络组件
──────────────────

┌── VPC (专有网络) ─────────────────────────────────────┐
│                                                       │
│  ┌── VSwitch (交换机) ──────────────────────────────┐ │
│  │                                                   │ │
│  │  ACK 集群 Pod CIDR: 172.16.0.0/16               │ │
│  │  ACK 集群 Service CIDR: 172.21.0.0/20           │ │
│  │                                                   │ │
│  └───────────────────────────────────────────────────┘ │
│                                                       │
│  ┌── ALB (应用型负载均衡) ──────────────────────────┐ │
│  │  api.robotics.com   → ACK Ingress → API 服务     │ │
│  │  admin.robotics.com → ACK Ingress → 管理后台     │ │
│  │  jupyter.robotics.com → ACK Ingress → JupyterHub │ │
│  └───────────────────────────────────────────────────┘ │
│                                                       │
│  ┌── NAT 网关 ──────────────────────────────────────┐ │
│  │  集群节点拉取外部镜像                              │ │
│  │  节点访问 pip/npm/apt 源                          │ │
│  │  训练代码下载预训练模型                            │ │
│  └───────────────────────────────────────────────────┘ │
│                                                       │
│  ┌── 内网 DNS (PrivateZone) ────────────────────────┐ │
│  │  pg.internal.robotics.com → RDS PostgreSQL       │ │
│  │  redis.internal.robotics.com → Redis             │ │
│  │  nas.internal.robotics.com → NAS 挂载点          │ │
│  └───────────────────────────────────────────────────┘ │
│                                                       │
└───────────────────────────────────────────────────────┘

各组件需求：

组件	必要性	说明
VPC	必须	ACK 已在 VPC 内，确认网段规划合理
ALB	必须	ACK Ingress 的后端负载均衡器
NAT 网关	必须	没有 NAT，节点无法访问外网（拉镜像、装依赖）
PrivateZone	推荐	内部服务用域名而非 IP 访问
CDN	按需	如果有 OTA 包分发、前端静态资源加速
VPN/专线	推荐	开发人员安全访问集群和内网资源

2.4 数据库层

推荐的数据库组合
────────────────

┌── RDS PostgreSQL ─────────────────────────────────────┐
│  用途: 业务核心数据                                     │
│  ├── 用户系统                                          │
│  ├── 设备管理（机器人信息、状态）                        │
│  ├── 任务调度记录                                      │
│  ├── 模型版本元数据                                    │
│  └── 标注任务管理                                      │
│                                                       │
│  推荐规格: pg.x4.medium.2c (2C8G)                     │
│  高可用: 主备双节点                                     │
│  存储: ESSD 云盘，自动扩容                              │
└───────────────────────────────────────────────────────┘

┌── Redis (Tair) ───────────────────────────────────────┐
│  用途: 缓存 + 会话 + 队列                              │
│  ├── API 响应缓存                                     │
│  ├── 用户 Session                                     │
│  ├── 任务队列（Celery broker）                         │
│  ├── 推理结果缓存                                     │
│  └── 分布式锁                                         │
│                                                       │
│  推荐规格: 标准版 1G 起                                 │
│  高可用: 主备双节点                                     │
└───────────────────────────────────────────────────────┘

┌── MongoDB (按需) ─────────────────────────────────────┐
│  用途: 半结构化数据                                     │
│  ├── 传感器原始数据（JSON/BSON）                       │
│  ├── 机器人行为日志                                    │
│  ├── 标注结果（复杂嵌套结构）                           │
│  └── 实验配置快照                                      │
│                                                       │
│  初期可用 PG 的 JSONB 替代，后期量大再单独部署           │
└───────────────────────────────────────────────────────┘

ACK 中如何连接这些数据库：

yaml

# 数据库连接信息通过 Secret 管理
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: production
type: Opaque
stringData:
  DATABASE_URL: "postgresql://user:[email protected]:5432/robotics"
  REDIS_URL: "redis://:[email protected]:6379/0"
---
# Pod 中引用
env:
- name: DATABASE_URL
  valueFrom:
    secretKeyRef:
      name: db-credentials
      key: DATABASE_URL

2.5 CI/CD & 开发工具

GitLab 推广 or 迁移到 GitHub？

维度	自建 GitLab	GitHub (Team/Enterprise)
成本	服务器费用 + 运维人力	$4/人/月 (Team)
运维	需要自己维护升级备份	零运维
CI/CD	GitLab CI (内置)	GitHub Actions (生态丰富)
安全	自主可控	需信任 GitHub
适合	对数据主权有严格要求	初创公司推荐

建议：

如果没有合规/数据主权强制要求：
  → 迁移到 GitHub Team 版（$4/人/月）
  → 省去 GitLab 运维成本
  → GitHub Actions 生态更丰富

如果必须自建：
  → 推广 GitLab + GitLab CI
  → 分配专人维护
  → 定期备份、升级

必须建设的 CI/CD 组件

CI/CD 工具链
────────────

  代码托管 (GitLab/GitHub)
      │
      ├── CI: GitLab CI / GitHub Actions
      │   ├── Lint (ruff, mypy, eslint)
      │   ├── Test (pytest, jest)
      │   ├── Build (docker build)
      │   ├── Scan (Trivy 漏洞扫描)
      │   └── Push (→ ACR)
      │
      ├── CD: ArgoCD  ← 部署在 ACK 集群内
      │   ├── 自动同步 Staging
      │   ├── 手动审批 Production
      │   └── 回滚能力
      │
      └── 镜像仓库: ACR  ← 已有

2.6 可观测性（监控 + 日志 + 告警）

这是最容易被忽视但最重要的基础设施。

可观测性三支柱
──────────────

┌── Metrics (指标) ─────────────────────────────────────┐
│                                                       │
│  Prometheus (集群内 Helm 安装)                         │
│  ├── kube-state-metrics    ← K8s 资源状态             │
│  ├── node-exporter         ← 节点 CPU/内存/磁盘       │
│  ├── DCGM Exporter         ← GPU 利用率/显存/温度     │
│  ├── cAdvisor (内置)       ← 容器资源使用             │
│  └── 应用自定义 metrics    ← 业务指标                 │
│                                                       │
│  Grafana (可视化)                                      │
│  ├── K8s 集群仪表盘                                   │
│  ├── GPU 监控仪表盘                                   │
│  ├── 业务服务仪表盘                                   │
│  └── 发布仪表盘                                       │
└───────────────────────────────────────────────────────┘

┌── Logs (日志) ────────────────────────────────────────┐
│                                                       │
│  方案 A: Loki + Promtail (轻量，推荐初创公司)          │
│  方案 B: 阿里云 SLS (全托管，按量付费)                  │
│                                                       │
│  日志分类:                                             │
│  ├── 应用日志   → 结构化 JSON 输出                    │
│  ├── 访问日志   → Ingress access log                 │
│  ├── 训练日志   → 训练 loss/metric 输出               │
│  └── 审计日志   → K8s audit log                      │
└───────────────────────────────────────────────────────┘

┌── Alerts (告警) ──────────────────────────────────────┐
│                                                       │
│  AlertManager                                         │
│  ├── Critical → 电话/短信（节点宕机、服务不可用）       │
│  ├── Warning  → 飞书/钉钉群（CPU 高、磁盘满）         │
│  └── Info     → 仅记录（Pod 重启、扩容事件）           │
│                                                       │
│  告警渠道对接:                                         │
│  ├── 飞书机器人 Webhook                               │
│  ├── 钉钉机器人 Webhook                               │
│  ├── 阿里云短信服务                                   │
│  └── PagerDuty (国际化团队)                           │
└───────────────────────────────────────────────────────┘

安装命令：

bash

# Prometheus + Grafana 一键安装
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set grafana.adminPassword=YourSecurePassword \
  --set prometheus.prometheusSpec.retention=30d

# Loki + Promtail 安装
helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki-stack \
  --namespace monitoring \
  --set promtail.enabled=true \
  --set loki.persistence.enabled=true

# GPU 监控 (DCGM Exporter)
helm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts
helm install dcgm-exporter gpu-helm-charts/dcgm-exporter \
  --namespace monitoring

2.7 安全

组件	优先级	说明	阿里云产品
RAM 账号体系	P0	每人独立账号，最小权限原则	RAM
KMS 密钥管理	P0	K8s Secret 加密存储	KMS
SSL 证书	P0	HTTPS 加密，Let's Encrypt 或阿里云	证书服务
RBAC	P0	K8s 集群内权限控制	ACK 原生
NetworkPolicy	P1	Pod 间网络隔离	Terway CNI
安全中心	P1	漏洞扫描、基线检查	云安全中心
WAF	P2	对外 API 防护	Web 应用防火墙
堡垒机	P2	运维操作审计	云安全中心堡垒机

RAM 最小权限示例：

角色设计
────────

├── Admin           → 全部权限（仅 CTO/技术负责人）
├── DevOps          → ACK 管理 + ACR + SLB + 监控
├── Backend Dev     → ACK 查看 + staging 部署 + 日志
├── Algorithm Dev   → ACK 查看 + 训练节点池 + 日志 + NAS/CPFS
├── Frontend Dev    → ACK 查看 + staging 部署
├── Data Engineer   → OSS 读写 + NAS + 训练日志查看
└── Viewer          → 只读（产品、项目经理）

2.8 AI/ML 平台

组件	优先级	说明	方案
JupyterHub	P0	算法工程师的日常开发环境	部署在 ACK + GPU 节点
实验追踪	P0	记录训练参数、指标、模型版本	MLflow（开源）或 W&B
模型仓库	P1	模型版本管理、部署审批	MLflow Model Registry 或 OSS 手动管理
标注平台	P1	数据标注管理	Label Studio（开源）或采购
训练任务管理	P1	提交/监控分布式训练	Kubeflow Training Operator + Arena
Feature Store	P2	特征工程平台	Feast（开源），后期建设

JupyterHub 部署示例：

bash

helm repo add jupyterhub https://hub.jupyter.org/helm-chart/
helm install jupyterhub jupyterhub/jupyterhub \
  --namespace ml-platform --create-namespace \
  --values jupyterhub-values.yaml

yaml

# jupyterhub-values.yaml
singleuser:
  image:
    name: registry-vpc.cn-hangzhou.aliyuncs.com/robotics-base/jupyter-gpu
    tag: latest
  profileList:
  - display_name: "CPU 环境 (4C8G)"
    kubespawner_override:
      cpu_limit: 4
      mem_limit: "8G"
  - display_name: "GPU 环境 (T4)"
    kubespawner_override:
      cpu_limit: 8
      mem_limit: "16G"
      extra_resource_limits:
        nvidia.com/gpu: "1"
      tolerations:
      - key: nvidia.com/gpu-type
        operator: Equal
        value: inference
        effect: NoSchedule
  storage:
    type: dynamic
    capacity: 50Gi
    storageClass: alicloud-nas-subpath

hub:
  config:
    Authenticator:
      admin_users: ["admin"]
    JupyterHub:
      authenticator_class: nativeauthenticator.NativeAuthenticator

MLflow 部署示例：

yaml

# mlflow-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mlflow
  namespace: ml-platform
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mlflow
  template:
    metadata:
      labels:
        app: mlflow
    spec:
      containers:
      - name: mlflow
        image: ghcr.io/mlflow/mlflow:v2.12.1
        command:
        - mlflow
        - server
        - --host=0.0.0.0
        - --port=5000
        - --backend-store-uri=postgresql://mlflow:[email protected]:5432/mlflow
        - --default-artifact-root=oss://robotics-models/mlflow-artifacts
        ports:
        - containerPort: 5000
        resources:
          requests:
            cpu: 500m
            memory: 1Gi
---
apiVersion: v1
kind: Service
metadata:
  name: mlflow
  namespace: ml-platform
spec:
  selector:
    app: mlflow
  ports:
  - port: 5000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mlflow
  namespace: ml-platform
spec:
  ingressClassName: nginx
  rules:
  - host: mlflow.internal.robotics.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mlflow
            port:
              number: 5000

三、分阶段建设路线

Phase 1：基础保障（第 1-2 周）

目标: 让开发和部署跑通

✅ 已有: ACK, ACR, CPFS 智算版, OSS, ESSD (2TB/机)

需要补充:
├── [P0] ALB + Ingress Controller
│   └── 对外暴露服务的基础
├── [P0] NAT 网关
│   └── 节点访问外网（拉镜像、装依赖）
├── [P0] RDS PostgreSQL
│   └── 业务数据库
├── [P0] Redis
│   └── 缓存 + 队列
├── [P0] SSL 证书
│   └── HTTPS 加密
└── [P0] RAM 账号体系
    └── 每人独立权限

Phase 2：CI/CD 建设（第 3-4 周）

目标: 代码提交后自动构建部署

├── [P0] 推广 GitLab 或迁移到 GitHub
│   └── 统一代码托管
├── [P0] CI Pipeline (GitLab CI / GitHub Actions)
│   └── Lint → Test → Build → Scan → Push ACR
├── [P0] ArgoCD 安装和配置
│   └── GitOps 自动部署到 staging/production
└── [P0] K8s Manifests 仓库
    └── Kustomize 多环境管理

Phase 3：可观测性（第 5-6 周）

目标: 能看到集群和服务的状态

├── [P0] Prometheus + Grafana
│   └── 指标采集和可视化
├── [P0] DCGM Exporter
│   └── GPU 监控
├── [P0] Loki + Promtail (或 SLS)
│   └── 日志聚合
├── [P0] AlertManager + 告警通道
│   └── 飞书/钉钉通知
└── [P1] 核心仪表盘
    ├── K8s 集群概览
    ├── GPU 监控
    └── 各服务 RED 指标 (Rate/Error/Duration)

Phase 4：AI 平台（第 7-10 周）

目标: 算法团队能自助训练和调试

├── [P0] JupyterHub
│   └── 算法开发环境（连接 CPFS + GPU）
├── [P0] Kubeflow Training Operator
│   └── 分布式训练任务管理
├── [P1] ESSD 本地缓存策略
│   └── 利用 2TB ESSD 做训练数据缓存
├── [P1] MLflow
│   └── 实验追踪和模型仓库
└── [P1] Label Studio
    └── 数据标注平台

Phase 5：安全加固（第 11-12 周）

目标: 生产环境安全可靠

├── [P0] KMS + Secret 加密
├── [P1] NetworkPolicy
├── [P1] 安全中心基线检查
├── [P2] WAF
└── [P2] 堡垒机

Phase 6：进阶优化（第 13+ 周）

目标: 提升效率和降低成本

├── Argo Rollouts 灰度发布
├── Spot 实例 + Cluster Autoscaler
├── 成本分析和优化
├── Feature Store
└── A/B Testing 平台

四、成本估算（月度）

最小可用配置

资源	规格	数量	月费用 (CNY)
ACK Pro 管理费	-	1	600
CPU 节点 (c7.2xlarge)	8C16G	3	3,000
GPU 推理节点 (T4)	4C15G+T4	2	6,000
GPU 训练 (按需)	A100	按时	~30/h
RDS PostgreSQL	2C8G	1	800
Redis	1G 标准版	1	200
CPFS 智算版	已有	-	(已包含)
OSS	5TB	1	500
ESSD 云盘	2TB/机已有	-	(已包含)
ALB	基础版	1	200
NAT 网关	小型	1	200
ACR 企业版	基础版	1	500
固定月成本			~12,400
+ 训练 GPU 按需	A100 30h/周		~4,000/月

估算总结

初创期月度支出范围:
├── 最低配置: ~15,000 CNY/月
├── 常规使用: ~25,000 CNY/月
└── 重度训练: ~50,000+ CNY/月

关键省钱策略:
├── 训练用 Spot 实例（省 50-70%）
├── 推理用 cGPU 共享（1 卡当 2-4 用）
├── 非核心组件部署在 ECI 虚拟节点
└── 非工作时间自动缩容训练节点

五、GitLab 推广行动计划

既然已经自建了 GitLab 但未推广，建议：

方案 A：推广 GitLab（数据自主可控）

Week 1: 基础完善
├── 升级到最新 GitLab 稳定版
├── 配置 LDAP/SSO 统一登录
├── 配置自动备份（每日 → NAS/OSS）
├── 创建组织结构和项目模板
└── 编写使用规范文档

Week 2: CI/CD 配置
├── 部署 GitLab Runner（在 ACK 中）
├── 编写通用 CI 模板 (.gitlab-ci.yml)
│   ├── Python 项目模板
│   ├── Node.js 项目模板
│   └── 训练镜像构建模板
└── 集成 ACR 推送

Week 3: 团队培训和迁移
├── 组织 1 小时 GitLab 使用培训
├── 逐项目迁移代码
│   ├── 先迁移 1 个试点项目
│   ├── 验证 CI/CD 流程
│   └── 全量迁移
└── 配置 ArgoCD 连接 GitLab

Week 4: 规范落地
├── 配置分支保护策略
│   ├── main: 只能通过 MR 合并
│   ├── 至少 1 人 Approve
│   └── CI 必须通过
├── 配置 Webhook → 飞书/钉钉通知
└── 定期检查和维护计划

方案 B：迁移到 GitHub（省运维精力）

Week 1: 创建 GitHub Organization
├── 创建 org (如 robotics-ai)
├── 配置 Team 权限
├── 添加团队成员
└── 配置 SSO (如果有)

Week 2: 代码迁移
├── git remote add github <url>
├── git push github --all
├── 验证代码完整性
└── 配置分支保护

Week 3: CI/CD 迁移
├── 编写 GitHub Actions workflows
├── 配置 Secrets (ACR 密码等)
├── 集成 ArgoCD
└── 验证完整流程

Week 4: 废弃旧 GitLab
├── 所有项目确认迁移完成
├── GitLab 设为只读归档
├── 保留 3 个月备查
└── 最终关闭

六、开发者代码存放与工作流

代码在哪里？

┌──────────────────────────────────────────────────────────────────────┐
│                     代码的三个"家"                                     │
│                                                                      │
│  ┌─────────────────────┐                                             │
│  │  1. 开发者本机        │  ← 日常编码（IDE: VSCode/PyCharm/Cursor）  │
│  │     ~/projects/      │     本地运行、调试、写测试                   │
│  │     ├── robotics-api/ │     git clone 从远端仓库拉取               │
│  │     ├── training/     │                                           │
│  │     └── ...           │                                           │
│  └──────────┬────────────┘                                           │
│             │ git push                                               │
│             ▼                                                        │
│  ┌─────────────────────┐                                             │
│  │  2. Git 远端仓库     │  ← 代码的"唯一真相源" (Single Source of Truth)│
│  │     GitLab / GitHub  │     所有人的代码最终汇聚于此                 │
│  │     ├── main 分支    │     CI/CD 从这里触发                        │
│  │     ├── feature/*    │     Code Review 在这里进行                  │
│  │     └── hotfix/*     │                                           │
│  └──────────┬────────────┘                                           │
│             │ CI 自动构建                                             │
│             ▼                                                        │
│  ┌─────────────────────┐                                             │
│  │  3. K8s 集群（ACK）   │  ← 代码以 Docker 镜像形式运行              │
│  │     通过镜像部署      │     开发者不直接在集群里改代码               │
│  │     CPFS/ESSD 存数据  │                                           │
│  └──────────────────────┘                                            │
└──────────────────────────────────────────────────────────────────────┘

不同角色的代码工作方式

后端/前端工程师

日常流程:
─────────

  ① 本机 (MacBook/PC)
     └── git clone [email protected]:robotics/robotics-api.git
         ├── src/
         ├── tests/
         └── Dockerfile

  ② 本地开发和测试
     └── docker compose up   (本地跑 API + PG + Redis)
     └── pytest tests/       (运行测试)
     └── 浏览器访问 localhost:8000

  ③ 提交代码
     └── git checkout -b feature/add-new-endpoint
     └── git commit + git push
     └── 在 GitLab/GitHub 上创建 Merge Request / Pull Request

  ④ CI 自动化
     └── 代码推到远端 → CI 自动 Lint/Test/Build/Push 镜像

  ⑤ CD 自动部署
     └── 镜像推到 ACR → ArgoCD 部署到 ACK 集群

代码完全在本机 + Git 仓库，不在集群里。

算法工程师

当前状态（你们的实际情况）

现状: 代码在 CPFS，训练数据在 OSS
──────────────────────────────────

  算法工程师:
  ├── SSH 到 GPU 算力机 / JupyterHub
  ├── 代码写在 CPFS 共享目录
  │   └── /cpfs/user/zhangsan/projects/
  │       ├── train.py
  │       ├── model.py
  │       └── configs/
  └── 训练数据从 OSS 读取
      └── oss://robotics-data/datasets/...

  训练流程:
  ├── 直接在 GPU 机上 python train.py 运行
  ├── 或者通过脚本提交多卡/多机任务
  └── Checkpoint / 模型输出回 CPFS 或 OSS

这种模式的具体工作方式

算法工程师提交训练任务的实际过程:

  ① 在 GPU 机上编辑代码
     └── vim /cpfs/users/zhangsan/train.py  (或 VSCode Remote SSH)

  ② 小规模调试
     └── python /cpfs/users/zhangsan/train.py --debug --epochs=1

  ③ 提交正式训练任务
     └── 训练容器挂载 CPFS，直接运行 CPFS 上的代码:
         command: ["python", "/cpfs/users/zhangsan/train.py", "--epochs=100"]

  ④ 训练数据从 OSS 读取 (通过 ossutil 或 CSI 挂载)

  优点: 改了代码立即生效，无需重新构建镜像
  感觉: 不太正规 ← 你说的就是这个

这种模式的问题

⚠️ 主要风险:
├── 代码没有版本控制 → 改坏了回不去，不知道谁改了什么
├── 多人可能覆盖同一文件 → /cpfs/shared/train.py 被别人改了
├── 无法做 Code Review → 代码质量无保证
├── 环境不一致 → 每人 pip install 的包版本不同
├── 实验不可复现 → 不知道哪个版本代码对应哪次实验结果
├── CPFS 如果故障 → 代码全丢（CPFS 不是 Git，没有历史版本）
└── 代码和运行环境耦合 → 换台机器可能跑不起来

⚠️ 典型事故场景:
├── 张三改了 utils.py 里的数据加载函数，李四的训练直接报错
├── 实验做了 20 个版本，不知道哪个版本出的好结果
├── 新同事入职，环境配了两天还跑不通
└── 线上推理用了"某个版本"的代码，出问题不知道对应哪个

两种训练代码运行模式对比

模式 A（你们现在的）: CPFS 挂载代码，容器直接运行
──────────────────────────────────────────────

  训练 Pod 配置:
  volumes:
    - name: cpfs-code
      mountPath: /cpfs/users/zhangsan/
  command: ["python", "/cpfs/users/zhangsan/train.py"]

  ✅ 优点: 改了文件立即生效，不用等镜像构建
  ❌ 缺点: 不正规，不可复现，有风险


模式 B（业界标准）: 代码打进 Docker 镜像
──────────────────────────────────────

  训练 Pod 配置:
  image: registry/robotics-training/vision-train:20260315-abc1234
  command: ["python", "train.py"]  # 代码在镜像里

  ✅ 优点: 环境一致、可复现、可追溯
  ❌ 缺点: 每次改代码要重建镜像（CI 需要 3-5 分钟）

推荐方案：混合模式（兼顾效率和规范）

不需要一步到位切到纯镜像模式！ 最佳实践是分场景使用两种模式：

混合模式: 探索期用 CPFS 挂载，正式训练用镜像
──────────────────────────────────────────────

  ┌────────────────────────────────────────────────────────┐
  │ 场景 1: 探索 & 调试（继续用 CPFS 挂载代码）             │
  │                                                        │
  │ 适用: 算法还在摸索，频繁改代码                           │
  │                                                        │
  │ 做法:                                                   │
  │ ├── 代码放 CPFS: /cpfs/users/zhangsan/exp-abc/         │
  │ ├── 用通用基础镜像（已装好 PyTorch 等依赖）              │
  │ ├── 容器挂载 CPFS → 直接运行代码                        │
  │ └── 改了代码 → 重新跑就行                               │
  │                                                        │
  │ 要求（最低规范）:                                       │
  │ ├── ★ CPFS 上的代码必须 git init + 定期 push           │
  │ ├── ★ 每次实验记录 git commit hash                     │
  │ └── ★ 个人目录隔离，不互相覆盖                          │
  └────────────────────────────────────────────────────────┘

  ┌────────────────────────────────────────────────────────┐
  │ 场景 2: 正式训练（用镜像模式）                           │
  │                                                        │
  │ 适用: 算法确定了，要跑大规模正式训练                     │
  │                                                        │
  │ 做法:                                                   │
  │ ├── 代码推到 Git → CI 构建训练镜像                      │
  │ ├── 训练配置（超参、数据路径）通过 ConfigMap 传入         │
  │ ├── 镜像 tag + 配置 = 完全可复现                        │
  │ └── 提交 PyTorchJob / Arena                            │
  │                                                        │
  │ 何时触发:                                               │
  │ ├── 要占用 4+ 卡 的大规模训练                           │
  │ ├── 要长时间运行（>24h）的训练                          │
  │ ├── 要出正式模型用于上线                                │
  │ └── 需要给其他人复现的实验                              │
  └────────────────────────────────────────────────────────┘

改进的渐进式路径

阶段 1: 最小改动 — CPFS 上的代码加 Git（本周就做）
──────────────────────────────────────────────

  ★ 不改变任何工作习惯，只加一层 Git

  每个算法工程师在 GPU 机上执行一次:
  ┌──────────────────────────────────────┐
  │ cd /cpfs/users/zhangsan/my-project   │
  │ git init                             │
  │ git remote add origin \              │
  │   git@gitlab:robotics/my-project.git │
  │ echo "__pycache__/" >> .gitignore    │
  │ echo "*.pyc" >> .gitignore           │
  │ echo "wandb/" >> .gitignore          │
  │ echo "checkpoints/" >> .gitignore    │
  │ git add .                            │
  │ git commit -m "init: 初始化项目"      │
  │ git push -u origin main              │
  └──────────────────────────────────────┘

  日常习惯只加一步:
  ├── 每天下班前: git add . && git commit -m "..." && git push
  └── 或者: 每次大改动后 commit

  效果:
  ├── ✅ 工作方式零改变
  ├── ✅ 代码有了版本历史（改坏了能回退）
  ├── ✅ 有了远端备份（CPFS 坏了不丢代码）
  └── ✅ 可以看到谁改了什么


阶段 2: 目录隔离 + 基础镜像标准化（2-3 周内）
────────────────────────────────────────

  CPFS 目录规划:
  /cpfs/
  ├── users/             ← 每人独立目录（互不影响）
  │   ├── zhangsan/
  │   │   ├── vision-train/     ← git repo
  │   │   └── llm-finetune/     ← git repo
  │   └── lisi/
  │       └── rl-policy/        ← git repo
  │
  ├── shared/            ← 公共工具和预训练模型（只读）
  │   ├── pretrained-models/
  │   └── utils/
  │
  ├── datasets/          ← 从 OSS 同步的热数据
  │
  └── outputs/           ← 训练输出（按项目组织）
      └── vision-train/
          ├── exp-001-20260315/
          └── exp-002-20260316/

  基础镜像标准化:
  ├── 统一构建 2-3 个基础镜像（含 PyTorch/TF/常用库）
  ├── 算法工程师不需要自己 pip install
  ├── 用基础镜像 + 挂载 CPFS 代码的方式训练
  └── 有特殊依赖 → 在基础镜像上加一层 Dockerfile

  基础镜像示例:
  ├── robotics-base/pytorch-gpu:2.2.0-cuda12.1
  │   └── 内含: torch, torchvision, numpy, pandas, wandb, ...
  ├── robotics-base/pytorch-gpu:2.2.0-cuda12.1-llm
  │   └── 额外含: transformers, peft, deepspeed, vllm, ...
  └── robotics-base/rl-gpu:latest
      └── 额外含: gym, mujoco, stable-baselines3, ...


阶段 3: 正式训练镜像化 + MLflow 实验追踪（1-2 月）
─────────────────────────────────────────────

  正式训练场景切到镜像模式:
  ① CPFS 上探索调试（保持 CPFS 挂载方式）
  ② 算法确定 → git push 到 GitLab
  ③ CI 自动构建训练镜像 → 推到 ACR
  ④ 用镜像 + 配置文件提交训练任务

  配合 MLflow 记录实验:
  ├── 每次训练自动记录:
  │   ├── 代码版本 (git commit hash)
  │   ├── 镜像 tag (如果用镜像模式)
  │   ├── 超参数 (learning_rate, batch_size, ...)
  │   ├── 训练指标 (loss, accuracy, ...)
  │   └── 模型文件路径 (OSS/CPFS)
  └── 实验可对比、可复现、可追溯

提交训练任务的两种方式（对应两种场景）

yaml

# 方式 1: CPFS 挂载代码（探索调试阶段）
# 使用通用基础镜像 + 挂载 CPFS 上的代码
apiVersion: "kubeflow.org/v1"
kind: PyTorchJob
metadata:
  name: zhangsan-exp-001
  namespace: algo
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          containers:
          - name: pytorch
            image: registry-vpc.cn-hangzhou.aliyuncs.com/robotics-base/pytorch-gpu:2.2.0-cuda12.1
            command:
            - python
            - /cpfs/users/zhangsan/vision-train/train.py  # 代码在 CPFS
            - --config=/cpfs/users/zhangsan/vision-train/configs/exp001.yaml
            - --data-dir=/data/datasets/imagenet
            - --output-dir=/cpfs/outputs/vision-train/exp-001
            volumeMounts:
            - name: cpfs
              mountPath: /cpfs
            - name: oss-data
              mountPath: /data
            resources:
              limits:
                nvidia.com/gpu: "1"
          volumes:
          - name: cpfs
            persistentVolumeClaim:
              claimName: cpfs-general
          - name: oss-data
            persistentVolumeClaim:
              claimName: oss-datasets

yaml

# 方式 2: 镜像内置代码（正式训练阶段）
# 代码打在镜像里，配置通过 ConfigMap 传入
apiVersion: "kubeflow.org/v1"
kind: PyTorchJob
metadata:
  name: vision-train-v2.1-formal
  namespace: algo
spec:
  pytorchReplicaSpecs:
    Master:
      replicas: 1
      template:
        spec:
          containers:
          - name: pytorch
            image: registry-vpc.cn-hangzhou.aliyuncs.com/robotics-training/vision-train:20260315-abc1234
            command:
            - python
            - train.py              # 代码在镜像里
            - --config=/configs/production.yaml
            - --data-dir=/data/datasets/imagenet
            - --output-dir=/cpfs/outputs/vision-train/formal-v2.1
            volumeMounts:
            - name: config
              mountPath: /configs
            - name: cpfs-output
              mountPath: /cpfs/outputs
            - name: oss-data
              mountPath: /data
            resources:
              limits:
                nvidia.com/gpu: "8"
          volumes:
          - name: config
            configMap:
              name: vision-train-config  # 训练超参通过 ConfigMap
          - name: cpfs-output
            persistentVolumeClaim:
              claimName: cpfs-outputs
          - name: oss-data
            persistentVolumeClaim:
              claimName: oss-datasets
    Worker:
      replicas: 3
      # ... 同 Master 配置

总结：不必非此即彼

                           探索阶段              正式训练
                        ────────────          ────────────
代码位置                 CPFS 挂载              Docker 镜像
环境                    基础镜像 + CPFS 代码     专用训练镜像
修改成本                 秒级（改文件即可）       分钟级（重建镜像）
可复现性                 低（需记录 git hash）    高（镜像 tag 固定）
适用场景                 1-2 卡小实验            4+ 卡正式训练
Git 要求                 ★ 必须用 Git            ★ 必须用 Git
规模                    日常 70% 的工作          日常 30% 的工作

核心原则:
├── 不管哪种模式，代码都必须 Git 管理
├── 探索阶段追求效率 → CPFS 挂载没问题
├── 正式训练追求可复现 → 必须用镜像
└── 从 CPFS 挂载 → 镜像的切换应该是平滑的

训练数据在 OSS 的使用方式

训练数据流: OSS → CPFS → GPU 训练
─────────────────────────────────

方式 1: OSS 直接挂载到 Pod（小数据集）
├── 通过 CSI 插件将 OSS Bucket 挂载为目录
├── 优点: 简单，数据始终最新
└── 缺点: 读取速度受网络限制，不适合大规模训练

方式 2: OSS → CPFS 预同步（推荐，大数据集）
├── 提前将 OSS 数据同步到 CPFS
│   └── ossutil sync oss://robotics-data/imagenet/ /cpfs/datasets/imagenet/
├── 训练时直接读 CPFS（高性能）
├── 优点: 训练期间零网络瓶颈
└── 建议: 用 CronJob 定期同步

方式 3: OSS → ESSD 本地缓存（最高性能）
├── 首次从 OSS/CPFS 拷贝到 ESSD
├── 后续训练直接读本地
└── 适合: 反复训练同一数据集

yaml

# 数据同步 CronJob: OSS → CPFS 每日同步
apiVersion: batch/v1
kind: CronJob
metadata:
  name: sync-oss-to-cpfs
  namespace: data
spec:
  schedule: "0 2 * * *"   # 每天凌晨 2 点
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: sync
            image: registry-vpc.cn-hangzhou.aliyuncs.com/robotics-infra/ossutil:latest
            command:
            - sh
            - -c
            - |
              ossutil sync oss://robotics-data/datasets/ /cpfs/datasets/ \
                --delete --include "*.tar" --include "*.tfrecord" \
                --jobs=10 --parallel=5
            volumeMounts:
            - name: cpfs
              mountPath: /cpfs
            env:
            - name: OSS_ACCESS_KEY_ID
              valueFrom:
                secretKeyRef:
                  name: oss-credentials
                  key: access-key-id
            - name: OSS_ACCESS_KEY_SECRET
              valueFrom:
                secretKeyRef:
                  name: oss-credentials
                  key: access-key-secret
          restartPolicy: OnFailure
          volumes:
          - name: cpfs
            persistentVolumeClaim:
              claimName: cpfs-datasets

数据工程师

日常流程:
─────────

  ① 本机开发数据处理脚本
     └── git clone robotics-data-pipeline
     └── 本地用小样本数据测试

  ② 数据存储位置
     ├── 原始数据: OSS (oss://robotics-raw-data/)
     ├── 处理后数据: CPFS (/datasets/processed/)
     └── 临时中间数据: ESSD 本地缓存

  ③ 数据处理任务提交到集群
     └── K8s Job / CronJob 方式运行

代码存放规范

每个开发者的本机
────────────────

~/projects/                           ← 统一的项目根目录
├── robotics-api/                     ← 从 Git clone
│   ├── .git/
│   ├── src/
│   ├── tests/
│   ├── Dockerfile
│   └── .env.local                    ← 本地环境变量（不提交到 Git！）
│
├── robotics-training/
│   ├── .git/
│   ├── src/
│   ├── configs/
│   └── Dockerfile
│
├── robotics-k8s-manifests/           ← K8s 部署配置
│   ├── .git/
│   ├── base/
│   └── overlays/
│
└── robotics-admin-web/
    ├── .git/
    ├── src/
    └── Dockerfile


Git 远端仓库 (GitLab/GitHub)
──────────────────────────

gitlab.robotics.com (或 github.com/robotics-ai)
├── robotics-api           ← 每个服务一个独立仓库
├── robotics-training
├── robotics-llm-server
├── robotics-admin-web
├── robotics-data-pipeline
└── robotics-k8s-manifests ← 部署配置独立仓库

关键原则

原则	说明
代码在 Git 仓库	每个人本机 clone，所有修改通过 Git 提交
绝不在集群里直接改代码	集群里运行的是镜像，不是源代码
JupyterHub 代码要同步到 Git	Notebook 只是临时环境，正式代码必须 push
数据在 CPFS/OSS	代码和数据分离，数据不放 Git
Secret 不放 Git	密码、Token 通过 K8s Secret 或环境变量注入
每个服务独立仓库	微服务架构，各服务独立开发和部署

分支策略

推荐: GitHub Flow（简洁版 Git Flow）
──────────────────────────────────

  main (保护分支)     ← 始终可部署，CI/CD 从这里触发
    │
    ├── feature/add-llm-endpoint     ← 功能开发分支
    │   └── 开发 → 测试 → PR → Review → Merge
    │
    ├── feature/improve-training     ← 另一个功能分支
    │   └── 开发 → 测试 → PR → Review → Merge
    │
    └── hotfix/fix-oom-crash         ← 紧急修复分支
        └── 修复 → PR → 快速 Review → Merge


分支命名规范:
├── feature/xxx      新功能
├── fix/xxx          Bug 修复
├── hotfix/xxx       紧急修复
├── refactor/xxx     重构
└── docs/xxx         文档更新

保护规则:
├── main 分支: 禁止直接 push，只能通过 MR/PR 合并
├── MR/PR 需要至少 1 人 Approve
├── CI 检查必须全部通过
└── 合并后自动删除 feature 分支

七、基础设施即代码（IaC）

所有基础设施都应该用代码管理（Terraform），而非在阿里云控制台手动点击创建：

hcl

# main.tf — 阿里云基础设施定义示例
provider "alicloud" {
  region = "cn-hangzhou"
}

# VPC
resource "alicloud_vpc" "main" {
  vpc_name   = "robotics-vpc"
  cidr_block = "10.0.0.0/8"
}

# ACK 集群
resource "alicloud_cs_managed_kubernetes" "ack" {
  name         = "robotics-ack"
  cluster_spec = "ack.pro.small"
  # ...
}

# RDS PostgreSQL
resource "alicloud_db_instance" "pg" {
  engine           = "PostgreSQL"
  engine_version   = "16.0"
  instance_type    = "pg.x4.medium.2c"
  instance_storage = 50
  # ...
}

# Redis
resource "alicloud_kvstore_instance" "redis" {
  instance_class = "redis.master.small.default"
  engine_version = "7.0"
  # ...
}

建议：初期可以先在控制台创建，但要记录所有创建的资源，中期用 Terraform 管理。

八、总结 — 优先级排序

✅ 已有: ACK, ACR, CPFS 智算版, OSS, ESSD 2TB/机

立刻做 (P0, 1-2 周):
├── 1. NAT 网关（没有的话节点无法访问外网）
├── 2. ALB + Ingress（服务对外暴露）
├── 3. RDS PostgreSQL + Redis（业务数据库）
├── 4. RAM 权限体系（安全基础）
├── 5. SSL 证书（HTTPS）
└── 6. 推广 GitLab 或迁移 GitHub

尽快做 (P0-P1, 3-6 周):
├── 7. CI/CD Pipeline (CI + ArgoCD)
├── 8. Prometheus + Grafana + 告警
├── 9. 日志系统 (Loki 或 SLS)
├── 10. JupyterHub（算法开发环境）
├── 11. Kubeflow Training Operator
└── 12. ESSD 本地缓存策略（加速训练）

后续做 (P1-P2, 7-12 周):
├── 13. MLflow 实验追踪
├── 14. 标注平台
├── 15. KMS + Secret 加密
├── 16. NetworkPolicy
├── 17. Argo Rollouts 灰度发布
└── 18. Terraform IaC

学习完成

恭喜！你已经完成了从 Docker 基础到 ACK 分布式训练的全部学习路径。

→ 回到首页 → 速查手册

12 - AI 机器人公司基础设施全景规划 ​

一、当前状态与差距分析 ​

现有基础设施 ​

完整基础设施全景 ​

二、各层详细规划 ​

2.1 计算层（ACK 集群增强） ​

2.2 存储层现状分析 ​

存储分工建议 ​

ESSD 本地缓存加速策略 ​

2.3 网络层 ​

2.4 数据库层 ​

2.5 CI/CD & 开发工具 ​

GitLab 推广 or 迁移到 GitHub？ ​

必须建设的 CI/CD 组件 ​

2.6 可观测性（监控 + 日志 + 告警） ​

2.7 安全 ​

2.8 AI/ML 平台 ​

三、分阶段建设路线 ​

Phase 1：基础保障（第 1-2 周） ​

Phase 2：CI/CD 建设（第 3-4 周） ​

Phase 3：可观测性（第 5-6 周） ​

Phase 4：AI 平台（第 7-10 周） ​

Phase 5：安全加固（第 11-12 周） ​

Phase 6：进阶优化（第 13+ 周） ​

四、成本估算（月度） ​

最小可用配置 ​

估算总结 ​

五、GitLab 推广行动计划 ​

方案 A：推广 GitLab（数据自主可控） ​

方案 B：迁移到 GitHub（省运维精力） ​

六、开发者代码存放与工作流 ​

代码在哪里？ ​

不同角色的代码工作方式 ​

后端/前端工程师 ​

算法工程师 ​

当前状态（你们的实际情况） ​

这种模式的具体工作方式 ​

这种模式的问题 ​

两种训练代码运行模式对比 ​

推荐方案：混合模式（兼顾效率和规范） ​

改进的渐进式路径 ​

提交训练任务的两种方式（对应两种场景） ​

总结：不必非此即彼 ​

训练数据在 OSS 的使用方式 ​

数据工程师 ​

代码存放规范 ​

关键原则 ​

分支策略 ​

七、基础设施即代码（IaC） ​

八、总结 — 优先级排序 ​

学习完成 ​

12 - AI 机器人公司基础设施全景规划

一、当前状态与差距分析

现有基础设施

完整基础设施全景

二、各层详细规划

2.1 计算层（ACK 集群增强）

2.2 存储层现状分析

存储分工建议

ESSD 本地缓存加速策略

2.3 网络层

2.4 数据库层

2.5 CI/CD & 开发工具

GitLab 推广 or 迁移到 GitHub？

必须建设的 CI/CD 组件

2.6 可观测性（监控 + 日志 + 告警）

2.7 安全

2.8 AI/ML 平台

三、分阶段建设路线

Phase 1：基础保障（第 1-2 周）

Phase 2：CI/CD 建设（第 3-4 周）

Phase 3：可观测性（第 5-6 周）

Phase 4：AI 平台（第 7-10 周）

Phase 5：安全加固（第 11-12 周）

Phase 6：进阶优化（第 13+ 周）

四、成本估算（月度）

最小可用配置

估算总结

五、GitLab 推广行动计划

方案 A：推广 GitLab（数据自主可控）

方案 B：迁移到 GitHub（省运维精力）

六、开发者代码存放与工作流

代码在哪里？

不同角色的代码工作方式

后端/前端工程师

算法工程师

当前状态（你们的实际情况）

这种模式的具体工作方式

这种模式的问题

两种训练代码运行模式对比

推荐方案：混合模式（兼顾效率和规范）

改进的渐进式路径

提交训练任务的两种方式（对应两种场景）

总结：不必非此即彼

训练数据在 OSS 的使用方式

数据工程师

代码存放规范

关键原则

分支策略

七、基础设施即代码（IaC）

八、总结 — 优先级排序

学习完成