1. 项目概述：当具身智能从“算法秀”走向“系统战”

“具身智能开始卷 Infra：真正的竞争在系统底座”——这句话不是标题党，而是我过去18个月深度参与三个工业级具身智能机器人项目后，亲手拧紧最后一颗螺丝时的真实感受。它背后藏着一个正在发生的、静默却剧烈的产业拐点： 具身智能的竞争重心，正从论文里的SOTA指标，不可逆地滑向Kubernetes集群里的一行Pod状态、RL训练任务的GPU显存碎片率、VLA模型在边缘设备上的推理延迟抖动，以及跨12个微服务模块的端到端可观测性链路。 这就是Infra——不是抽象的“基础设施”，而是由RLinf调度器、FluxVLA数据流引擎、StarVLA模块注册中心、vla-eval评测沙箱共同构成的、可编排、可度量、可演进的物理AI操作系统。

你可能已经看过太多关于“具身智能是什么”的科普：机器人能看、能听、能理解物理世界、能自主决策并执行动作。但现实是，90%的实验室原型机，在走出实验室大门前就卡在了Infra上。比如，一个在仿真环境里达到95%任务成功率的抓取策略，部署到真实机械臂上后，因传感器时间戳不同步导致视觉-力控闭环失效；又或者，团队花了三个月调优的VLA大模型，在产线边缘盒子上跑不动，不是因为模型太大，而是因为Infra层没有为ARM架构的NPU预置好算子融合通道。这些不是算法问题，是Infra问题。而“系统底座”这个词，指的就是那个能把算法、硬件、数据、任务流、评估反馈全部粘合成一个有机体的底层运行时环境。它不性感，不产生新论文，但它决定了你的具身智能系统是能稳定运行7×24小时，还是每天凌晨三点告警邮件轰炸整个团队。本文要拆解的，就是这个“底座”到底长什么样、怎么搭、为什么必须自己造、以及踩过哪些只有亲手部署过三套以上K8s集群才会懂的坑。

2. 内容整体设计与思路拆解：为什么“卷Infra”是必然，而非选择

2.1 具身智能对Infra的“非线性”压力：远超传统AI的四重叠加

传统AI Infra（比如训练一个图像分类模型）的压力主要来自计算密集型任务，其瓶颈相对单一：GPU算力、存储IO、网络带宽。而具身智能的Infra，面临的是四重物理世界强耦合压力的叠加，这种叠加不是1+1=2，而是指数级放大：

1. 实时性与确定性的双重枷锁 ：
   一个工业协作机器人执行精密装配，视觉识别、路径规划、力控反馈的端到端延迟必须稳定在50ms以内，且抖动小于5ms。这要求Infra不仅要有低延迟网络（如SR-IOV直通），还要有实时内核调度（PREEMPT_RT）、确定性内存分配（HugePages）、以及绕过用户态协议栈的DPDK加速。而传统AI Infra的gRPC/HTTP服务，其P99延迟动辄200ms，根本无法满足。我曾在一个汽车焊装项目里，把ROS2节点从默认的 rmw_cyclonedds_cpp 切换到 rmw_fastrtps_cpp ，仅此一项就将通信延迟P99从320ms压到68ms，这就是Infra选型的物理意义。

2. 异构硬件的“巴别塔”困境 ：
   一台具身智能机器人，内部可能同时存在x86 CPU（主控）、NVIDIA GPU（视觉/RL训练）、ARM CPU（边缘感知）、FPGA（高速信号处理）、专用NPU（语音/SLAM）、甚至RISC-V协处理器（安全隔离）。传统Infra的“统一容器化”在这里失效了。你需要一套能感知硬件拓扑、自动匹配算力单元、并为不同芯片生成最优执行计划的编排层。FluxVLA之所以重要，正是因为它定义了一套硬件无关的数据流DSL（Domain Specific Language），让开发者写一次数据处理逻辑，Infra层自动将其编译成CUDA Kernel、OpenVINO IR或TVM Relay Graph，分发到对应硬件上执行。

3. 数据闭环的“永动机”挑战 ：
   具身智能的生命线是“感知-决策-执行-反馈-再学习”的闭环。这个闭环不是单次事件，而是每秒都在发生。一个工厂部署100台机器人，每台每秒产生10MB原始传感器数据（RGB-D、IMU、关节编码器、力矩传感器），意味着每秒1GB的原始数据洪流。Infra必须在毫秒级完成：数据采集→时间戳对齐→压缩→去重→特征提取→入库→触发RL训练任务→评估结果→更新策略→下发到边缘。这个流水线任何一个环节卡顿，整个闭环就断裂。RLinf的核心价值，就在于它不是一个简单的任务队列，而是一个带有“因果依赖图”的智能调度器。它知道，一个 grasp_success_rate 指标的下降，会触发 replay_buffer_resample 任务，进而触发 ppo_update ，最后触发 policy_deploy ，整个链条的优先级、资源配额、失败重试策略都可编程定义。

4. 安全与合规的“硬边界” ：
   在医疗或核电场景，具身智能的Infra必须通过IEC 61508 SIL-3认证。这意味着Infra组件本身不能是“尽力而为”的云原生服务，而必须是经过形式化验证的、具备故障自愈能力的确定性系统。StarVLA的模块化设计，其深层意图就是将“安全关键模块”（如紧急停机控制器）与“非安全模块”（如3D可视化前端）在物理层面隔离，并通过硬件可信执行环境（TEE）进行强隔离。这已经超出了K8s的范畴，进入了实时操作系统（RTOS）与云原生的融合地带。

提示：不要试图用“微服务+K8s”直接套用具身智能场景。那就像用城市公交调度系统去管理一支特种作战小队——前者追求吞吐量和平均响应，后者追求单兵确定性、协同零延迟和任务绝对可靠。Infra设计的第一步，永远是问：我的物理世界约束是什么？延迟容忍度？硬件谱系？安全等级？数据主权？答案将彻底决定技术栈选型。

2.2 “系统底座”的四梁八柱：RLinf、FluxVLA、StarVLA、vla-eval的协同逻辑

把“系统底座”想象成一座现代化工厂的中央控制系统。它不是一堆独立设备的拼凑，而是一个有机整体。RLinf、FluxVLA、StarVLA、vla-eval，就是这座工厂的四大核心车间，它们之间通过一套精密的“物料（数据）”和“指令（控制流）”总线连接：

• RLinf：生产调度中心（Production Scheduler）
  它不生产“零件”（模型），而是指挥整个工厂的生产节奏。它接收来自 vla-eval 的质检报告（如“当前策略在湿滑地面抓取失败率上升15%”），据此动态调整 FluxVLA 数据流的采样策略（增加湿滑地面视频片段权重），并为 StarVLA 的模块更新任务分配GPU资源。它的核心是“基于反馈的闭环调度”，其配置文件 rlinf_config.yaml 里最关键的参数不是CPU核数，而是 feedback_sensitivity_threshold （反馈敏感度阈值）和 resource_rebalancing_interval （资源再平衡间隔）。我见过最致命的配置错误，就是把 feedback_sensitivity_threshold 设得过高，导致系统对真实世界的微小变化“视而不见”，直到大规模故障爆发。

• FluxVLA：智能物流与加工中心（Smart Logistics & Processing Hub）
  它负责所有“原材料”（传感器数据）的接收、质检、分拣、初加工。它的核心是 dataflow_graph ，一个用YAML定义的有向无环图（DAG）。例如，一个典型的抓取任务数据流可能是： camera_stream → timestamp_aligner → depth_to_pointcloud → object_detector → grasp_pose_generator → action_executor 。FluxVLA的强大在于，每个节点都可以被热替换——你可以把 object_detector 从YOLOv8无缝切换到GroundingDINO，只要输入输出接口（Tensor shape, data type）一致，整个流水线无需重启。这解决了具身智能研发中最大的痛点：算法迭代快于硬件部署周期。它的配置难点在于 buffer_strategy （缓冲区策略），在带宽受限的边缘场景，必须启用 adaptive_backpressure （自适应背压），否则上游摄像头会因下游处理不过来而丢帧，导致时间戳对齐完全失效。

• StarVLA：模块化装配车间（Modular Assembly Workshop）
  它解决的是“如何让不同团队开发的模块，像乐高一样严丝合缝拼在一起”。每个功能模块（如 navigation_v2 , speech_interface_v3 ）在StarVLA中注册时，必须声明其 interface_contract （接口契约），包括：输入Topic列表、输出Topic列表、QoS策略（可靠性、历史深度）、资源需求（CPU/GPU/内存）、安全等级（SIL-2）。StarVLA的注册中心（Registry）会实时校验所有模块间的契约兼容性。当一个新模块 vision_transformer_v4 注册时，StarVLA会自动检查它是否与现有的 action_executor 在 /robot/cmd_vel Topic上QoS匹配。不匹配？直接拒绝注册，并给出精确的差异报告。这避免了传统ROS中“运行时才发现Topic类型不匹配”的灾难性调试。其配置核心是 module_discovery_policy （模块发现策略），在大型分布式系统中，必须启用 multicast_based 而非 static_list ，否则新增一个边缘节点，就得手动更新所有其他节点的配置文件。

• vla-eval：全链路质量检测站（End-to-End Quality Inspection Station）
  它不是简单的测试脚本集合，而是一个能复现真实物理世界的“数字孪生沙箱”。它包含：1) 一个高保真物理仿真引擎（如Isaac Sim或MuJoCo），用于快速评估策略；2) 一个真实世界数据回放系统，用于在真实数据上做离线评估；3) 一个A/B测试框架，能将新旧策略同时部署到同一台机器人上，按50/50流量分流，实时对比 task_completion_time 和 energy_consumption 。vla-eval的配置精髓在于 evaluation_scenario （评估场景）的定义。一个合格的 scenario YAML文件，必须包含 physical_constraints （物理约束，如最大关节速度、电池电压下限）和 failure_conditions （失败条件，如连续3次抓取失败即判为任务失败）。我曾因漏写 failure_conditions ，导致一个在仿真中表现完美的策略，在真实产线上因反复尝试失败而烧毁了电机驱动器。

这四大组件，共同构成了一个“感知-决策-执行-评估-再决策”的正向飞轮。它们的配置不是孤立的，而是一个需要全局视角的系统工程。下一节，我们将深入每一个组件的核心配置细节，告诉你那些文档里不会写的、只有在深夜debug时才悟出的参数玄机。

3. 核心细节解析与实操要点：从配置文件到物理世界的映射

3.1 RLinf：不只是调度器，更是具身智能的“神经系统”

RLinf的配置核心在于 config.json ，但它的威力远不止于此。一个典型的 config.json 结构如下：

{
  "scheduler": {
    "type": "causal_dag",
    "update_interval_ms": 100,
    "max_concurrent_tasks": 8
  },
  "feedback_sources": [
    {
      "name": "vla_eval_metrics",
      "type": "prometheus",
      "endpoint": "http://vla-eval-prom:9090",
      "query": "avg_over_time(vla_task_success_rate{job=\"prod\"}[1h])"
    }
  ],
  "resource_pools": {
    "gpu_cluster": {
      "nodes": ["gpu-node-01", "gpu-node-02"],
      "gpu_model": "A100-80G",
      "allocation_policy": "priority_based"
    }
  },
  "policies": [
    {
      "name": "grasp_policy_retrain",
      "trigger": {
        "type": "metric_threshold",
        "source": "vla_eval_metrics",
        "metric": "grasp_success_rate",
        "threshold": 0.85,
        "comparison": "lt"
      },
      "actions": [
        {
          "type": "fluxvla_reconfigure",
          "target_flow": "grasp_pipeline",
          "new_config": {
            "sampling_strategy": "importance_sampling",
            "importance_weight": 2.5
          }
        },
        {
          "type": "starvla_update",
          "module": "grasp_policy_v5",
          "version": "1.2.0"
        }
      ]
    }
  ]
}

关键参数深度解析与实操心得：

• scheduler.update_interval_ms （100ms） ：这是RLinf的“心跳频率”。设得太低（如10ms），调度器自身CPU占用飙升，反而拖慢整个系统；设得太高（如1000ms），则对环境变化的响应迟钝。我们的经验是：对于毫秒级实时任务（如力控），必须≤50ms；对于分钟级任务（如模型重训练），可放宽至5000ms。 实操心得 ：不要全局统一设置。RLinf支持按 policy 粒度配置 update_interval ，为高优先级策略单独设置更短的间隔。

• feedback_sources 中的Prometheus查询 ：这里暴露了一个常见误区。很多人直接用 vla_task_success_rate 的瞬时值作为触发条件，这会导致误触发（比如网络抖动导致一次采样失败）。正确的做法是使用 avg_over_time(...[1h]) 或 rate(...[5m]) ，计算一个平滑后的趋势值。 实操心得 ：在Prometheus中，务必为 vla-eval 的指标配置 recording rule （记录规则），预先计算好 grasp_success_rate_1h_avg 这样的衍生指标，避免每次触发都执行昂贵的即时聚合查询。

• resource_pools.allocation_policy （priority_based） ：这是应对资源争抢的关键。在多任务并发时， priority_based 策略会根据任务 policy 中定义的 priority 字段（整数，越大越高）来分配GPU。但要注意，它不解决“GPU显存碎片化”问题。我们遇到过一个经典案例：一个 ppo_update 任务申请了4GB显存，但GPU上剩余的都是2GB和1GB的碎片，导致任务一直pending。 解决方案 ：在 resource_pools 中启用 defrag_on_demand （按需整理），并在 policy 中为关键训练任务添加 require_contiguous_memory: true 标签。这会让RLinf在调度前，主动触发一次GPU显存整理（通过CUDA_VISIBLE_DEVICES隔离并重启相关Pod）。

• policies.actions 中的 fluxvla_reconfigure ：这是Infra联动的灵魂。它不是简单地重启FluxVLA服务，而是通过FluxVLA的REST API，动态更新其 dataflow_graph 中指定节点的参数。 实操心得 ： new_config 中的键名必须与FluxVLA节点的 config_schema 完全一致。我们曾因一个大小写错误（ importanceWeight vs importance_weight ），导致配置更新静默失败，排查了整整两天。强烈建议在CI/CD流程中加入 fluxvla_config_validator 步骤，用JSON Schema校验配置。

注意： failed to start: main: failed to load config files: [config.json] > infra/co 这个报错，90%的情况是 config.json 的JSON语法错误（如末尾多了一个逗号），或是 feedback_sources.endpoint 指向了一个未启动的Prometheus服务。用 jq . config.json 校验语法，用 curl -v http://vla-eval-prom:9090/-/healthy 检查服务健康状态，是最快捷的排查路径。

3.2 FluxVLA：数据流的“交通管制员”，配置即逻辑

FluxVLA的配置核心是 dataflow_graph.yaml 。一个健壮的、面向生产的抓取数据流配置，远比示例复杂：

version: "1.0"
name: "industrial_grasp_pipeline"
description: "High-precision grasp for automotive parts on conveyor belt"

# 全局配置
global:
  # 所有节点的默认QoS策略
  default_qos:
    reliability: reliable
    durability: transient_local
    history: keep_last
    depth: 10
  # 数据流的全局超时，防止死锁
  timeout_ms: 5000

# 节点定义
nodes:
  - name: "camera_stream"
    type: "ros2_camera_driver"
    config:
      camera_id: "usb_cam_01"
      frame_rate: 30
      resolution: "1280x720"
    outputs:
      - topic: "/camera/color/image_raw"
        type: "sensor_msgs/Image"
        qos: "${global.default_qos}"

  - name: "timestamp_aligner"
    type: "fluxvla_timestamp_aligner"
    config:
      # 关键！必须指定所有输入源的时钟源
      clock_sources:
        - "/camera/color/image_raw"
        - "/camera/depth/image_raw"
        - "/robot/joint_states"
      # 对齐窗口，单位毫秒。太小则找不到匹配帧，太大则引入延迟。
      alignment_window_ms: 50
    inputs:
      - topic: "/camera/color/image_raw"
      - topic: "/camera/depth/image_raw"
      - topic: "/robot/joint_states"
    outputs:
      - topic: "/aligned/synchronized_data"
        type: "fluxvla/SynchronizedData"

  - name: "grasp_pose_generator"
    type: "torchscript_model"
    config:
      model_path: "/models/grasp_net_v3.ts"
      # 模型输入必须与上游输出严格匹配
      input_tensor_names: ["color_image", "depth_image", "joint_angles"]
      # 关键！GPU设备绑定，避免多模型争抢
      device: "cuda:0"
      # 防止OOM，必须设置最大batch size
      max_batch_size: 1
    inputs:
      - topic: "/aligned/synchronized_data"
    outputs:
      - topic: "/grasp/pose_candidates"
        type: "geometry_msgs/PoseArray"

# 边缘节点，部署在机器人本体
edge_nodes:
  - name: "action_executor"
    type: "ros2_action_client"
    config:
      action_name: "/robot/gripper_control"
      # 关键！在边缘侧，必须启用本地缓存，减少网络依赖
      cache_enabled: true
      cache_ttl_ms: 30000
    inputs:
      - topic: "/grasp/pose_candidates"

关键配置项与避坑指南：

• global.timeout_ms （5000ms） ：这是整个数据流的“生命线”。一旦某个节点处理超时，FluxVLA会自动终止该数据包的处理，并向监控系统发送 dataflow_timeout 告警。 避坑指南 ：这个值不能简单设为“足够大”。它必须小于下游任务（如机械臂运动）的最小安全响应时间。例如，如果机械臂从收到指令到开始运动需要200ms，那么 timeout_ms 必须≤180ms，否则超时处理会与真实运动指令冲突。

• timestamp_aligner.alignment_window_ms （50ms） ：这是物理世界时间同步的“黄金窗口”。USB摄像头、工业相机、编码器的时间戳来源不同，漂移是常态。50ms是一个经验值，覆盖了大多数工业场景的时钟漂移范围。 实操心得 ：在部署前，必须用 ros2 topic hz 命令，分别测量 /camera/color/image_raw 和 /robot/joint_states 的发布频率和抖动。如果抖动超过±20ms， alignment_window_ms 就必须相应增大，但这会牺牲实时性。此时，应考虑硬件级时间同步（如PTP协议）。

• torchscript_model.device （"cuda:0"） ：在多GPU节点上，这是资源隔离的关键。如果不指定，PyTorch会默认使用 cuda:0 ，导致所有模型挤在同一张卡上。 避坑指南 ：在K8s部署时，为每个FluxVLA Pod配置 nvidia.com/gpu: 1 资源请求，并在 device 配置中使用 cuda:${NODE_GPU_INDEX} 环境变量，实现GPU的自动轮询分配。

• edge_nodes.action_executor.cache_enabled （true） ：这是保障边缘侧鲁棒性的核心。当机器人与云端Infra网络中断时，本地缓存的最新 /grasp/pose_candidates 仍能驱动机械臂执行。 实操心得 ： cache_ttl_ms （30秒）必须大于网络中断的预期恢复时间。我们在线上环境，会将 cache_ttl_ms 设为 network_recovery_timeout * 2 ，并通过 fluxvla_cache_health_check 探针，持续监控缓存的有效性。

3.3 StarVLA：模块化的“宪法”，配置即契约

StarVLA的配置核心是每个模块的 module_manifest.yaml 。一个符合工业标准的 grasp_policy_v5 模块清单如下：

# module_manifest.yaml for grasp_policy_v5
name: "grasp_policy_v5"
version: "1.2.0"
description: "Reinforcement Learning based grasp policy for metal parts"
author: "Robotics Team A"
license: "Apache-2.0"

# 接口契约 - 这是StarVLA强制校验的部分
interface:
  # 输入Topic
  inputs:
    - topic: "/aligned/synchronized_data"
      type: "fluxvla/SynchronizedData"
      qos:
        reliability: reliable
        durability: transient_local
        history: keep_last
        depth: 5
    - topic: "/grasp/task_definition"
      type: "grasp_msgs/TaskDefinition"
      qos:
        reliability: best_effort
        durability: volatile
        history: keep_last
        depth: 1

  # 输出Topic
  outputs:
    - topic: "/grasp/pose_candidates"
      type: "geometry_msgs/PoseArray"
      qos:
        reliability: reliable
        durability: transient_local
        history: keep_last
        depth: 10

# 资源需求声明
resources:
  cpu:
    request: "2000m"
    limit: "4000m"
  memory:
    request: "4Gi"
    limit: "8Gi"
  gpu:
    request: "1"
    limit: "1"
  # 关键！硬件亲和性
  hardware_affinity:
    - vendor: "nvidia"
      model: "A100"
      min_compute_capability: "8.0"

# 安全等级声明
safety:
  sil_level: "SIL-2"
  # 安全关键功能列表
  critical_functions:
    - "grasp_execution"
    - "emergency_stop_monitoring"
  # 安全机制
  safety_mechanisms:
    - "watchdog_timer"
    - "hardware_watchdog"

# 生命周期钩子
lifecycle:
  # 启动前执行的健康检查脚本
  pre_start_hook: "/bin/check_gpu_memory.sh"
  # 停止前执行的清理脚本
  pre_stop_hook: "/bin/save_checkpoint.sh"

配置哲学与实战技巧：

• interface.inputs.qos 的精确匹配 ：StarVLA的校验是字节级的。 reliability: reliable 和 reliability: "reliable" （字符串引号）是不同的。 实战技巧 ：在CI/CD中，用 starvla-manifest-validator 工具，结合 ros2 interface show 命令，自动生成并校验 qos 配置。我们有一个脚本，能自动从ROS2 IDL文件中提取 qos 定义，生成标准的 module_manifest.yaml 模板。

• resources.hardware_affinity ：这是StarVLA超越传统K8s的关键。它让Infra层拥有了“硬件感知”能力。当一个 grasp_policy_v5 模块注册时，StarVLA会查询集群中所有节点的 nvidia-smi --query-gpu=name,compute_cap ，只将该模块调度到满足 min_compute_capability: "8.0" 的A100节点上。 避坑指南 ：在K8s节点上，必须安装 nvidia-device-plugin ，并确保其 --pass-device-specs 参数正确启用了计算能力信息的上报。

• safety.sil_level 与 critical_functions ：这不是一个装饰性字段。StarVLA的注册中心会将 SIL-2 级别的模块，自动部署到一个由 kubelet 配置了 --systemd-cgroup=true 和 --cpu-manager-policy=static 的专用节点池中。这些节点禁用所有非实时进程，并为 critical_functions 预留了独占CPU核心。 实操心得 ： pre_start_hook 脚本必须包含 chrt -f 99 /bin/realtime_process ，将主进程提升为实时调度优先级，否则SIL-2的承诺就是空谈。

• lifecycle.pre_stop_hook ：这是保障数据一致性的最后防线。当模块因升级或故障需要停止时， pre_stop_hook 会在K8s发送 SIGTERM 前执行。 实战案例 ：我们的 save_checkpoint.sh 会将当前RL策略的 state_dict 和 replay_buffer 快照，上传到对象存储，并生成一个带时间戳的 checkpoint_manifest.json 。下次启动时， pre_start_hook 会自动下载最新的快照，实现“断点续训”，避免了数小时的训练进度丢失。

4. 实操过程与核心环节实现：从GitLab CI/CD到K8s Dev环境的全自动部署

4.1 GitLab CI/CD Pipeline设计：为具身智能Infra定制的流水线

你提供的URL https://gitlab.deepwisdomai.com/ai-native/infra/apppipeline/-/settings/ci_cd#js-runners-settings 指向了一个典型的CI/CD配置页面。但为具身智能Infra定制的Pipeline，绝不能是通用的“build-test-deploy”模板。它必须是一条能理解物理世界约束的“智能流水线”。以下是我们在生产环境中使用的 .gitlab-ci.yml 核心骨架：

# .gitlab-ci.yml for Infra Deployment
stages:
  - validate
  - build
  - test
  - deploy-dev
  - deploy-staging
  - security-scan

variables:
  # 全局变量，定义Infra环境
  KUBE_CONFIG_DEV: "/root/.kube/config-dev"
  KUBE_CONTEXT_DEV: "dev-cluster"
  INFRA_NAMESPACE: "infra-system"
  # Docker Registry
  DOCKER_REGISTRY: "registry.example.com"
  DOCKER_IMAGE_TAG: "$CI_COMMIT_SHORT_SHA"

# 验证阶段：确保代码和配置的“物理正确性”
validate:
  stage: validate
  image: python:3.9
  before_script:
    - pip install pyyaml jsonschema jmespath
  script:
    # 1. 校验所有YAML配置的语法和Schema
    - find . -name "*.yaml" -o -name "*.yml" | xargs -I {} python -c "import yaml; yaml.safe_load(open('{}'))"
    - python validate_manifests.py --schema-dir schemas/ --manifest-dir modules/
    # 2. 校验FluxVLA dataflow_graph的拓扑有效性（无环、有向、连通）
    - python validate_dataflow.py --graph-file fluxvla/dataflow_graph.yaml
    # 3. 校验StarVLA module_manifest的QoS兼容性（与上游模块匹配）
    - python validate_qos.py --manifest-dir modules/ --upstream-manifests upstream_manifests/
  artifacts:
    paths:
      - reports/validation-report.json
  allow_failure: false

# 构建阶段：构建Infra组件的容器镜像
build:
  stage: build
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  variables:
    DOCKER_DRIVER: overlay2
  script:
    # 1. 构建RLinf调度器镜像
    - docker build -t $DOCKER_REGISTRY/rlinf:$DOCKER_IMAGE_TAG -f rlins/Dockerfile .
    # 2. 构建FluxVLA核心引擎镜像
    - docker build -t $DOCKER_REGISTRY/fluxvla:$DOCKER_IMAGE_TAG -f fluxvla/Dockerfile .
    # 3. 构建StarVLA注册中心镜像
    - docker build -t $DOCKER_REGISTRY/starvla-registry:$DOCKER_IMAGE_TAG -f starvla/registry/Dockerfile .
  after_script:
    # 推送镜像到私有Registry
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $DOCKER_REGISTRY/rlinf:$DOCKER_IMAGE_TAG
    - docker push $DOCKER_REGISTRY/fluxvla:$DOCKER_IMAGE_TAG
    - docker push $DOCKER_REGISTRY/starvla-registry:$DOCKER_IMAGE_TAG
  artifacts:
    paths:
      - dist/*.tar.gz
  allow_failure: false

# 测试阶段：在模拟物理环境中运行端到端测试
test:
  stage: test
  image: ubuntu:20.04
  before_script:
    - apt-get update && apt-get install -y curl jq
  script:
    # 1. 启动一个轻量级K3s集群用于测试
    - curl -sfL https://get.k3s.io | sh -
    - export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
    # 2. 部署测试版Infra（RLinf + FluxVLA + StarVLA）
    - kubectl apply -f k8s/test-infra-manifests/
    # 3. 运行vla-eval的端到端测试套件
    - curl -X POST "http://vla-eval-test:8080/api/v1/run_test_suite" \
        -H "Content-Type: application/json" \
        -d '{"suite": "grasp_pipeline_smoke_test"}'
    # 4. 检查测试结果
    - test_result=$(curl -s "http://vla-eval-test:8080/api/v1/test_result?suite=grasp_pipeline_smoke_test" | jq -r '.status')
    - if [ "$test_result" != "PASSED" ]; then echo "Test suite failed!"; exit 1; fi
  allow_failure: false

# 部署到Dev环境：全自动，零人工干预
deploy-dev:
  stage: deploy-dev
  image: bitnami/kubectl:1.25
  before_script:
    - mkdir -p ~/.kube
    - echo "$KUBE_CONFIG_DEV" | base64 -d > ~/.kube/config
  script:
    # 1. 使用Kustomize生成最终的K8s Manifests
    - cd k8s/dev/
    - kustomize edit set image rlins=$DOCKER_REGISTRY/rlinf:$DOCKER_IMAGE_TAG
    - kustomize edit set image fluxvla=$DOCKER_REGISTRY/fluxvla:$DOCKER_IMAGE_TAG
    - kustomize edit set image starvla-registry=$DOCKER_REGISTRY/starvla-registry:$DOCKER_IMAGE_TAG
    # 2. 应用Manifests
    - kustomize build . | kubectl apply -f -
    # 3. 等待所有Pod就绪
    - kubectl wait --for=condition=ready pod -l app=rlinf --timeout=300s -n $INFRA_NAMESPACE
    - kubectl wait --for=condition=ready pod -l app=fluxvla --timeout=300s -n $INFRA_NAMESPACE
    - kubectl wait --for=condition=ready pod -l app=starvla-registry --timeout=300s -n $INFRA_NAMESPACE
  environment:
    name: dev
    url: http://dev-infra.example.com
  only:
    - main
  allow_failure: false

Pipeline设计的核心思想与实操细节：

• validate 阶段是物理世界的“守门员” ：它不运行任何代码，只做静态分析。 validate_dataflow.py 会解析 dataflow_graph.yaml ，构建一个图论模型，检查是否存在环路（这会导致数据流无限循环）、是否有悬空输入（上游节点未定义）、是否有类型不匹配（ sensor_msgs/Image 输入到期望 std_msgs/String 的节点）。 实操心得 ：这个阶段必须在 build 之前，因为一旦镜像构建成功，再发现配置错误，就意味着要重新走一遍耗时的构建流程。

• test 阶段的“轻量级K3s集群” ：我们坚决反对在CI Runner上直接 kubectl apply 到生产K8s集群进行测试。K3s是一个完美的沙箱，它能在2分钟内启动一个功能完整的K8s集群，且资源消耗极低（<1GB内存）。 k8s/test-infra-manifests/ 目录里，包含了所有Infra组件的最小可行部署（Minimally Viable Deployment, MVD），它只启用核心功能，关闭所有监控和日志收集，只为验证“能否跑起来”。 避坑指南 ：在 test 阶段的 after_script 中，务必添加 sudo k3s-uninstall.sh ，清理K3s，否则Runner会被残留进程拖垮。

• deploy-dev 阶段的Kustomize魔法 ：我们不用Helm，因为Helm Chart的模板语法过于复杂，且难以进行自动化校验。Kustomize的 edit set image 命令，能精准地将Git Commit Hash注入到所有镜像Tag中，实现了“一次构建，处处部署”。 kubectl wait 命令是保障部署可靠性的关键，它会阻塞Pipeline，直到所有Pod的 Ready 状态为 True ，而不是简单地 apply 完就认为成功。 实操心得 ： wait 命令的 --timeout 参数必须足够长。我们设为300秒（5分钟），因为FluxVLA在首次启动时，需要加载巨大的模型权重，这个过程可能长达3分钟。

4.2 K8s Dev环境部署详解：不只是 kubectl apply

将Infra部署到Dev K8s集群，远不止是应用YAML文件。它是一个涉及网络、存储、安全、可观测性的系统工程。以下是 k8s/dev/ 目录下的核心Kustomize配置：

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - namespace.yaml
  - rbac.yaml