1. 从“ax”这个标题说起一个被低估的调度原语第一次看到“ax”这个标题很多人会以为是某个命令行工具的缩写或者某个前端框架的代号。但把热搜词摊开来看——ax、agentic、orchestration、kubernetes、workspace——这几个词凑在一起指向的其实是一个非常具体的技术命题在 Kubernetes 之上为 agentic 工作负载做一套调度与编排的抽象层。我最早接触这类需求是在做多租户 AI 任务平台的时候。当时团队里有人提了一个很朴素的问题我们有一堆 agent 要跑每个 agent 有自己的 workspace、自己的依赖、自己的生命周期为什么不能像调度 Pod 一样调度它们这个问题听起来简单但真正落地时会发现Kubernetes 原生的调度语义是围绕“长期运行的服务”和“一次性任务”设计的而 agentic 负载的特点是状态化、长会话、工具调用密集、workspace 需要持久化且隔离。直接用 Deployment 或 Job 去套会撞上一堆边界问题。“ax”在我的理解里就是对这个问题的回应。它不是 Kubernetes 的替代品而是架在 Kubernetes 之上的一层agent 调度抽象。你可以把它想象成 Kubernetes 的“agent 运行时接口”底层还是 Pod、PVC、Service 那一套但上层暴露的是 agent、workspace、session、tool 这些更贴近 agentic 场景的概念。热搜里出现的[init] using kubernetes version: v1.26.0、[preflight] running pre-flight chec这些片段说明实际部署时确实是在跟 kubeadm 这类工具打交道底层集群版本至少是 1.26。这篇文章适合谁看如果你正在做 agent 平台、AI 工作流编排、多租户 workspace 管理或者你只是好奇“agentic orchestration 到底怎么落到 Kubernetes 上”那这篇内容应该能给你一些可以直接抄的作业。我会从设计思路、核心概念、实操部署、问题排查四个层面拆开讲尽量把每个“为什么”都说清楚。2. 整体设计思路为什么要在 Kubernetes 上再包一层2.1 agentic 负载和普通微服务到底差在哪普通微服务和 agentic 负载最大的区别不在于计算量而在于状态的生命周期。一个 HTTP 服务是无状态的请求来了处理完就走Pod 挂了重启就行。但一个 agent 不一样它可能正在执行一个长达几十分钟的任务中间调用了十几个工具workspace 里写满了中间文件会话上下文存在内存或本地磁盘里。这时候你把 Pod 重启了任务就断了。我踩过的第一个坑就在这里。早期我们直接用 Job 跑 agent 任务结果发现 Job 的backoffLimit和activeDeadlineSeconds根本不够用——agent 任务不是“失败重试”那么简单它需要的是断点续跑和workspace 保留。Job 失败后 Pod 被清理PVC 如果没配好中间产物全丢。后来我们改成 StatefulSet又发现 StatefulSet 的扩缩容语义太重一个 agent 一个 Pod 的模式在几百个 agent 并发时etcd 压力直接拉满。所以“ax”这类抽象层的第一个设计目标就是把 agent 的生命周期和 Pod 的生命周期解耦。agent 是一个逻辑实体Pod 只是它某一时刻的执行载体。agent 可以休眠、可以迁移、可以被唤醒而 Pod 可以随时创建销毁。这个解耦是后面所有设计的基础。2.2 为什么选 Kubernetes 作为底座而不是自研调度器有人会问既然 Kubernetes 原生语义不匹配为什么不自己写一个调度器我的答案是不要重复造轮子但要学会给轮子加适配器。Kubernetes 已经解决了分布式系统里最难的那部分问题资源调度、网络、存储编排、健康检查、滚动更新、RBAC、命名空间隔离。你自研一个调度器这些全都要重写一遍而且大概率写得不如社区好。agentic 场景真正特殊的地方其实只在调度策略和生命周期管理这两层。底层的能力Kubernetes 已经足够。“ax”的做法是底层继续用 Kubernetes 的 Pod、PVC、Service、ConfigMap但在上面加一层 Controller 和 CRDCustom Resource Definition。比如定义一个AgentCRD描述 agent 的镜像、workspace 大小、工具依赖、超时策略再定义一个WorkspaceCRD描述持久化存储的挂载点和配额。Controller 监听这些 CRD把它们翻译成底层的 Pod 和 PVC。这样既复用了 Kubernetes 的成熟能力又让上层语义贴近 agentic 场景。热搜里提到的karmada正式毕业华为云携手社区共建agentic cloud坚实底座其实也印证了这个方向多集群调度和 agentic cloud 的结合正在成为社区共识。Karmada 解决的是跨集群编排而“ax”这类层解决的是单集群内 agent 的精细调度两者是互补的。2.3 workspace 隔离为什么不能共用一个 PVCworkspace 是 agentic 场景里最容易被低估的概念。热搜里有一条vscode的workspace是什么意思虽然语境不同但核心问题是一样的workspace 是工作现场的边界。在 agent 场景里workspace 至少承担三个职责第一存放 agent 执行过程中的中间文件第二隔离不同 agent 的文件系统防止互相污染第三作为会话恢复的依据。如果你让所有 agent 共用一个 PVC会出现什么问题A agent 写了一个config.jsonB agent 读到了直接跑出错误结果。更严重的是如果 agent 会执行代码共用 workspace 等于共用了一个可写目录安全边界直接没了。所以“ax”的设计里workspace 必须是按 agent 实例隔离的。实现方式有两种一种是每个 agent 一个 PVC优点是隔离彻底缺点是 PVC 数量多了之后存储后端的元数据压力大另一种是用一个共享 PVC但每个 agent 挂载不同的子路径subPath优点是 PVC 数量少缺点是隔离性依赖路径管理一旦路径计算错误就会串。我实测下来中小规模用 subPath 方案大规模用独立 PVC 方案。subPath 方案在 500 个 agent 以内表现很稳超过之后 kubelet 的挂载操作会成为瓶颈。独立 PVC 方案在 2000 个 agent 时只要存储后端支持动态供给问题不大但要注意 PVC 的回收策略别让孤儿 PVC 把存储撑爆。3. 核心概念拆解Agent、Workspace、Session、Tool3.1 Agent CRD 应该包含哪些字段设计一个 Agent CRD最忌讳的是字段太多太杂。我见过有人把 agent 的所有配置都塞进 CRD结果 YAML 写了两百行维护成本极高。我的经验是CRD 只放调度相关的字段业务配置放 ConfigMap。一个够用的 Agent CRD 大概长这样apiVersion: ax.io/v1alpha1 kind: Agent metadata: name: research-agent spec: image: registry.example.com/agent:latest workspace: size: 10Gi storageClass: fast-ssd session: timeout: 3600 resumePolicy: OnFailure tools: - name: web-search endpoint: http://tool-websearch:8080 - name: code-exec endpoint: http://tool-codeexec:8080 resources: requests: cpu: 2 memory: 4Gi limits: cpu: 4 memory: 8Gi这里有几个字段值得展开说。session.timeout控制 agent 空闲多久后进入休眠单位是秒。resumePolicy决定 Pod 挂了之后怎么恢复OnFailure表示只有异常退出才恢复Always表示无论如何都恢复。tools列表里的 endpoint 是工具服务的地址agent 运行时通过这个地址调用工具。注意resources.limits不要设得太紧。agent 任务经常有突发计算CPU 限制太死会导致任务超时。我一般把 limits 设成 requests 的 2 倍留出 burst 空间。3.2 Workspace 的存储选型和配额管理Workspace 的存储选型核心看两个指标IOPS 和延迟。agent 任务里常见的操作是读写小文件、解压代码包、写日志这些对 IOPS 要求高对吞吐要求一般。所以选 SSD 类存储比 HDD 类存储合适得多。在 Kubernetes 里这体现为 StorageClass 的选择。我一般会准备两个 StorageClass一个fast-ssd给 workspace 用一个standard给日志和备份用。fast-ssd 的volumeBindingMode设成WaitForFirstConsumer避免 PVC 创建时 Pod 还没调度导致卷绑到错误的节点。配额管理是另一个容易翻车的地方。Kubernetes 的 ResourceQuota 可以限制 PVC 的总量但不能限制单个 PVC 的大小。所以要在 Agent CRD 的 admission webhook 里做校验比如单个 workspace 不超过 50Gi单命名空间总 workspace 不超过 500Gi。这个校验不做迟早有人申请一个 1Ti 的 workspace把存储池打满。3.3 Session 恢复机制怎么做到断点续跑Session 恢复是 agentic 编排里最复杂的部分。简单说agent 执行到一半 Pod 挂了重新拉起后要能接着跑而不是从头开始。这要求 agent 本身支持 checkpoint同时编排层要能把 workspace 和 session 状态重新挂载回去。“ax”的做法是agent 进程定期把执行状态写到 workspace 里的一个约定路径比如/workspace/.ax/session.json。Pod 重启后agent 启动时先读这个文件如果存在且resumePolicy允许就从上次的状态继续。编排层要保证的是新 Pod 挂载的是同一个 workspace且启动顺序在 workspace 就绪之后。这里有个坑如果 agent 写 session 文件写到一半 Pod 挂了文件可能是损坏的。所以写 session 要用原子写先写临时文件再 rename。rename 在 POSIX 文件系统上是原子的能保证要么读到旧版本要么读到新版本不会读到半截。3.4 Tool 调用的网络模型Tool 是 agent 调用的外部能力比如搜索、代码执行、数据库查询。在 Kubernetes 里tool 通常以 Service 的形式暴露。agent 通过环境变量或配置文件拿到 tool 的 endpoint然后发起 HTTP 或 gRPC 调用。网络模型上有两种选择同命名空间直连和跨命名空间走 Service。同命名空间直连延迟低但隔离性差跨命名空间走 Service 隔离性好但多一层网络跳转。我的建议是tool 和 agent 放在同一个命名空间但用 NetworkPolicy 限制只有特定 agent 能访问特定 tool。这样既保证延迟又有安全边界。提示tool 的 endpoint 不要硬编码在 agent 镜像里。用 ConfigMap 注入这样换环境时不用重新打镜像。4. 实操部署从零搭一个 ax 调度环境4.1 集群准备和版本选择热搜里出现了[init] using kubernetes version: v1.26.0说明实际部署时用的是 1.26。我的建议是至少用 1.26最好用 1.28 以上。1.26 是很多特性的分水岭比如PodSchedulingReadiness在 1.26 进入 beta1.27 正式 GA。这个特性对 agent 调度很有用因为它允许 Pod 在调度前等待外部条件就绪正好匹配 workspace 挂载的场景。集群初始化用 kubeadm 就行命令不复杂kubeadm init --kubernetes-versionv1.28.0 \ --pod-network-cidr10.244.0.0/16 \ --apiserver-advertise-address192.168.1.100初始化完成后装一个 CNI 插件Calico 或 Cilium 都行。我倾向 Cilium因为它的 NetworkPolicy 支持更细粒度而且有 eBPF 加速对 tool 调用的延迟更友好。[preflight] running pre-flight chec这个片段说明 kubeadm 在跑预检。预检失败最常见的原因是swap 没关、端口被占用、cgroup 驱动不匹配。swap 用swapoff -a关掉端口检查用ss -tlnp看 6443、10250 这些端口有没有被占。cgroup 驱动要确保 kubelet 和容器运行时一致都用 systemd。4.2 安装 ax Controller 和 CRDax Controller 的安装方式取决于它的分发形式。如果是 Helm Chart直接helm install ax ax/ax-controller -n ax-system --create-namespace。如果是源码先 apply CRD再部署 Controllerkubectl apply -f config/crd/bases/ kubectl apply -f config/manager/CRD 安装后用kubectl get crd | grep ax确认。应该能看到agents.ax.io、workspaces.ax.io、sessions.ax.io这几个。Controller 部署后检查它的日志kubectl logs -n ax-system deploy/ax-controller-manager -f正常启动会打印starting manager和Starting EventSource。如果卡在setting up workspace: loading packages...大概率是镜像拉取慢或者 RBAC 没配好。RBAC 问题看日志里的forbidden关键字镜像问题看 Pod 的ImagePullBackOff事件。4.3 创建第一个 Agent 和 Workspace先创建一个 WorkspaceapiVersion: ax.io/v1alpha1 kind: Workspace metadata: name: demo-workspace namespace: default spec: size: 5Gi storageClass: fast-ssd reclaimPolicy: RetainreclaimPolicy: Retain表示 Workspace 删除后 PVC 保留方便排查问题。生产环境可以设成Delete但要有备份机制。再创建一个 AgentapiVersion: ax.io/v1alpha1 kind: Agent metadata: name: demo-agent namespace: default spec: image: busybox:latest command: [sh, -c, while true; do echo agent running; sleep 60; done] workspaceRef: demo-workspace session: timeout: 600 resumePolicy: OnFailureapply 之后用kubectl get agents看状态。正常会经历Pending-Creating-Running。如果卡在Pending用kubectl describe agent demo-agent看 Events通常是 workspace 没就绪或者资源不足。4.4 验证调度和隔离效果验证调度效果最直接的方法是看 Pod 落在哪个节点kubectl get pods -o wide | grep demo-agent然后进 Pod 看 workspace 挂载kubectl exec -it demo-agent-xxx -- df -h /workspace应该能看到 5Gi 的挂载点。再写个文件测试持久化kubectl exec -it demo-agent-xxx -- touch /workspace/test.txt kubectl delete pod demo-agent-xxx # 等 Controller 重建 Pod kubectl exec -it demo-agent-yyy -- ls /workspace如果test.txt还在说明 workspace 持久化生效了。隔离效果测试创建两个 Agent分别挂不同的 Workspace在 A 里写文件去 B 里看应该看不到。如果能看到说明 subPath 计算有问题或者 PVC 绑错了。5. 常见问题与排查技巧实录5.1 Agent 一直 Pending 怎么办Pending 是最常见的问题原因通常有三类资源不足、workspace 未就绪、调度约束不满足。排查顺序先kubectl describe agent name看 Events再kubectl describe pod pod看更底层的 Events。如果 Events 里出现0/3 nodes are available: 3 Insufficient cpu就是资源不足要么加节点要么调低 requests。如果出现waiting for workspace to be ready就去查 Workspace 的状态看 PVC 有没有 Bound。PVC 不 Bound 的常见原因是 StorageClass 不存在或者volumeBindingMode设成了Immediate但节点上没有对应存储。用kubectl get sc确认 StorageClass用kubectl get pvc -n default看 PVC 状态。5.2 Workspace 挂载失败mount 报错怎么查挂载失败的表现是 Pod 卡在ContainerCreatingkubectl describe pod里能看到MountVolume.SetUp failed。这时候要去节点上看 kubelet 日志journalctl -u kubelet -f | grep -i mount常见错误有no such file or directorysubPath 目录不存在、permission denied挂载点权限不对、timeout存储后端响应慢。subPath 目录不存在的问题可以在 Agent 启动前加一个 initContainer先创建目录。权限问题通常是 PVC 的fsGroup没设在 PodSecurityContext 里加fsGroup: 1000能解决大部分。5.3 Session 恢复不生效的排查思路Session 恢复不生效先确认三件事agent 有没有写 session 文件、resumePolicy 是不是允许恢复、新 Pod 挂的是不是同一个 workspace。进 Pod 看/workspace/.ax/session.json存不存在。如果不存在说明 agent 没写要检查 agent 的 checkpoint 逻辑。如果存在但没恢复看 Controller 日志里有没有resuming session关键字。没有的话可能是 resumePolicy 设成了Never或者 session 文件格式不对Controller 解析失败。提示session 文件建议用 JSON 格式字段名用 snake_case避免不同语言解析时的兼容问题。5.4 工具调用超时和网络策略冲突Tool 调用超时先kubectl exec进 agent Pod用curl或nc测 tool 的 endpoint 通不通。不通的话检查 NetworkPolicykubectl get networkpolicy -n default如果 policy 里只允许了特定 label 的 Pod 访问确认 agent Pod 的 label 匹配。另一个常见原因是 Service 的targetPort和容器实际监听端口不一致用kubectl get svc tool -o yaml看targetPort再进 tool Pod 用ss -tlnp看实际端口。5.5 常见问题速查表现象可能原因排查命令解决方向Agent Pending资源不足kubectl describe agent调低 requests 或加节点Pod ContainerCreating挂载失败journalctl -u kubelet检查 subPath 和 fsGroupSession 不恢复resumePolicy 不对kubectl logs ax-controller改 resumePolicy 为 OnFailureTool 调用超时NetworkPolicy 拦截kubectl get networkpolicy放行对应 labelController 启动卡住镜像拉取慢kubectl describe pod配镜像加速或预拉取PVC 不 BoundStorageClass 缺失kubectl get sc创建对应 StorageClass6. 性能调优和规模化经验6.1 Controller 的并发调谐参数怎么调ax Controller 默认的并发调谐数concurrent reconciles通常比较保守比如 1 或 2。在 agent 数量少的时候没问题但到了几百个 agent 时调谐速度会跟不上。可以在 Controller 的启动参数里加--concurrent-agent-syncs10把并发数提上去。但并发数不是越高越好。我实测下来10 到 20 之间比较合适。超过 20 之后API Server 的请求压力明显上升而且 Controller 自身的 CPU 会成为瓶颈。调的时候要盯着 API Server 的apiserver_request_duration_seconds指标如果 P99 超过 1 秒就要往回调。6.2 Workspace 存储的 IOPS 瓶颈怎么定位Workspace 变慢通常是 IOPS 打满了。定位方法是进节点用iostat -x 1看%util如果接近 100%就是存储瓶颈。另一个指标是await超过 20ms 就说明延迟偏高。解决方向有三个换更高 IOPS 的存储类、把 workspace 拆到多个存储后端、减少不必要的文件操作。第三个最容易被忽略。我见过 agent 每执行一步就写一次全量日志到 workspaceIOPS 全耗在日志上。改成写 stdout让容器运行时收集workspace 的 IOPS 直接降了一半。6.3 多租户场景下的资源配额设计多租户场景下配额要分三层命名空间级、Agent 级、Workspace 级。命名空间级用 ResourceQuota 限制总 CPU、内存、PVC 数量Agent 级用 LimitRange 限制单个 Pod 的资源范围Workspace 级用 admission webhook 限制单个 workspace 的大小。三层配额的关系是命名空间级是硬上限Agent 级是默认值和范围Workspace 级是细粒度控制。设计的时候要注意ResourceQuota 的 PVC 数量限制是按 PVC 个数算的不是按容量。所以如果每个 agent 一个 PVC配额要设得足够大否则 agent 创建到一半就失败了。7. 我对 agentic orchestration 的一点个人判断做了几个 agent 平台之后我越来越觉得agentic orchestration 的核心难点不在调度算法而在状态管理。Kubernetes 把无状态服务的编排做到了极致但 agent 是有状态的而且状态的生命周期比 Pod 长得多。谁能把状态管理做好谁就能在 agentic 这波里站住脚。“ax”这个方向是对的但它不是终点。我预期后面会出现更细分的层有的专门做 workspace 存储有的专门做 session 恢复有的专门做 tool 路由。就像当年 Kubernetes 生态分化出 Istio、Prometheus、Helm 一样agentic 生态也会分化。现在入场正好是卡位的时候。最后分享一个我踩过的坑不要用 ConfigMap 存 agent 的 session 状态。ConfigMap 有 1MiB 的大小限制而且更新频率高了之后etcd 的写入压力很大。session 状态老老实实写 workspace用文件系统管简单可靠。这个坑我花了两个星期才爬出来希望你别再踩。
