Kubernetes agentic 调度实战：ax 编排层设计与 workspace 故障排查

1. 从"ax"这个标题说起：一个被低估的调度命题

第一次看到"ax"这个标题，很多人会一头雾水——两个字母，没有上下文，没有正文，没有关键词。但把热搜词摊开来看，线索就非常清楚了：ax调度、agentic、orchestrator、kubernetes、workspace、karmada、device plugin。这几个词拼在一起，指向的是一个非常具体的技术命题：在 Kubernetes 之上，为 agentic 工作负载构建一套调度与编排层。

我先把结论摆在前面：ax在我的理解里，是一个面向 agentic 场景的调度器/编排器的代号。它要解决的问题不是"怎么把 Pod 跑起来"——那是 kube-scheduler 的活；它要解决的是"当工作负载从无状态的 HTTP 服务，变成有状态、有工具调用、有长时任务、有资源亲和性的 agent 时，调度该怎么做"。

为什么这个命题值得单独拎出来讲？因为过去十年我们写的调度逻辑，几乎都是为"短生命周期、无状态、可随意漂移"的服务设计的。Deployment 滚动更新、HPA 按 CPU 扩容、Pod 挂了就重建——这套范式在 agentic 场景下会大面积失效。一个 agent 可能持有对话上下文、持有工具调用的中间状态、持有对某个 GPU 或某个外部资源的独占锁。你把它当无状态 Pod 调度，它就会在漂移中丢状态；你把它当有状态服务调度，又会被 StatefulSet 那套固定序号的模型绑死。

所以这篇东西我想聊的不是"ax 是什么"这种定义题，而是如果你要自己动手搭一套 agentic 调度层，哪些坑是绕不过去的。热搜词里那些看起来零散的东西——Karmada 毕业、device plugin、workspace 卡在 loading packages、未授权访问漏洞——其实都是同一条链路上的不同断面。我会把它们串起来讲。

适合谁看：已经会用 Kubernetes 跑服务，但准备把 agent 类负载搬上去的工程师；正在做多集群调度、想做统一编排层的平台同学；以及被setting up workspace: loading packages...卡住过、想搞清楚背后到底发生了什么的倒霉蛋（我也卡过）。

2. agentic 负载到底和普通微服务差在哪

2.1 生命周期：从"秒级"到"分钟到小时级"

普通微服务的 Pod 生命周期通常是秒级到分钟级。一个请求进来，处理完就结束，Pod 本身可以活很久但单个任务很短。调度器关心的是"把 Pod 放到哪个节点"，放完之后基本就不管了。

agentic 负载完全不是这个节奏。一个 agent 任务可能包含：规划阶段（调 LLM 做任务分解）、工具调用阶段（调外部 API、查数据库、跑代码）、反思阶段（根据结果调整计划）、再执行。整个链路跑下来几分钟到几小时都正常。这意味着：

• 调度决策的时效性要求变了。你不可能等任务跑完再重新调度，必须在任务开始前就把资源预留好，中途还要能感知任务是否卡死。
• 抢占（preemption）的代价变高了。普通 Pod 被抢占，重启一下就好；agent 被抢占，可能丢掉半小时的推理上下文。
• "调度"和"运行时"的边界模糊了。传统调度器管放置，运行时管执行；agentic 场景下，调度器需要知道运行时的状态才能做决策。

我在实际项目里踩过的一个坑：早期我们把 agent 当成普通 Job 提交，用restartPolicy: OnFailure。结果一个跑了 40 分钟的 agent 因为节点资源紧张被驱逐，重启后从零开始，前面 40 分钟的 token 全白烧了。后来改成 checkpoint + 状态外置才缓解，但这是运行时层面的补救，调度层面其实应该更早介入。

2.2 资源画像：不只是 CPU 和内存

普通服务调度看 CPU/内存 request 和 limit 就够了。agentic 负载的资源画像要复杂得多：

这张表里最容易被忽略的是外部 API 配额。一个 agent 集群里如果有 100 个 agent 同时调同一个 LLM 接口，配额瞬间打满，所有 agent 一起超时。这时候调度器如果只按 CPU 调度，会把 100 个 agent 全塞到同一批节点上，加剧问题。正确的做法是把"配额"当成一种可调度资源，在调度层做限流和分散。

2.3 状态：调度器必须"看见"的东西

这是 agentic 调度和传统调度最大的分水岭。传统调度器假设 Pod 是无状态的，所以可以随意漂移。agent 是有状态的，状态可能存在于：

• 内存中：对话历史、推理中间结果
• 本地磁盘：临时文件、代码执行产物
• 外部存储：向量库、对象存储、数据库
• 外部会话：和某个工具服务建立的连接

调度器要做的决策是：这个 agent 能不能漂移？漂移的代价是什么？如果状态全在外部存储，漂移代价低，可以当无状态调度；如果状态在内存，漂移等于重启，那就必须做亲和性调度，把它钉在特定节点上。

我在设计时用了一个简单的判断规则：状态外置程度 = 可漂移程度。状态外置得越彻底，调度自由度越高。反过来，如果团队不愿意改代码做状态外置，那调度层就得背这个锅，用 nodeAffinity 和 podAffinity 硬钉。

3. 调度层设计：ax 需要回答的四个问题

3.1 问题一：调度粒度是 Pod、Task 还是 Session

这是最根本的设计决策。三种粒度对应三种完全不同的架构：

Pod 粒度：沿用 Kubernetes 原生模型，一个 agent 任务 = 一个 Pod。优点是生态兼容好，kube-scheduler 直接能用；缺点是 Pod 生命周期和任务生命周期强绑定，任务中途需要扩容/缩容很别扭。

Task 粒度：引入一个中间层 Task 对象，一个 Task 可能对应多个 Pod（比如规划 Pod + 执行 Pod）。优点是灵活，能表达复杂工作流；缺点是要自己实现 Task 到 Pod 的映射和生命周期管理，复杂度陡增。

Session 粒度：以用户会话为单位调度，一个 Session 包含多个 Task。优点是贴合 agent 的实际使用模式（用户和 agent 的多轮交互）；缺点是和 Kubernetes 的模型差距最大，几乎要重写调度逻辑。

我的建议是：从 Pod 粒度起步，但预留 Task 抽象。具体做法是给 Pod 打上一组 label 来标识它属于哪个 Task、哪个 Session，调度策略先按 Pod 做，但决策逻辑里预留 Task 级别的聚合视图。这样将来要升级到 Task 粒度时，不用推倒重来。

3.2 问题二：亲和性怎么表达

agentic 场景的亲和性需求比普通服务复杂得多。我整理了几类常见的：

• 工具亲和：agent 需要调用某个本地工具（比如一个特定的代码执行沙箱），必须调度到装了该工具的节点。
• 数据亲和：agent 需要读取本地缓存的数据集，调度到有该数据副本的节点能省大量网络开销。
• 会话亲和：同一会话的多个 agent 任务尽量调度到同一节点，减少跨节点通信。
• 反亲和：同一批 agent 不要全挤在一个节点，避免单点故障和配额争抢。

Kubernetes 原生的 nodeAffinity/podAffinity 能表达一部分，但表达力有限。比如"工具亲和"需要节点上报自己装了哪些工具，这就要用到device plugin或者自定义的 node label 机制。热搜词里出现kubernetes device plugin不是偶然——device plugin 是 Kubernetes 官方提供的扩展机制，让节点能上报自定义资源（GPU 是最典型的例子，但理论上任何资源都能上报）。

如果你要把"工具就绪"当成一种可调度资源，有两条路：

1. 用 device plugin 上报：把工具当成一种"设备"，节点上装了工具就上报，调度器按 device 请求调度。优点是原生支持，缺点是 device plugin 通常用于硬件类资源，用来表达软件工具有点重。
2. 用 node label + 自定义调度器：节点打 label 标识工具，调度器读 label 做决策。优点是轻量灵活，缺点是要自己写调度逻辑。

我倾向于第二种，因为工具的种类和版本变化频繁，用 label 更容易维护。但如果你已经在用 device plugin 管 GPU，顺手把工具也纳入同一套体系，运维上会更统一。

3.3 问题三：多集群怎么统一调度

热搜词里karmada正式毕业是个重要信号。Karmada 是 CNCF 的多集群管理项目，它的"毕业"意味着多集群调度这件事从"各家自己造轮子"进入了"有标准方案"的阶段。

agentic 负载为什么需要多集群？几个现实原因：

• 配额隔离：不同团队的 agent 配额需要隔离，物理集群隔离比 namespace 隔离更彻底。
• 地域分布：agent 调用的外部服务可能在不同地域，就近调度能降延迟。
• 故障域隔离：单集群故障不应该让所有 agent 停摆。
• 成本优化：不同集群的机器成本不同，可以把非紧急任务调度到便宜集群。

Karmada 提供的核心能力是PropagationPolicy和OverridePolicy：前者决定工作负载分发到哪些集群，后者决定分发到不同集群时做哪些差异化配置。对于 agentic 场景，我通常会配三层策略：

1. 全局策略：所有 agent 任务默认分发到所有可用集群。
2. 团队策略：按团队 label 分发到该团队专属集群。
3. 任务策略：高优先级任务分发到高性能集群，低优先级分发到成本优化集群。

这里有个坑：Karmada 的调度决策和成员集群的 kube-scheduler 是两级调度。Karmada 决定"去哪个集群"，成员集群的 scheduler 决定"去哪个节点"。如果两级调度不协调，会出现"Karmada 觉得某集群有资源，但成员集群实际调度不进去"的情况。解决办法是在 Karmada 层做资源预估时留足余量，或者用 Karmada 的Reschedule机制做二次修正。

3.4 问题四：调度决策要不要可解释

这个问题看起来是"锦上添花"，实际上是"雪中送炭"。agentic 负载的调度决策往往涉及多维权衡（资源、亲和、配额、成本），一旦出问题，没有可解释性根本没法排查。

我要求调度器输出的每条决策都带一个decision trace，至少包含：

• 候选节点列表和每个节点的打分
• 最终选择的节点和选择理由
• 被过滤掉的节点和过滤原因
• 决策时依赖的关键指标快照

这个 trace 不需要实时展示，但必须落盘。出问题时能回溯"当时为什么选了这个节点"，比事后猜要高效得多。我用的是一个简单的 JSON 结构，每次调度决策写一行，配合日志系统做检索。

4. workspace 初始化卡住：一个高频故障的完整排查链路

4.1 现象：loading packages 卡住不动

热搜词里setting up workspace: loading packages...卡住和couldn't complete the workspace policy acknowledgment这两个，我太熟了。前者是 workspace 初始化时卡在包加载阶段，后者是策略确认失败。这两个现象经常一起出现，因为 workspace 初始化本身就包含"加载依赖"和"确认策略"两个阶段。

先说loading packages...卡住。这个现象的本质是：workspace 初始化流程在等待某个外部依赖，但依赖没有超时机制，导致无限等待。

常见的卡住原因，按我遇到的频率排序：

1. 包源不可达：workspace 初始化要从某个包仓库拉依赖，网络不通或仓库响应慢，卡在 TCP 连接或 TLS 握手。
2. 依赖解析死锁：包管理器在解析依赖树时遇到循环依赖或版本冲突，陷入无限回溯。
3. 锁竞争：多个 workspace 同时初始化，争抢同一个包缓存目录的锁。
4. 磁盘满：包下载到一半磁盘满了，写入阻塞。
5. DNS 解析慢：包源域名解析超时，每次重试都要等 DNS。

4.2 排查链路：从外到内逐层定位

我排查这类问题的顺序是固定的，从最外层开始，逐层往里剥：

第一步：确认是网络问题还是本地问题。

# 在 workspace 所在节点上，直接测包源连通性 curl -v --max-time 10 https://your-package-registry.example.com/health # 看 DNS 解析耗时 dig your-package-registry.example.com | grep "Query time" # 看是否有大量 TIME_WAIT 连接 ss -s

如果 curl 超时或 DNS 解析超过 1 秒，基本可以定位到网络层。这时候要看节点的网络策略、出口代理配置、DNS 配置。

第二步：确认是包管理器问题还是 workspace 框架问题。

# 看包管理器进程是否在跑，CPU 占用如何 ps aux | grep -E "npm|pip|go mod|yarn" # 如果是 npm，看它的日志 tail -f ~/.npm/_logs/*.log # 如果是 pip，加 -v 重跑看详细输出 pip install -v your-package

如果包管理器进程 CPU 占用高但没进展，多半是依赖解析死锁。如果进程在但 CPU 占用低，多半是在等网络或等锁。

第三步：确认是单点问题还是普遍问题。

# 看同一节点上其他 workspace 是否也卡住 ls -la /var/lib/workspace/*/status # 看其他节点是否正常 kubectl get pods -o wide | grep workspace

如果只有个别 workspace 卡住，是单点问题（可能是那个 workspace 的依赖特殊）；如果全部卡住，是共性问题（网络、包源、节点资源）。

4.3 修复方案：超时、重试、降级三件套

定位到原因后，修复方案基本围绕三件事：

超时：给所有外部依赖调用加超时。包管理器一般有超时配置，比如 npm 的fetch-timeout、pip 的--timeout。workspace 框架层面也要加总超时，超过就报错退出，不要无限等。

重试：网络类问题加指数退避重试。但要注意重试次数上限，避免重试本身变成新的卡点。

降级：如果主包源不可达，切到备用源；如果依赖解析失败，用锁定的版本文件（package-lock.json、requirements.txt）跳过解析。

我实际用的一套配置，供参考：

# npm 场景 npm config set fetch-timeout 30000 npm config set fetch-retries 3 npm config set fetch-retry-mintimeout 1000 npm config set fetch-retry-maxtimeout 10000 # pip 场景 pip install --timeout 30 --retries 3 -r requirements.txt # workspace 框架层面，设置总超时 export WORKSPACE_INIT_TIMEOUT=300

注意：超时时间不要设太短。我见过有人把 fetch-timeout 设成 5 秒，结果正常的大包下载也被中断，反而制造了更多失败。30 秒是个比较稳的起点。

4.4 策略确认失败：另一个高频坑

couldn't complete the workspace policy acknowledgment这个报错，本质是 workspace 初始化时要求确认一组策略（可能是安全策略、资源策略、合规策略），但确认流程失败了。

失败原因通常是：

• 策略服务不可达：确认请求发不出去。
• 策略版本不匹配：workspace 期望的策略版本和策略服务提供的不一致。
• 确认超时：策略服务响应慢，确认请求超时。
• 权限不足：workspace 的身份没有确认策略的权限。

排查方法和上面类似，先测连通性，再看日志，最后看权限。修复上，我建议把策略确认做成幂等 + 可重试的操作，并且允许在策略服务短暂不可用时用缓存的策略继续初始化（前提是缓存策略没过期）。

5. 安全边界：未授权访问漏洞为什么总在调度层出现

5.1 调度层的攻击面比你想的大

热搜词里kubernetes 未授权访问漏洞是个老生常谈但一直有人中招的问题。为什么调度层容易出这类问题？因为调度层天然要访问大量资源：

• 要读节点信息（才能调度）
• 要读 Pod 信息（才能做亲和性）
• 要写 Pod 的调度结果（binding）
• 可能要读 Secret（才能注入凭证）

这些权限如果配置不当，就是一个巨大的攻击面。最常见的错误是给调度器组件配了 cluster-admin 权限，理由是"方便"。一旦这个组件被攻破，整个集群就沦陷了。

5.2 最小权限怎么落地

我的做法是给调度层单独建 ServiceAccount，然后用 RBAC 精确授权。一个典型的调度器需要的权限大概是：

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: ax-scheduler-role rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"] - apiGroups: [""] resources: ["pods/binding"] verbs: ["create"] - apiGroups: [""] resources: ["events"] verbs: ["create", "patch"]

注意这里没有secrets权限，没有delete权限，没有*通配符。调度器只需要读 Pod 和 Node、写 binding 和 event，其他都不需要。

提示：pods/binding这个子资源是调度器专用的，普通组件不需要。如果你看到某个组件有pods/binding的 create 权限，要确认它是不是真的调度器。

5.3 agentic 场景的特殊风险

agentic 负载给安全边界带来了新挑战：

• agent 会执行代码：如果 agent 能跑任意代码，它就可能利用调度层的权限做提权。
• agent 会调外部服务：如果 agent 能访问外部网络，它就可能把集群信息外传。
• agent 的状态可能含敏感数据：对话历史、工具调用结果可能包含敏感信息，调度时要考虑数据隔离。

我的建议是给 agent 负载做三层隔离：

1. 网络隔离：用 NetworkPolicy 限制 agent 的出入口，只允许访问必要的服务。
2. 权限隔离：agent 的 ServiceAccount 权限要极小，最好只读自己 namespace 的资源。
3. 运行时隔离：用 gVisor、Kata Containers 之类的沙箱运行时跑 agent 代码，防止逃逸。

这三层里，网络隔离最容易做也最容易被忽略。我见过不少集群，agent 能访问整个集群网络，包括 etcd 的端口。这是非常危险的。

6. 从单集群到多集群：Karmada 落地时的真实取舍

6.1 什么时候该上多集群

不是所有 agentic 场景都需要多集群。我的判断标准是三条，满足任意两条才考虑上：

• 单集群资源上限逼近：单集群撑不住负载增长，且垂直扩容成本过高。
• 有明确的隔离需求：团队隔离、环境隔离、合规隔离，namespace 隔离不够用。
• 有地域分布需求：用户或依赖服务分布在不同地域，单集群延迟不可接受。

如果只是"想试试多集群"，我建议先别上。多集群带来的复杂度是实打实的：网络打通、镜像同步、配置分发、监控聚合、故障排查，每一项都是工作量。

6.2 Karmada 的核心概念怎么映射到 agentic 场景

Karmada 的几个核心概念，映射到 agentic 场景是这样的：

实际配置时，我通常会给 agent 任务打三类 label：team、priority、region，然后 PropagationPolicy 按这三类 label 做分发。比如高优先级任务只去高性能集群，低优先级任务去成本优化集群。

6.3 多集群调度的两个真实坑

坑一：镜像不同步导致调度失败。Karmada 把任务分发到成员集群后，成员集群要拉镜像。如果镜像只在部分集群有，分发到没有镜像的集群就会 ImagePullBackOff。解决办法是用统一的镜像仓库，或者用 Karmada 的 OverridePolicy 给不同集群配不同的镜像地址。

坑二：资源预估不准导致调度震荡。Karmada 层做资源预估时，看到的是成员集群上报的可用资源。但成员集群的实际可用资源可能因为本地调度而变化。如果预估不准，会出现任务在集群间反复漂移。解决办法是给 Karmada 的资源预估留 buffer，或者用 Reschedule 机制做修正。

7. 我踩过的几个具体坑和对应的解法

7.1 坑一：把 agent 当 Job 提交，结果状态全丢

前面提过，早期我们把 agent 当 Job 提交，用restartPolicy: OnFailure。问题是一个跑了 40 分钟的 agent 被驱逐后从零开始。后来改成：

• agent 状态定期 checkpoint 到外部存储
• 调度时用 podAffinity 尽量把 agent 钉在特定节点
• 驱逐前先触发 checkpoint（用 preStop hook）

这套组合下来，状态丢失从"每次驱逐都丢"降到"极端情况下丢最后几分钟"。

7.2 坑二：device plugin 上报的资源调度不进去

我们用 device plugin 上报了一种自定义资源，结果发现调度器不认。排查后发现是 device plugin 注册的资源名和 Pod 里请求的资源名不一致。device plugin 注册的是example.com/tool-a，Pod 里写的是example.com/tool_a（下划线 vs 横线）。这种低级错误排查起来很费时间，因为报错信息不直观。

注意：Kubernetes 的资源名有命名规范，扩展资源必须用域名/资源名格式，且资源名部分只能包含字母、数字、横线、下划线、点。横线和下划线不通用，写的时候要仔细。

7.3 坑三：workspace 初始化超时设置不当

前面提过，超时设太短会误杀正常请求。我踩过的具体坑是把 workspace 初始化的总超时设成 60 秒，结果大依赖包下载需要 90 秒，每次初始化都失败。后来改成 300 秒，并且把"下载"和"解析"两个阶段分开设超时，下载给 240 秒，解析给 60 秒，问题解决。

7.4 坑四：多集群调度时忽略了 DNS

多集群场景下，agent 调用的外部服务域名在不同集群可能解析到不同 IP。如果 agent 的配置里写死了 IP，跨集群调度就会失败。解决办法是统一用域名，并且确保每个集群的 DNS 都能正确解析。这个坑不常遇到，但遇到一次就很难查，因为报错信息通常是"连接超时"，看起来像网络问题。

8. 如果你现在要动手，我的建议顺序

如果你看完上面这些，想自己动手搭一套 agentic 调度层，我的建议顺序是：

第一步：先把单集群的调度跑通。不要一上来就上多集群。用 Kubernetes 原生的调度能力，加上 nodeAffinity 和 podAffinity，把 agent 的亲和性需求表达清楚。这一步的目标是"能跑"，不是"跑得好"。

第二步：把状态外置做掉。这是提升调度自由度的关键。状态外置得越彻底，调度器能做的决策越多。如果团队不愿意改代码，至少把 checkpoint 机制加上。

第三步：加可观测性。调度决策的 trace、agent 的生命周期事件、资源使用曲线，这些都要有。没有可观测性，出了问题只能猜。

第四步：考虑多集群。等单集群真的撑不住了，再上 Karmada。上之前先把镜像同步、网络打通、监控聚合这三件事做好。

第五步：补安全边界。最小权限、网络隔离、运行时沙箱，这三层按需上。安全不是一次性的，是持续的过程。

最后分享一个我自己的体会：agentic 调度这件事，难的不是调度算法本身，而是对 agent 行为的理解。你得知道 agent 在什么阶段需要什么资源、状态存在哪里、失败后怎么恢复，才能设计出合理的调度策略。纯从 Kubernetes 角度想这个问题，很容易想偏。多和写 agent 的人聊，比多看调度器源码更有用。