用 RLark 做机器人纳管与跨集群任务调度实战

这篇能做出什么

照着走完，能拿到三样具体的产物：

1. 一份机器人清单：至少一台机器人被纳管进 RLark，控制台或命令行能看到它的在线状态、所在集群、固件与运行时版本、挂载的传感器。

2. 一个可复用的任务模板：把"抓取—放置""采集一段数据""跑一轮推理"这类动作定义成模板，之后每次执行只改参数，不改流程。

3. 一套跨集群调度策略：任务提交后，由 RLark 决定落到边缘集群还是中心集群，并借助预热池把冷启动时间从分钟级压到十几秒量级。

下面所有命令按通用写法给出。RLark 的子命令名和 YAML 字段会随版本演进，动手前用 --help 和官方文档对一遍，比背命令可靠。

前置条件清单

开始之前，确认这几件事已经就绪：

• 一个 RLark 账号，以及对应租户（tenant）或工作空间的写权限；
• 本机装好 rlark CLI，并且能把二进制放进 PATH；
• 至少一个已接入的 Kubernetes 集群（边缘侧或中心侧都可以），RLark 通过它下发工作负载；
• 机器人侧可以跑容器化 Agent，能主动向外发起连接（边缘网络通常没有公网入向，靠反向隧道更稳）；
• 一个容器镜像仓库地址，作为任务镜像的来源；镜像 tag 以你内部仓库的当前约定为准；
• 机器人与集群之间的网络时延、带宽已知，后面打调度分数要用。

第 1 步：先建立对象模型的心智图

RLark 里需要记住四类对象，后面的操作都是围绕它们转：

关键点：Robot 不等于 Cluster。机器人可以"注册在 A 集群、算力跑在 B 集群"，这正是跨集群调度的价值所在。把这两者当成同一个东西，后面策略就会写歪。

第 2 步：登录并确认可见的集群

```bash

登录（按提示完成浏览器授权或粘贴 Token）

rlark login

看当前身份和默认租户

rlark whoami

列出可用集群及其标签

rlark cluster list --show-labels

```

输出里重点看两列：集群的 region / site 标签，以及是否被标记为 edge 或 cloud。调度策略就是靠这些标签做匹配的，标签缺失会导致任务永远 Pending。

第 3 步：纳管第一台机器人（目标 5 分钟内）

纳管本质是两件事：在控制面登记一台机器人，在机器人侧跑起 Agent 并把它认领回去。

先取一个一次性注册令牌：

```bash

rlark robot token create --ttl 15m --scope register

```

把输出里的令牌复制到机器人上，然后启动 Agent。多数场景用容器方式最省事：

```bash

在机器人侧执行；镜像地址与 tag 以官方文档当前版本为准

docker run -d --name rlark-agent --restart unless-stopped \

-e RLARK_TOKEN="<上一步的令牌>" \

-e RLARK_ENDPOINT="<控制面地址>" \

-e RLARK_NAMESPACE="<租户命名空间>" \

-v /dev:/dev \

-v /var/run/docker.sock:/var/run/docker.sock \

<registry>/rlark-agent:<tag>

```

几秒后回到控制侧确认：

```bash

rlark robot list

rlark robot describe arm-001

```

如果列表里出现了机器人和 Ready 状态，纳管就完成了。这一步通常几分钟内能搞定，剩下的时间基本花在排查网络上。

接着给机器人打标签，标签决定了后面任务能不能选中它：

```yaml

robot-labels.yaml

apiVersion: rlark.io/v1

kind: Robot

metadata:

name: arm-001

labels:

site: lab-a

model: arm-x

tier: production

spec:

cluster: edge-lab-a

capabilities:

• camera
• gripper
• force-torque

```

```bash

rlark apply -f robot-labels.yaml

```

第 4 步：写第一个任务模板

模板要写清三件事：跑在哪种机器人上、跑什么镜像、产物放哪。

```yaml

task-template.yaml

apiVersion: rlark.io/v1

kind: TaskTemplate

metadata:

name: pick-and-place

spec:

robotSelector:

matchLabels:

model: arm-x

site: lab-a

runtime:

image: <registry>/pick-and-place:<tag> # tag 以内部仓库当前约定为准

command: ["python", "run.py"]

env:

• name: TARGET_COUNT

value: "20"

resources:

cpu: "2"

memory: "4Gi"

artifacts:

path: /out

uploadTo: <你的对象存储前缀>

timeout: 30m

```

```bash

rlark apply -f task-template.yaml

rlark template list

```

robotSelector 里的标签一定要和上一步打的标签对得上。这是新手最容易踩的坑：标签写错一个字母，任务不报错，只是排队。

第 5 步：单集群跑通一次

先用最保守的方式验证链路：锁定某个集群，不启用跨集群调度。

```bash

rlark task submit pick-and-place \

--param TARGET_COUNT=5 \

--cluster edge-lab-a \

--follow

```

--follow 会持续打印日志。看到任务进入 Succeeded 且产物出现在对象存储里，说明"模板 → 调度 → 机器人 → 产物"这条链路是通的。

查历史：

```bash

rlark task list --template pick-and-place

rlark task logs <run-id> --tail 200

```

第 6 步：配置跨集群调度策略

链路通了再上策略。跨集群调度的核心是一个带权重的打分函数：让每次任务落到"网络近、有算力、有预热"的集群上。

```yaml

schedule-policy.yaml

apiVersion: rlark.io/v1

kind: SchedulePolicy

metadata:

name: nearest-with-capacity

spec:

strategy: scoreBased

scores:

• type: RobotNetworkLatency # 机器人与目标集群的时延

weight: 50

• type: FreeAccelerator # 集群空闲 GPU/加速器

weight: 30

• type: WarmPoolHit # 是否命中预热池

weight: 20

fallbackClusters:

• edge-lab-a
• cloud-cn-01

constraints:

• type: RequireLabel

key: tier

operator: In

values: ["production"]

```

```bash

rlark policy apply -f schedule-policy.yaml

```

三个权重的含义很直白：时延权重给高，任务响应才跟得上；算力权重给中，避免把任务扔到已经满载的集群；预热命中的权重给低，但它是决定"几秒还是几十秒"的那一项。

fallbackClusters 是保底。边缘集群掉线时，任务会被推到中心集群，代价是时延变高，但不会卡住。

第 7 步：把启动压到 10 秒级

冷启动慢，绝大多数时候慢在两个地方：镜像拉取，和运行时初始化。对应两个动作。

一是预热池。 提前把容器起好，挂着不干活，任务来了直接切进去：

```yaml

warm-pool.yaml

apiVersion: rlark.io/v1

kind: WarmPool

metadata:

name: pick-and-place-warm

spec:

templateRef: pick-and-place

clusters:

• edge-lab-a

minReplicas: 2

maxReplicas: 6

idleTimeout: 10m

```

```bash

rlark warmpool apply -f warm-pool.yaml

rlark warmpool status pick-and-place-warm

```

minReplicas 别一味加大：预热实例是占资源的，按任务到达频率估一个够用的值就好。idleTimeout 控制空转多久回收。

二是把重的东西前置到镜像构建阶段。 模型权重、依赖包、CUDA 运行时能烘进镜像就烘进去，不要留在启动脚本里下载。启动脚本里只留"读参数、连设备、跑循环"。

做完这两件，命中预热的任务从提交到开始执行，通常能进到十几秒这个量级。具体数字随集群规模、网络、镜像大小而变，压测一遍拿到自己环境的真实值更有意义。

第 8 步：看住它

上线之后要有观测，否则出了问题只能靠猜：

```bash

任务队列里有没有堆积

rlark task list --state Pending

预热池命中率

rlark warmpool status pick-and-place-warm --show-metrics

机器人在线率

rlark robot list --state Offline

```

再配两条告警就够了：Pending 任务数持续高于阈值（说明算力不够或标签错配），以及机器人离线数超过阈值（通常意味着现场网络或供电出问题）。

常见坑与排错

机器人一直 Offline。 先确认 Agent 容器活着，再看它能不能向外连到控制面。边缘网络大多没有入向端口，如果 Agent 配置里要求控制面主动连机器人，方向就反了，改成长连接或反向隧道。

任务永远 Pending，不报错。 九成是 robotSelector 的标签没匹配上。用 rlark robot describe <name> --show-labels 和模板里的 selector 逐字对一遍。另一个原因是 constraints 里的租户标签没打到集群上。

跨集群调度没有生效。 检查策略是否真的绑到了这个模板或命名空间；策略存在但没绑定，等于没写。也确认集群的 region / site 标签齐全，缺标签时打分函数算不出分数，会直接走 fallback。

启动时间忽快忽慢。 命中预热和没命中，差的是数量级。看 WarmPoolHit 这个信号在当前 run 上是正是负，就知道是不是预热池被打空了。

镜像拉取失败。 边缘节点不一定能访问中心镜像仓库。要么在边缘侧做镜像同步，要么把 imagePullSecrets 配到对应命名空间。这一步在离线现场尤其容易漏。

时间戳对不上导致日志乱序。 机器人、边缘节点、控制面三处时钟都要同步。做时序分析前先确认 NTP 状态。

产物上传失败但任务显示成功。 把产物上传做成"失败即任务失败"，否则数据丢了没人知道。

下一步建议

跑通上面这条最小链路之后，可以按这个顺序往下推：

1. 把模板参数化。同一套流程通过参数覆盖不同工位、不同物料，模板数量就能压下来。

2. 接入 CI。镜像构建完自动 rlark apply 更新模板，避免手工改 tag 改出错。

3. 做灰度。新版本先投一台机器人，观察一轮再放量，回滚只改模板里的镜像 tag。

4. 补混沌演练。主动断掉一个边缘集群，验证 fallback 和预热池重建是否符合预期。

5. 量化容量。用预热池命中率和 Pending 队列长度反推需要多少边缘算力，比拍脑袋扩机器靠谱。

RLark 的字段名、子命令和默认值会随版本调整，落地前把官方文档当前版本过一遍，尤其是调度策略和预热池这两块——它们直接决定启动时间是十秒还是十秒的两三倍。