随着大模型技术的飞速发展，AI Agent 正从概念走向生产。与传统的批处理任务或推理服务不同，Agent 工作负载呈现出独特的运行特征——间歇性活跃、极低延迟敏感、多轮会话状态持久化。然而，现有的 Kubernetes 调度体系主要面向批处理和长运行服务设计，难以有效应对这类"潮汐式"交互负载：空闲时资源白白占用，唤醒时又无法做到亚秒级响应，状态管理更是一大痛点。AgentCube[1] 正是为解决这一矛盾而生。作为 Volcano社区[2]的子项目，AgentCube 专为 AI Agent 工作负载打造了专用的控制面与数据面，核心优势体现在四个方面：极速启动—— 通过 Warm Pool （预热池）机制预先创建并暂停一批沙箱，当 Agent 请求到来时以 "Claim-and-Go" 的方式进行毫秒级分配，消除冷启动瓶颈。高效调度 —— 借助 Volcano Agent Scheduler 的乐观并发控制与精简调度策略，大幅提升调度吞吐，并能与 Volcano 原有的 Batch Scheduler 无缝协作，确保 Agent 与传统批处理作业的统一调度与资源协调。原生会话管理 —— 以 Session ID 为核心路由标识，会话到来时自动识别并路由请求至对应沙箱，并在沙箱休眠时自动唤醒，保障多轮交互的上下文连续性。安全隔离 —— 为每个会话分配独立沙箱，确保计算、内存与文件系统的端到端隔离，防止跨租户数据泄露。同时支持以安全容器运行 Agent，借助安全运行时技术实现内核级强隔离。本文将聚焦 AgentCube 在华为云 CCE（云容器引擎）上的实践，探讨如何将 AgentCube 的调度能力与 CCE 的基础设施深度结合，为 AI Agent 应用提供高效、稳定的云原生运行底座。关于AgentCube的原理可通过设计文档[3]或往期文章[4]了解。  环境准备  已经创建好了一个1.29或更高版本的CCE集群确保本地安装的python版本>=3.11安装SDK[5] ： pip install agentcube_sdk  安装 AgentCube 插件  AgentCube目前已上架华为云 CCE 插件市场。可通过登录CCE控制台[6]进入集群插件中心界面，找到AgentCube插件进行配置安装。 AgentCube主要组件：workloadmanager：管理AgentRuntime和CodeInterpreter的生命周期。agentcube-router：API 网关，代理客户端请求到沙箱实例。volcano-agent-scheduler：调度器组件，提供低延迟和高吞吐的负责调度。agent-sandbox-controller：管理AgentSandbox资源。安装时需要设置如下参数：redis.addr：Redis的地址，必须配置。redis.password：Redis的密码，必须配置。agentSandbox.install：是否自动安装agent-sandbox。AgentCube插件运行时依赖 agent-sandbox[7]，当参数配置为true时会自动安装。如果集群已手动安装了agent-sandbox，则可配置为false跳过安装。agentSandbox.extensions：是否启用agent-sandbox的extension controller。volcano.scheduler.enabled：是否安装volcano agent-scheduler调度器。由于AgentCube运行时依赖Redis维护会话状态和索引，从稳定性和可扩展性考虑，建议购买和使用华为云分布式缓存服务 DCS[8]。此外，如果要在集群外访问 AgentCube，可为workloadmanager和agentcube-router的Service绑定ELB Ingress。  开始使用  ▍步骤一：环境变量设置export WORKLOAD_MANAGER_URL="http://workloadmanager-addr:workloadmanager-port" export ROUTER_URL="http://agentcube-router-addr:agentcube-router-port"其中workloadmanager-addr、workloadmanager-service-nodeport为workload-manager的访问地址和端口，agentcube-router-addr、agentcube-router-port为agentcube-router的访问地址和端口。▍步骤二：使用CodeInterpreterCodeInterpreter是AgentCube两大核心能力之一（另一个是AgentRuntime），是专为执行 LLM 生成的不可信代码而设计的受限运行时。通过收窄模板配置、内置 JWT 认证和预热池加速，在保障安全隔离的同时实现毫秒级启动，适用于代码解释器等沙箱执行场景。部署CodeInterpreter首先创建文件code-interpreter.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: CodeInterpretermetadata:  name: my-codeinterpreter  namespace: defaultspec:  template:    # runtimeClassName: kata    # 若使用安全容器，则可配置runtimeClassName为kata或kuasar-vmm（需要有支持安全运行时的节点）    image: swr.ap-southeast-3.myhuaweicloud.com/container/picod:latest    # 使用 PicoD 镜像，当前示例使用的镜像仅支持执行shell和python代码    resources:      requests:        cpu: "100m"        memory: "128Mi"      limits:        cpu: "500m"        memory: "512Mi"  sessionTimeout: "15m"      # 空闲 15 分钟后超时  maxSessionDuration: "8h"   # 最大会话时长 8 小时  warmPoolSize: 5    # 预热 5 个 Pod执行部署：kubectl apply -f code-interpreter.yaml验证是否部署成功：kubectl get codeinterpreter部署完成后，等待一段时间执行kubectl get pods |grep my-codeinterpreter可以看到已经预热出了5个CodeInterpreter。远程执行第一份代码创建python脚本quickstart.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')with CodeInterpreterClient(name="my-codeinterpreter", namespace="default") as client:    result = client.run_code("python", "print('Hello from AgentCube!')")    print(result)上述python脚本会连接到上一步部署的CodeInterpreter，启动一个隔离的沙箱会话，向其发送一段待执行的 Python 代码片段，并打印输出结果。执行python quickstart.py开始运行，输出：2026-06-05 15:25:22,584 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:25:22,790 | INFO | agentcube.code_interpreter | Session created: 900923f4-4d1c-4383-ac6b-331c5ec83acbHello from AgentCube!2026-06-05 15:25:22,921 | INFO | agentcube.code_interpreter | Deleting session 900923f4-4d1c-4383-ac6b-331c5ec83acb...尝试在一个会话中连续执行代码在步骤三中，我们创建的 CodeInterpreter 仅运行了单次代码便自动结束了会话。但在真实的业务场景中，我们往往需要处理多轮连续交互。接下来，我们将通过一个更具实战价值的进阶示例，来展示 AgentCube 的会话保持能力。创建python脚本longtask.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def session_reuse_workflow():    # 步骤 1：创建会话并写入数据    print("step 1: Create a session and write initial data.")    client1 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,    )    # 写入多个文件    client1.write_file("100", "counter.txt")    client1.write_file("[]", "results.json")    session_id = client1.session_id    print(f"session ID: {session_id}")    print("The file system status has been saved.\n")    # 注意：不调用 client1.stop()，让会话保持活跃    # 步骤 2：复用会话，读取并处理数据    print("step 2: Reusing sessions and processing data.")    client2 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,        session_id=session_id,  # 复用会话    )    code = """import jsonimport time# 读取计数器with open('counter.txt') as f:    counter = int(f.read().strip())print(f"current count: {counter}")# 增加计数counter += 1with open('counter.txt', 'w') as f:    f.write(str(counter))# 读取结果列表with open('results.json') as f:    results = json.load(f)# 添加新结果results.append({    'timestamp': time.time(),    'counter': counter})# 保存结果with open('results.json', 'w') as f:    json.dump(results, f, indent=2)print(f"new count: {counter}")print(f"result count: {len(results)}")"""    result = client2.run_code("python", code)    print(f"{result}\n")    # 步骤 3：查看文件系统状态    print("step 3: Verifying the File System Statuses")    files = client2.list_files(".")    print(f"Files in session: {[f['name'] for f in files]}\n")    # 清理会话    client2.stop()    print("session is deleted")if __name__ == "__main__":    session_reuse_workflow()上述python脚本首先创建了一个会话，往CodeInterpreter中上传了两个文件counter.txt和results.json。然后并不立即关闭会话，而是使用第一次创建会话时返回的session_id（会话ID）再次创建了一个客户端并远程执行代码。执行python longtask.py开始运行，输出如下：step 1: Create a session and write initial data.2026-06-05 15:45:03,386 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:45:03,775 | INFO | agentcube.code_interpreter | Session created: eda5f22f-ad7d-4d95-9adf-b74dbf015051session ID: eda5f22f-ad7d-4d95-9adf-b74dbf015051The file system status has been saved.step 2: Reusing sessions and processing data.2026-06-05 15:45:03,893 | INFO | agentcube.code_interpreter | Reusing existing session: eda5f22f-ad7d-4d95-9adf-b74dbf015051current count: 100new count: 101result count: 1step 3: Verifying the File System StatusesFiles in session: ['.bashrc', '.profile', 'counter.txt', 'picod', 'results.json', 'script_1780645503894.py']2026-06-05 15:45:04,072 | INFO | agentcube.code_interpreter | Deleting session eda5f22f-ad7d-4d95-9adf-b74dbf015051...session is deleted可以看到3轮请求的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个CodeInterpreter实例而非创建新的。且第2、3轮请求能够读取到第1轮请求上传的文件，说明这个CodeInterpreter实例并没有被销毁和重建，它的整个运行时状态——包括文件系统、内存中的变量、进程上下文等，都在请求之间完整保留。这正是 CodeInterpreter 区别于无状态函数调用的核心优势。▍步骤三：使用AgentRuntime有别于 CodeInterpreter，AgentRuntime 支持完整的 PodSpec 自定义，适用于对话、工具调用等常规 Agent 场景。部署AgentRuntime创建agent.py、requirements.txt文件，其中agent.py文件内容为官方提供的Agent示例代码[9]，requirements.txt如下：agentcube_sdk使用如下Dockerfile制作Agent容器镜像，并将制作好的镜像上传华为云SWR。FROM python:3.11-slimWORKDIR /app# 复制依赖文件COPY requirements.txt .# 安装 Python 依赖RUN pip install --no-cache-dir -r requirements.txt# 复制应用代码COPY agent.py /app/# 暴露端口EXPOSE8080# 运行应用CMD ["python", "/app/agent.py"]创建文件agent-runtime.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: AgentRuntimemetadata:  name: my-agent-app  namespace: defaultspec:  targetPort:    - pathPrefix: "/"      port: 8080      protocol: "HTTP"  podTemplate:    labels:      app: my-agent-app    spec:      schedulerName: default-scheduler    # 如果开启安装了volcano agent-scheduler调度器，可配置为agent-scheduler      containers:        - name: my-agent-app          image: {{agent image}}    # 构建好并上传华为云SWR的Agent容器镜像          env:            - name: WORKLOAD_MANAGER_URL              value: http://workloadmanager.agentcube.svc.cluster.local:8080            - name: ROUTER_URL              value: http://agentcube-router.agentcube.svc.cluster.local:8080            - name: CODEINTERPRETER_NAME              value: my-codeinterpreter            - name: CODEINTERPRETER_NAMESPACE              value: default          readinessProbe:            httpGet:              path: /health              port: 8080            periodSeconds: 5  sessionTimeout: "15m"             # 空闲 15 分钟后超时  maxSessionDuration: "8h"          # 最大会话时长 8 小时status: {}执行部署:kubectl apply -f agent-runtime.yaml验证是否部署成功:kubectl get agentruntime输出:NAME           AGEmy-agent-app   1m说明部署成功，my-agent-app为我们创建的Agent的名字。与Agent进行对话创建python脚本chatToAgent.py：from agentcube.agent_runtime import AgentRuntimeClientimport osimport timeROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def test_conversation():    # 第一轮对话    agent_client1 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0    )    # 记录会话ID，后续对话复用    session_id = agent_client1.session_id    result = agent_client1.invoke(        payload={"prompt": "Introduce yourself"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第二轮对话    agent_client2 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client2.invoke(        payload={"prompt": "What can you do?"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第三轮对话    agent_client3 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client3.invoke(        payload={"prompt": "Write a Python function for me"},    )    print(f"response: {result}\n")if __name__ == "__main__":    test_conversation()上述python脚本首先创建了一个对话，对话的对象是上一步创建的my-agent-appAgent应用，然后连续发起3次对话。输出如下：2026-06-05 16:33:28,396 | INFO | agentcube.agent_runtime | Bootstrapping AgentRuntime session...2026-06-05 16:33:29,771 | INFO | agentcube.agent_runtime | AgentRuntime session created: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Introduce yourself', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:29.839193', 'original_prompt': 'Introduce yourself'}2026-06-05 16:33:30,812 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: What can you do?', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:30.912573', 'original_prompt': 'What can you do?'}2026-06-05 16:33:31,886 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Write a Python function for me', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:31.989551', 'original_prompt': 'Write a Python function for me'}可以看到3次对话的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个AgentRuntime实例。  总 结  AgentCube 以极速启动、高效调度、原生会话管理、安全隔离四大核心能力，补齐了 K8s 集群承载 AI Agent 工作负载的短板。华为云 CCE 将持续集成 AgentCube ，为用户打造低延迟、高吞吐、强隔离的高性能 AI Agent 运行底座。 相关链接[1] AgentCube GitHub仓库: cid:link_7[2] Volcano官网: https://volcano.sh[3] AgentCube设计文档: cid:link_3[4] Kubernetes 跑 AI Agent，缺的不只是算力——AgentCube 补上了什么: cid:link_6[5] Python SDK: cid:link_4[6] 华为云CCE控制台: cid:link_1[7] AgentSandbox: cid:link_5[8] 华为云分布式缓存服务 DCS: cid:link_2[9] Agent示例代码: cid:link_0 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

随着大模型技术的飞速发展，AI Agent 正从概念走向生产。与传统的批处理任务或推理服务不同，Agent 工作负载呈现出独特的运行特征——间歇性活跃、极低延迟敏感、多轮会话状态持久化。然而，现有的 Kubernetes 调度体系主要面向批处理和长运行服务设计，难以有效应对这类"潮汐式"交互负载：空闲时资源白白占用，唤醒时又无法做到亚秒级响应，状态管理更是一大痛点。AgentCube[1] 正是为解决这一矛盾而生。作为 Volcano社区[2]的子项目，AgentCube 专为 AI Agent 工作负载打造了专用的控制面与数据面，核心优势体现在四个方面： 极速启动—— 通过 Warm Pool （预热池）机制预先创建并暂停一批沙箱，当 Agent 请求到来时以 "Claim-and-Go" 的方式进行毫秒级分配，消除冷启动瓶颈。高效调度 —— 借助 Volcano Agent Scheduler 的乐观并发控制与精简调度策略，大幅提升调度吞吐，并能与 Volcano 原有的 Batch Scheduler 无缝协作，确保 Agent 与传统批处理作业的统一调度与资源协调。原生会话管理 —— 以 Session ID 为核心路由标识，会话到来时自动识别并路由请求至对应沙箱，并在沙箱休眠时自动唤醒，保障多轮交互的上下文连续性。安全隔离 —— 为每个会话分配独立沙箱，确保计算、内存与文件系统的端到端隔离，防止跨租户数据泄露。同时支持以安全容器运行 Agent，借助安全运行时技术实现内核级强隔离。本文将聚焦 AgentCube 在华为云 CCE（云容器引擎）上的实践，探讨如何将 AgentCube 的调度能力与 CCE 的基础设施深度结合，为 AI Agent 应用提供高效、稳定的云原生运行底座。关于AgentCube的原理可通过设计文档[3]或往期文章[4]了解。  环境准备  已经创建好了一个1.29或更高版本的CCE集群确保本地安装的python版本>=3.11安装SDK[5] ： pip install agentcube_sdk  安装 AgentCube 插件  AgentCube目前已上架华为云 CCE 插件市场。可通过登录CCE控制台[6]进入集群插件中心界面，找到AgentCube插件进行配置安装。 AgentCube主要组件： workloadmanager：管理AgentRuntime和CodeInterpreter的生命周期。agentcube-router：API 网关，代理客户端请求到沙箱实例。volcano-agent-scheduler：调度器组件，提供低延迟和高吞吐的负责调度。agent-sandbox-controller：管理AgentSandbox资源。安装时需要设置如下参数：redis.addr：Redis的地址，必须配置。redis.password：Redis的密码，必须配置。agentSandbox.install：是否自动安装agent-sandbox。AgentCube插件运行时依赖 agent-sandbox[7]，当参数配置为true时会自动安装。如果集群已手动安装了agent-sandbox，则可配置为false跳过安装。agentSandbox.extensions：是否启用agent-sandbox的extension controller。volcano.scheduler.enabled：是否安装volcano agent-scheduler调度器。由于AgentCube运行时依赖Redis维护会话状态和索引，从稳定性和可扩展性考虑，建议购买和使用华为云分布式缓存服务 DCS[8]。此外，如果要在集群外访问 AgentCube，可为workloadmanager和agentcube-router的Service绑定ELB Ingress。  开始使用  ▍步骤一：环境变量设置export WORKLOAD_MANAGER_URL="http://workloadmanager-addr:workloadmanager-port" export ROUTER_URL="http://agentcube-router-addr:agentcube-router-port"其中workloadmanager-addr、workloadmanager-service-nodeport为workload-manager的访问地址和端口，agentcube-router-addr、agentcube-router-port为agentcube-router的访问地址和端口。▍步骤二：使用CodeInterpreterCodeInterpreter是AgentCube两大核心能力之一（另一个是AgentRuntime），是专为执行 LLM 生成的不可信代码而设计的受限运行时。通过收窄模板配置、内置 JWT 认证和预热池加速，在保障安全隔离的同时实现毫秒级启动，适用于代码解释器等沙箱执行场景。部署CodeInterpreter首先创建文件code-interpreter.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: CodeInterpretermetadata:  name: my-codeinterpreter  namespace: defaultspec:  template:    # runtimeClassName: kata    # 若使用安全容器，则可配置runtimeClassName为kata或kuasar-vmm（需要有支持安全运行时的节点）    image: swr.ap-southeast-3.myhuaweicloud.com/container/picod:latest    # 使用 PicoD 镜像，当前示例使用的镜像仅支持执行shell和python代码    resources:      requests:        cpu: "100m"        memory: "128Mi"      limits:        cpu: "500m"        memory: "512Mi"  sessionTimeout: "15m"      # 空闲 15 分钟后超时  maxSessionDuration: "8h"   # 最大会话时长 8 小时  warmPoolSize: 5    # 预热 5 个 Pod执行部署：kubectl apply -f code-interpreter.yaml验证是否部署成功：kubectl get codeinterpreter部署完成后，等待一段时间执行kubectl get pods |grep my-codeinterpreter可以看到已经预热出了5个CodeInterpreter。远程执行第一份代码创建python脚本quickstart.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')with CodeInterpreterClient(name="my-codeinterpreter", namespace="default") as client:    result = client.run_code("python", "print('Hello from AgentCube!')")    print(result)上述python脚本会连接到上一步部署的CodeInterpreter，启动一个隔离的沙箱会话，向其发送一段待执行的 Python 代码片段，并打印输出结果。执行python quickstart.py开始运行，输出：2026-06-05 15:25:22,584 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:25:22,790 | INFO | agentcube.code_interpreter | Session created: 900923f4-4d1c-4383-ac6b-331c5ec83acbHello from AgentCube!2026-06-05 15:25:22,921 | INFO | agentcube.code_interpreter | Deleting session 900923f4-4d1c-4383-ac6b-331c5ec83acb...尝试在一个会话中连续执行代码在步骤三中，我们创建的 CodeInterpreter 仅运行了单次代码便自动结束了会话。但在真实的业务场景中，我们往往需要处理多轮连续交互。接下来，我们将通过一个更具实战价值的进阶示例，来展示 AgentCube 的会话保持能力。创建python脚本longtask.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def session_reuse_workflow():    # 步骤 1：创建会话并写入数据    print("step 1: Create a session and write initial data.")    client1 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,    )    # 写入多个文件    client1.write_file("100", "counter.txt")    client1.write_file("[]", "results.json")    session_id = client1.session_id    print(f"session ID: {session_id}")    print("The file system status has been saved.\n")    # 注意：不调用 client1.stop()，让会话保持活跃    # 步骤 2：复用会话，读取并处理数据    print("step 2: Reusing sessions and processing data.")    client2 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,        session_id=session_id,  # 复用会话    )    code = """import jsonimport time# 读取计数器with open('counter.txt') as f:    counter = int(f.read().strip())print(f"current count: {counter}")# 增加计数counter += 1with open('counter.txt', 'w') as f:    f.write(str(counter))# 读取结果列表with open('results.json') as f:    results = json.load(f)# 添加新结果results.append({    'timestamp': time.time(),    'counter': counter})# 保存结果with open('results.json', 'w') as f:    json.dump(results, f, indent=2)print(f"new count: {counter}")print(f"result count: {len(results)}")"""    result = client2.run_code("python", code)    print(f"{result}\n")    # 步骤 3：查看文件系统状态    print("step 3: Verifying the File System Statuses")    files = client2.list_files(".")    print(f"Files in session: {[f['name'] for f in files]}\n")    # 清理会话    client2.stop()    print("session is deleted")if __name__ == "__main__":    session_reuse_workflow()上述python脚本首先创建了一个会话，往CodeInterpreter中上传了两个文件counter.txt和results.json。然后并不立即关闭会话，而是使用第一次创建会话时返回的session_id（会话ID）再次创建了一个客户端并远程执行代码。执行python longtask.py开始运行，输出如下：step 1: Create a session and write initial data.2026-06-05 15:45:03,386 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:45:03,775 | INFO | agentcube.code_interpreter | Session created: eda5f22f-ad7d-4d95-9adf-b74dbf015051session ID: eda5f22f-ad7d-4d95-9adf-b74dbf015051The file system status has been saved.step 2: Reusing sessions and processing data.2026-06-05 15:45:03,893 | INFO | agentcube.code_interpreter | Reusing existing session: eda5f22f-ad7d-4d95-9adf-b74dbf015051current count: 100new count: 101result count: 1step 3: Verifying the File System StatusesFiles in session: ['.bashrc', '.profile', 'counter.txt', 'picod', 'results.json', 'script_1780645503894.py']2026-06-05 15:45:04,072 | INFO | agentcube.code_interpreter | Deleting session eda5f22f-ad7d-4d95-9adf-b74dbf015051...session is deleted可以看到3轮请求的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个CodeInterpreter实例而非创建新的。且第2、3轮请求能够读取到第1轮请求上传的文件，说明这个CodeInterpreter实例并没有被销毁和重建，它的整个运行时状态——包括文件系统、内存中的变量、进程上下文等，都在请求之间完整保留。这正是 CodeInterpreter 区别于无状态函数调用的核心优势。▍步骤三：使用AgentRuntime有别于 CodeInterpreter，AgentRuntime 支持完整的 PodSpec 自定义，适用于对话、工具调用等常规 Agent 场景。部署AgentRuntime创建agent.py、requirements.txt文件，其中agent.py文件内容为官方提供的Agent示例代码[9]，requirements.txt如下：agentcube_sdk使用如下Dockerfile制作Agent容器镜像，并将制作好的镜像上传华为云SWR。FROM python:3.11-slimWORKDIR /app# 复制依赖文件COPY requirements.txt .# 安装 Python 依赖RUN pip install --no-cache-dir -r requirements.txt# 复制应用代码COPY agent.py /app/# 暴露端口EXPOSE8080# 运行应用CMD ["python", "/app/agent.py"]创建文件agent-runtime.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: AgentRuntimemetadata:  name: my-agent-app  namespace: defaultspec:  targetPort:    - pathPrefix: "/"      port: 8080      protocol: "HTTP"  podTemplate:    labels:      app: my-agent-app    spec:      schedulerName: default-scheduler    # 如果开启安装了volcano agent-scheduler调度器，可配置为agent-scheduler      containers:        - name: my-agent-app          image: {{agent image}}    # 构建好并上传华为云SWR的Agent容器镜像          env:            - name: WORKLOAD_MANAGER_URL              value: http://workloadmanager.agentcube.svc.cluster.local:8080            - name: ROUTER_URL              value: http://agentcube-router.agentcube.svc.cluster.local:8080            - name: CODEINTERPRETER_NAME              value: my-codeinterpreter            - name: CODEINTERPRETER_NAMESPACE              value: default          readinessProbe:            httpGet:              path: /health              port: 8080            periodSeconds: 5  sessionTimeout: "15m"             # 空闲 15 分钟后超时  maxSessionDuration: "8h"          # 最大会话时长 8 小时status: {}执行部署:kubectl apply -f agent-runtime.yaml验证是否部署成功:kubectl get agentruntime输出:NAME           AGEmy-agent-app   1m说明部署成功，my-agent-app为我们创建的Agent的名字。与Agent进行对话创建python脚本chatToAgent.py：from agentcube.agent_runtime import AgentRuntimeClientimport osimport timeROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def test_conversation():    # 第一轮对话    agent_client1 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0    )    # 记录会话ID，后续对话复用    session_id = agent_client1.session_id    result = agent_client1.invoke(        payload={"prompt": "Introduce yourself"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第二轮对话    agent_client2 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client2.invoke(        payload={"prompt": "What can you do?"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第三轮对话    agent_client3 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client3.invoke(        payload={"prompt": "Write a Python function for me"},    )    print(f"response: {result}\n")if __name__ == "__main__":    test_conversation()上述python脚本首先创建了一个对话，对话的对象是上一步创建的my-agent-appAgent应用，然后连续发起3次对话。输出如下：2026-06-05 16:33:28,396 | INFO | agentcube.agent_runtime | Bootstrapping AgentRuntime session...2026-06-05 16:33:29,771 | INFO | agentcube.agent_runtime | AgentRuntime session created: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Introduce yourself', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:29.839193', 'original_prompt': 'Introduce yourself'}2026-06-05 16:33:30,812 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: What can you do?', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:30.912573', 'original_prompt': 'What can you do?'}2026-06-05 16:33:31,886 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Write a Python function for me', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:31.989551', 'original_prompt': 'Write a Python function for me'}可以看到3次对话的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个AgentRuntime实例。  总 结  AgentCube 以极速启动、高效调度、原生会话管理、安全隔离四大核心能力，补齐了 K8s 集群承载 AI Agent 工作负载的短板。华为云 CCE 将持续集成 AgentCube ，为用户打造低延迟、高吞吐、强隔离的高性能 AI Agent 运行底座。 相关链接[1] AgentCube GitHub仓库: cid:link_7[2] Volcano官网: https://volcano.sh[3] AgentCube设计文档: cid:link_3[4] Kubernetes 跑 AI Agent，缺的不只是算力——AgentCube 补上了什么: cid:link_6[5] Python SDK: cid:link_4[6] 华为云CCE控制台: cid:link_1[7] AgentSandbox: cid:link_5[8] 华为云分布式缓存服务 DCS: cid:link_2[9] Agent示例代码: cid:link_0 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

随着批量训练、推理、AI Agent、HPC、大数据等多种负载在同一Kubernetes集群中混合部署，调度器需要在资源竞争更加激烈的环境下做出更高质量的决策，同时保持作业级语义、队列公平性、拓扑亲和性与运行稳定性。Volcano v1.15.0 现已正式发布，围绕这些方向，在调度核心、异构资源管理、多调度器协同与性能可观测等方面进行了增强。本次最值得关注的新增能力是 Gang-Aware Preemption and Resource Reclamation：抢占决策在抢占方与被抢占方两侧均以Gang为整体进行评估——抢占方按Gang整体进行放置，被抢占候选者同样按Gang粒度进行排序和评估，优先驱逐冗余副本，避免逐Pod随机驱逐打断多个训练任务而抢占方自身仍无法启动的情况。此外，v1.15.0在capacity插件中引入了DRA队列配额，新增了可插拔的多分片策略框架以及Benchmark与性能可观测工具，支持Kubernetes 1.35，并在NodeGroup调度优先级、Agent Scheduler稳定性、GPU/vGPU及队列准入控制等方面做了补充增强。Release Note: cid:link_11  Volcano v1.15.0 版本亮点  本次发布主要围绕以下方向展开：Gang-Aware Preemption and Resource Reclamation：以Job/Gang为粒度组织被抢占候选，区分冗余副本与关键副本，优先驱逐冗余副本减少任务扰动，并在驱逐前模拟整体放置确认抢占方能成功启动，避免逐Pod抢占打断多个训练任务而抢占方自己也无法运行的情况。DRA Queue Quota：capacity插件将DRA ResourceClaim纳入Volcano现有的队列容量模型，让DRA设备资源也能通过队列配额管理。Pluggable Multi-Sharding Policy：Sharding Controller支持通过ConfigMap组合多种分片策略，并支持运行时热加载。Volcano Benchmark框架：提供一键化性能测试环境搭建和报告输出，支持Kind/KWOK及已有集群。Scheduling Gates for Queue Admission：区分"队列配额不足"和"集群资源不足"，避免autoscaler因队列限额触发不必要的扩容。此外，v1.15.0还包含Kubernetes 1.35支持、NodeGroup preferred ordering、Agent Scheduler稳定性增强、GPU/vGPU增量增强以及安全修复。它们会在后文简要介绍，对生产可用性和生态兼容性同样重要。  重点特性  ▍1. Gang-Aware Preemption and Resource Reclamation（Alpha）在大模型训练、HPC等分布式任务中，一个Job往往需要多个Pod同时运行才有意义。如果抢占只按单个Pod进行决策，就可能从多个正在运行的训练任务里各抢一个Pod——表面上释放了资源，实际上既把多个任务都打断了，发起抢占的Gang也未必能凑齐minAvailable成功启动。v1.15.0引入Gang-Aware Preemption and Resource Reclamation，让抢占方和被抢占方在决策时都以Gang为整体来考量，避免出现"释放了一堆Pod，但谁都没跑起来"的情况。在被抢占方一侧，Volcano以Job/Gang为粒度组织被抢占候选，而不是把所有Pod看成可互换的抢占对象。每个候选Job的Pod被区分为冗余副本（超出minAvailable的部分）和关键副本，调度器优先选择冗余副本——驱逐它们不会打断任务——尽量避免触碰关键副本。这与原有action逐Pod选择、不区分破坏代价的方式有本质区别。在抢占方一侧，调度器逐步累计可释放的资源，当累计量足以覆盖抢占方Gang的整体需求时，先做放置模拟——在释放后的资源视图上验证抢占方Gang能否整体调度成功——只有模拟通过才真正执行驱逐。这样不会出现"抢了一堆Pod结果抢占方还是起不来"的情况。不论是否启用HyperNode拓扑，这套机制都能减少随机抢占带来的任务扰动。启用HyperNode拓扑后，Volcano还会将victim搜索限定在选定的拓扑范围内，避免跨拓扑域抢占。该特性目前为Alpha，需要显式配置gangPreempt和gangReclaim两个新的action。后续版本会继续评估是否将Gang-Aware驱逐机制与原有preempt、reclaim action合并。配置示例：actions: "enqueue, allocate, backfill, gangPreempt, gangReclaim"tiers:- plugins:  - name: priority  - name: gang  - name: drf  - name: predicates  - name: nodeorder - name: binpack相关资料：相关PR：cid:link_13,  cid:link_14,  cid:link_15设计文档：Gang-Aware Eviction Design:cid:link_5设计文档：EvictableFn Evolution for Gang Eviction:cid:link_2感谢社区开发者：@vzhou-p▍2. DRA Queue QuotaKubernetes Dynamic Resource Allocation（DRA）为设备资源申请提供了更灵活的模型。此前版本的Volcano已经支持调度使用DRA资源的Pod，但队列quota尚未覆盖DRA ResourceClaim。v1.15.0在capacity插件中补齐了这一能力，将DRA资源纳入Volcano已有的队列配额体系。用户仍然可以使用capability、deserved、guarantee容量模型管理队列资源，无需为DRA单独维护一套quota API。目前支持两类资源管控：基于DeviceClass的整卡/整设备数量配额基于可消费设备维度的配额，如虚拟GPU core、显存等当多个Pod引用同一个共享ResourceClaim时，Volcano会自动去重，避免同一份资源被重复计入队列用量。这样，集群管理员可以用同一套队列容量模型统一管理CPU、内存、扩展资源以及DRA设备资源。配置示例：tiers:- plugins:  - name: capacity    arguments:      capacity.DynamicResourceAllocationEnable: true      capacity.DRAConsumableCapacityEnable: trueapiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: ml-teamspec:  capability:    cpu: "100"    memory: "200Gi"    "deviceclass/gpu.nvidia.com": "8"    "cores.deviceclass/hami-core-gpu.project-hami.io": "800"    "memory.deviceclass/hami-core-gpu.project-hami.io": "320Gi"相关资料：相关PR：cid:link_16设计文档：DeviceClass Quota Support in Capacity Plugin:cid:link_7使用文档：DeviceClass Quota User Guide:cid:link_6感谢社区开发者：@xu-wentao▍3. Pluggable Multi-Sharding Policy（Alpha）在多调度器架构下，不同调度器通常面向不同类型的工作负载，对候选节点的范围也有不同要求。v1.15.0对Sharding Controller进行了增强，支持以可插拔的策略流水线组合多种分片逻辑。每个scheduler shard可以配置一组有序的策略，覆盖filter、score、select等阶段。内置策略包括：allocation-rate：根据节点资源利用率进行过滤和打分warmup：优先处理warmup节点node-limit：限制每个shard的节点数量范围策略通过ConfigMap配置，支持运行时热加载。如果新配置校验失败，系统会沿用上一份有效配置，避免线上变更引入风险。这让多调度器的节点分片能够更灵活地适配不同集群规模和业务类型，也为后续扩展更多sharding policy提供了清晰的接口。配置示例：custom:  sharding_configmap_enable: true  sharding_configmap_data: |    schedulerConfigs:      - name: volcano        type: volcano        policies:          - name: allocation-rate            weight: 1            arguments:              minCPUUtil: 0.0              maxCPUUtil: 0.6          - name: node-limit            arguments:              minNodes: 1              maxNodes: 100      - name: agent-scheduler        type: agent        policies:          - name: allocation-rate            weight: 1            arguments:              minCPUUtil: 0.7              maxCPUUtil: 1.0          - name: warmup            weight: 2相关资料：相关PR：cid:link_17, cid:link_18, cid:link_19使用文档：How to Configure Sharding via ConfigMap: cid:link_3感谢社区开发者：@lixmgl, @agrawalcodes▍4. Volcano Benchmark框架调度器的性能优化离不开稳定、可复现的测试基线。v1.15.0新增了Benchmark框架，支持一键部署测试环境、运行标准场景并输出性能报告。该框架支持两类环境：本地Kind + KWOK环境，用于开发者快速复现和分析调度性能问题已有Kubernetes集群，用于用户在真实环境中评估Volcano的调度吞吐和延迟测试场景覆盖VolcanoJob Gang调度、普通Pod调度、KWOK拓扑标签、HyperNode生成等，配合scheduler/controller metrics、audit-exporter报告和Grafana dashboard，可以帮助快速定位调度性能瓶颈。对于新接触Volcano的用户，也可以借助该框架在自己的集群中运行一轮测试，快速了解实际的调度吞吐和延迟表现。使用示例：cd benchmarkmake setup VOLCANO_VERSION=v1.15.0make test-gang-env JOBS=10 REPLICAS=100 MIN_AVAILABLE=100make cleanup-all相关资料：相关PR：cid:link_20, cid:link_21, cid:link_22,  cid:link_23使用文档：Benchmark README:cid:link_9感谢社区开发者：@JesseStutler, @3th4novo▍5. Scheduling Gates for Queue Admission（Alpha）当Pod因为队列容量不足而无法调度时，Cluster Autoscaler或Karpenter可能将这些Pod误判为集群资源不足，从而触发不必要的扩容。v1.15.0引入Scheduling Gates for Queue Admission。用户通过annotation为Pod开启后，当队列容量不足时，Volcano会通过Kubernetes原生的schedulingGates机制阻止Pod进入调度，使其对autoscaler不可见，从而不会触发扩容。等队列释放出容量后，Volcano再移除gate，Pod恢复正常调度流程。这样可以有效区分"队列配额不足"和"集群资源不足"两种情况，避免因队列quota限制导致的无效扩容。该特性目前为Alpha，需要同时在scheduler和webhook-manager中开启SchedulingGatesQueueAdmission。配置示例：helm install volcano volcano/volcano --namespace volcano-system --create-namespace \  --set custom.scheduler_feature_gates="SchedulingGatesQueueAdmission=true" \  --set custom.admission_feature_gates="SchedulingGatesQueueAdmission=true"apiVersion: v1kind: Podmetadata:  name: queue-gated-pod  annotations:    scheduling.volcano.sh/queue-allocation-gate: "true"spec:  schedulerName: volcano  containers:  - name: worker    image: nginx相关资料：相关Issue：cid:link_12相关PR：cid:link_25/pull/5033,cid:link_24设计文档：Gate-Controlled Scheduling for Cluster Autoscalers Compatibility: cid:link_4使用文档：How to Use Scheduling Gates for Queue Admission: cid:link_1感谢社区开发者：@devzizu  其他值得关注的增强  ▍Kubernetes 1.35支持v1.15.0更新了Kubernetes依赖、生成代码、fake client、informer、volumebinding集成、CI/lint工具链以及兼容性文档，支持Kubernetes 1.35。▍NodeGroup preferred orderingNodeGroup plugin新增enablePreferredOrder，Queue中preferredDuringSchedulingIgnoredDuringExecution的顺序会影响调度打分。靠前的NodeGroup会获得更高分数，适合“优先使用固定资源池，资源不足时再fallback到弹性资源池”的场景。配置示例：tiers:- plugins:  - name: nodegroup    arguments:      enablePreferredOrder: trueapiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: bigdataspec:  affinity:    nodeGroupAffinity:      preferredDuringSchedulingIgnoredDuringExecution:      - spark-fixed      - spark-serverless相关配置可参考：cid:link_0▍Agent Scheduler稳定性增强v1.15.0修复了Agent Scheduler多worker乐观并发冲突、共享action实例复用framework/cycle state、CSI manager注册缺失、binder节点优先级处理以及E2E duration metric等问题，并补充了相关E2E覆盖。这些修复主要提升了延迟敏感型AI Agent工作负载的调度稳定性。▍GPU/vGPU增量增强v1.15.0对deviceshare plugin做了多项增强，包括GPU exclusive支持、vGPU preemption支持，以及在不允许共享时避免同一PodGroup内的Pod使用同一张物理vGPU设备。▍安全修复v1.15.0包含webhook request body size mitigation，用于修复CVE-2026-44247相关的拒绝服务风险。该修复限制admission webhook请求体大小，避免超大请求导致webhook server内存耗尽。  总 结  Volcano v1.15.0的核心变化是Gang-Aware Preemption and Resource Reclamation，将抢占决策从逐Pod粒度提升到Gang粒度，在抢占方与被抢占方两侧同时进行整体性评估，减少分布式训练场景下因随机驱逐导致的连锁任务失败。DRA Queue Quota将DRA设备资源纳入已有的队列容量模型，使异构资源与CPU、内存在配额管理上保持一致。Pluggable Multi-Sharding Policy、Benchmark框架与Agent Scheduler稳定性修复，则分别完善了多调度器协同、性能基线建立与延迟敏感负载调度方面的工程能力。Volcano将继续面向AI训练、推理、Agent、HPC与大数据等混合部署场景，持续完善统一调度平台的调度能力与工程质量。  升级注意事项 可以通过Helm或YAML方式升级到v1.15.0：helm repo updatehelm upgrade volcano volcano-sh/volcano --version 1.15.0kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/v1.15.0/installer/volcano-development.yaml当前Gang-Aware Preemption and Resource Reclamation特性为Alpha阶段，需要显式配置gangPreempt和gangReclaim两个新的action。当前不推荐在同一个scheduler action list中同时配置新的gangPreempt/gangReclaim和旧的preempt/reclaim action。Scheduling Gates for Queue Admission为Alpha，需要同时在scheduler和webhook-manager中开启。DRA scheduling integration默认开启，以对齐Kubernetes 1.34+的DRA默认行为。如需关闭，可设置predicate.DynamicResourceAllocationEnable: false。DRA Queue Quota依赖Kubernetes DRA支持和可用的DRA driver。  参考链接  本文重点介绍v1.15.0的主要能力。完整的API Changes、Bug Fixes、依赖更新、测试与维护项和贡献者列表，请参考正式Release Note及相关文档。Release Note: cid:link_11Full Changelog: cid:link_10  致 谢  Volcano v1.15共有43位社区贡献者参与。衷心感谢每一位贡献者，是你们的努力让Volcano不断进步，成为更强大、更稳定的统一调度平台！  🌋 Volcano 是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.6k+ Star 和 1.3K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。欢迎参与社区贡献：Volcano官网： https://volcano.sh GitHub: cid:link_25 每周例会：https://zoom.us/j/91804791393关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

由Linux Foundation组织的LFX Mentorship计划[1]，从2019年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。该项目往年已获2w+申请，发起2000+课题，毕业实习生1400+，发放超过380万美金报酬。LFX Mentorship 2026 夏季(Term 2）申请时间为5月5日 – 5月19日（11:00 PDT；18:00 UTC)，远程实习将从 6 月 8 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为3000美金，约合20000人民币）。Volcano社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者即日起可前往官方平台申请（在校/在职符合条件可）:https://mentorship.lfx.linuxfoundation.org/  Volcano 社区介绍  Volcano 是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.5k+ Star 和 1.3K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。社区地址：🌋 https://github.com/volcano-sh在LFX Mentorship 2026夏季计划，Volcano期待与你协作开拓AI大数据、LLM大模型推理等场景调度的更多可能。  面 向 对 象 本期计划申请者需2026年5月19日前在LFX官网[1]完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下为开源项目做出贡献。依据官方规定，对Mentee申请者有以下要求[2]:在参加该计划时您至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026 年 Term2 申请及实习流程如下：Mentee注册与项目申请：5月5日-5月19日（11:00 AM PDT/18:00 UTC)申请者审核期： 5月20日-6月2日（11:00 AM PDT/18:00 UTC)申请者入选通知：6月3日实习正式开始：6月8日中期考核：7月21日（11:00 AM PDT/18:00 UTC)首次津贴支付：7月22日结项考核、实习报告提交：8月25日（11:00 AM PDT/18:00 UTC)最终津贴支付批准：8月26日本期结束最终日期：8月31参与者如有意向如何申请？流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在6 月 3 日通知到申请人。主线开发日期为2026年6月8日-8月25日，全程线上协作，无需线下参与。结项需要在2026年8月25日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  Volcano 项目课题  欢迎各位申请者申报CNCF Volcano社区课题：▍支持 Namespace 级别的 Queue课题描述：Volcano 当前的 Queue 是集群级别的资源，只有集群管理员才有权限创建和修改。这在多租户场景下对普通租户不太友好：租户通常只拥有自己 namespace 下的权限，但也想用上 Queue 提供的能力（资源共享、capability/guarantee/deserved、队列层级等）来管理自己的作业，而不是每改一次都要依赖集群管理员。本课题会在 Volcano 中引入 namespace 级别的 NamespaceQueue。NamespaceQueue 从 cluster 级别的 Queue 派生，语义和使用方式与 cluster Queue 保持一致，租户可以直接在自己的 namespace 下创建和管理队列，并像使用 cluster Queue 一样把 PodGroup/Job 关联到 NamespaceQueue 上进行调度。对不使用这个特性的用户，原有 cluster Queue 的行为和 API 完全不受影响。预期产出：新增 namespace 级别的 NamespaceQueue CRD，从 cluster 级别的 Queue 派生，capability/guarantee/deserved、队列层级等字段语义保持一致租户不需要集群管理员权限，就能在自己 namespace 下创建和管理 NamespaceQueuePodGroup/Job 支持引用 NamespaceQueue，调度行为与引用 cluster Queue 一致NamespaceQueue 的资源统计、status、事件等能够正常工作与原有 cluster Queue 和 scheduling.volcano.sh/queue-name annotation 兼容，老用户可以平滑迁移覆盖核心流程和异常场景的 E2E 测试Volcano 官网和代码仓库的用户文前置技能：GoKubernetes（CRD、controller、RBAC）熟悉 Volcano（scheduler、queue、PodGroup/Job 等）E2E 测试（Ginkgo）GitHub workflow 与 shell 脚课题导师：Zicong Chen（@JesseStutler ）jessestutler97@gmail.comHajnal Máté （@hajnalmt）hajnalmt@gmail.comJoão Azevedo （@devzizu）jazevedo960@gmail.com原始Issue：cid:link_2/issues/5251课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/9e582ac4-4e12-4fcc-a1cd-27855d79730a▍Kthena Router 支持第三方模型 API课题描述：目前 Volcano/Kthena Router 已经能够很好地支持集群内部的路由能力。但在与用户的交流中,部分用户提出希望能够对接外部的大语言模型 API。因此,Kthena 社区计划借助本期 LFX,让 Router 具备访问第三方 LLM API 的能力。预期结果：设计提案(Proposal)代码实现(包含单元测试;如能补充端到端测试更佳。但考虑到外部 LLM API 通常不会提供长期、稳定的免费访问,端到端测试不作为强制要求)用户指南及相关文前置技能：Go、Kubernetes、网络、LLM课题导师：Zengzeng Yao（@yaozengzeng ）yaozengzeng@huawei.com原始Issue：cid:link_3/issues/939课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/baa6fb1f-58c9-4255-849c-21aca35ce5e1▍Kthena Router 性能基准测试(Benchmark)课题描述：Kthena Router 是 Volcano/Kthena 项目中的 LLM 路由组件,负责将推理请求转发到集群内(以及即将支持的)第三方模型后端。随着 Kthena 逐步走向成熟,社区需要一套可复现的基准测试,用来在真实的 LLM 流量模式下衡量 Router 的性能特征(吞吐、延迟、TTFT、资源占用),并在版本迭代中及时发现性能回退。本项目希望设计并实现一套面向 Kthena Router 的基准测试框架,产出完整的测试报告。如果在过程中发现明显的瓶颈或可优化点,还需要与 Maintainer 协作,将代码层面的优化合入上游。预期产出：一套可复用的 Kthena Router 基准测试框架(压测客户端、场景配置、指标采集、结果汇总),可在本地乃至 CI 中运行。一组覆盖典型 LLM 路由模式的测试场景(不同的 QPS、prompt/response 长度、并发数、后端数量、路由策略等)。端到端测试流程文档化为 runbook(集群准备、mock/真实后端、运行方式、结果解读)。一份基准测试报告,包含吞吐、TPOT、TTFT、GPU/CPU/内存等指标,以及瓶颈分析。针对识别到的明显瓶颈进行优化并提交上游 PR,附上优化前后的性能对比数据前置技能：Go、Kubernetes、性能基准测试与性能剖析(pprof)、对 LLM 推理及 HTTP/gRPC 路由有基本了解。课题导师：Zengzeng Yao（@yaozengzeng ）yaozengzeng@huawei.comZhonghu Xu （@hzxuzhonghu ）zhhxu2011@gmail.com原始Issue：cid:link_3/issues/942课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/1cf34cb5-3520-4f15-81c8-4258cb9abcb9▍支持多 AgentCube 协同能力课题描述：目前, Volcano社区AgentCube项目 在 Code Interpretation和 Agent Runtime场景下都只会拉起单个 Agent。然而,当前我们已经进入多 Agent 协作的时代。因此,AgentCube 计划支持多 Agent 编排,使多个 Agent 能够围绕同一个任务进行协作,并由 AgentCube 统一管理这些 Agent 的生命周期。预期结果：设计提案(Proposal)代码实现(包含单元测试和端到端测试)用户指南及其他相关文前置技能：Go、Kubernetes、Agent课题导师：Zhonghu Xu （@hzxuzhonghu ）zhhxu2011@gmail.com原始Issue：cid:link_1/issues/301课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/9e7dd1c1-5d14-4c5e-af43-83454099e490更多Volcano课题，请访问LFX Mentorship官网[1]；对课题感兴趣/有任何问题，欢迎直接向课题导师发送邮件或在GitHub仓库提交Issue提问。今年夏季，Volcano社区期待在 LFX Mentorship 见到您！ 附：相关指引链接[1] LFX Mentorship计划官网及申报入口: https://mentorship.lfx.linuxfoundation.org/#projects_all[2] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible[3] LFX Mentorship - Program Readme: cid:link_0[4] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply[5] Volcano GitHub: cid:link_2[6] Volcano/Kthena GitHub: cid:link_3[7] Volcano/AgentCube GitHub: cid:link_1 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入Volcano技术交流群

在刚刚闭幕的 KubeCon + CloudNativeCon Europe 2026 上，全球开源精英与产业力量齐聚阿姆斯特丹，共同见证了云原生领域的又一次浪潮。本届大会以“Keep Cloud Native Moving”为主题，传递出一个清晰的信号：云原生已远超资源编排的范畴，正加速进化为AI——尤其是LLM与Agentic AI——的核心运行底座。  开放创新，共建面向 Agentic AI 的智能原生基础设施  作为 CNCF 的持续贡献者与全球云原生产业的引领者，华为云本次参会以 “Powering the Agentic Future” 为核心主旨，全方位展示了面向 Agentic AI 的“智能原生”基础设施开源创新与产品方案。通过多场深度技术演讲、沉浸式展区互动以及前沿技术研讨，华为云向全球开发者系统分享了在 AI 全生命周期管理、大规模异构算力调度、分布式推理流量治理、高性能服务网格等关键方向上的技术突破与实践经验，共同码写云原生在智能时代的新篇章。▍Volcano：从 AI 全生命周期调度到 Agent 韧性底座随着 Agentic AI 的兴起，基础设施面临着从“作业调度”向“复杂智能体编排”的转变。作为业界顶尖的云原生AI调度引擎，Volcano 构建从大规模训练到 Agent 编排的 AI 全生命周期调度底座，并于 2025 年重点推出了 面向 LLM 推理的 Kthena 与 面向 AI Agent 工作负载的高性能编排层 AgentCube 两个备受瞩目的子项目，在技术层面高性能适配 Agentic AI 应用要求。在工作负载层：Volcano-Global 将海量训练作业拆分到多个集群，突破了单集群的限制；Kthena 提供企业级 LLM 服务，并支持 vLLM 等框架；AgentCube 快速实现Agent工作负载调度。在基础设施层，Volcano 通过 DRA 集成、HyperNode 发现、GPU 共享和异构池化，提供现代化的资源抽象，实现高效的任务到加速器映射。▲ Breaking the Monolith: Decomposing and Governing Giant LLM Jobs Across Clusters - Kevin Wang, Huawei通过打通完整 AI 生命周期的统一调度能力，Volcano 提供强大的调度能力和高吞吐量，能够协调各种工作负载，超越批处理作业的限制，实现多调度器协同，高效应对人工智能快速发展过程中的训练、推理和 Agent 工作负载运行在孤立的系统中造成的资源效率低等难题。这不仅是调度算法的优化，更是云原生 AI 基础设施的一次范式重构，为 Agentic Future 提供了稳健、高效的运行动力。▲ 华为云开源技术专家 Zhonghu Xu（上）、Zicong Chen(左）、ZengZeng Yao（右）发表Volcano及Kthena、AgentCube 议题更多Volcano议题演讲精彩内容，欢迎关注后续技术解析。▍Karmada：跨越云端边界，构建面向 AI 的多集群管理架构本届大会，来自华为云的 Karmada 维护者 Hongcai Ren 等组织了专场 Project Meeting ，与开发者与用户深度探讨了多集群扩展性、工作负载分发及社区发展路标，强化了分布式云原生的协作生态。携手Bloomberg、携程等生产用户，Karmada 社区也在分论坛上分享了社区过去一年的关键演进。Karmada 正在从“多集群管理工具”进化为“多集群AI编排底座”：应用优先级调度、联邦资源配额、有状态应用故障迁移等能力持续增强生产级稳定性；AI 作业调度增强与 Volcano Global 的协同，则为超大规模 LLM 任务的跨集群拆分与统一调度提供了坚实基础。同时，Karmada Dashboard 正式发布、Operator 能力持续增强，显著提升了多集群场景的可观测性与运维体验。▲ Karmada 社区专场会议与议题演讲在 ArgoCon 论坛上，华为云开源技术专家联合用户伙伴分享了 Karmada 与 Argo 生态整合的最佳实践。针对混合云多集群场景下渐进式交付缺乏全局协调能力的痛点，他们展示了如何通过 Karmada 与 Argo CD、Argo Rollouts 的整合，构建“定义一次，安全交付到任意集群”的统一平台。通过金丝雀发布示例，现场演示了集成架构与完整工作流，既保留了 Argo 在单集群渐进式交付的成熟能力，又借助 Karmada 的跨集群编排能力，将渐进式交付扩展至全局多集群。该方案已在生产环境中验证，为企业多云应用交付提供了可复用的实践范本。▲ From Canary To Global: Unified Progressive Delivery for Hybrid Cloud With Karmada & Argo - Zhuang Zhang, Huawei & Karmada PartnerKarmada 的成熟度与可靠性已在 Bloomberg、携程等复杂生产环境中得到充分验证，社区用户组成员突破40+。未来，Karmada 社区将持续聚焦 AI 工作负载的跨集群编排能力，与 Volcano、Kueue 等项目深度协同，共同构建面向AI多集群场景的统一管理与控制面▍Kmesh：基于 Rust 的数据面创新，引领Sidecarless服务网格服务网格的性能开销一直是大规模分布式系统痛点，尤其是在对时延极其敏感的 AI 推理场景中。Kmesh 独辟蹊径地采用了内核级、Sidecarless 的架构。通过将服务治理逻辑下沉至 OS 内核（基于 eBPF 技术），Kmesh 实现了近乎零开销的网络转发，极大地降低了服务间通信的时延。▲ Optimize Sidecarless Service Mesh With A Brand-New Rust-Based Proxy - Zengzeng Yao, Huawei Cloud；Kmesh Maintainer华为云开源技术专家分享了在 Kmesh 社区的技术创新成果。针对现有 Sidecarless 服务网格方案中 L7 流量处理依赖 Envoy waypoint 所带来的性能瓶颈与内存管理难题，包括不可预测的内存泄漏和生产环境调试复杂性。Kmesh 引入基于 Rust 重构的 Orion，作为 waypoint 与 Kmesh 深度集成后，Orion 与 Kmesh 的 eBPF L4 处理能力形成合力，构建了覆盖 L4 与 L7 的统一高性能 Sidecarless 服务网格。这一方案既延续了 Kmesh 在 L4 层的极致性能优势，又通过 Rust 的安全内存模型解决了 L7 代理在长期运行中的稳定性隐患，为服务网格在AI时代高吞吐、低延迟场景下的规模化落地提供了全新路径。▍边缘智算引擎，KubeEdge 赋能万物智能正如会上的演讲议题“KubeEdge Everywhere: From Graduation to Global Adoption”，KubeEdge 的行业应用近年来呈爆炸式增长。作为首个从 CNCF 毕业的云原生边缘项目，KubeEdge 自 2024 年晋级后，社区的功能更新、治理更新以及实践案例，充分验证了在边缘 AI 和行业工作负载管理方面的强大性能，其强大的边云协同能力，为千行百业的智慧场景提供了可落地的云原生边缘基础设施技术方案。来自DaoCloud、谐云、Google、华为云的技术专家共建了 KubeEdge 系列议题，与此同时，KubeEdge  Project Pavilion 吸引了大量关于边缘 AI 落地场景的讨论。▲ KubeEdge 应用于大会 Keynote 议题演讲中的滑翔机  展区零距离——智算引擎全栈体验  在华为展台，华为云向与会者展示了面向 Agentic AI 时代的智能原生基础设施解决方案。展区围绕 Agentic AI 基础设施与开发者展开深度互动，通过全新一代 CCE 智算集群、华为云 Agent 全栈平台、华为云容器领导力等产品与内容展示，呈现了从云原生基础设施到 AI 时代工作负载最佳运行底座的全栈能力，共同探讨智能原生未来图景。同时，华为云技术团队也分别在 Volcano、Karmada、Kmesh 等多个项目展台驻场，从多集群编排到AI调度，从服务网格到K8s生态，通过现场答疑、案例讲解与代码演示，与开发者进行开源技术创新与应用的面对面深度技术交流。作为云原生与 AI 领域的先驱者，华为云深耕 Kubernetes 等核心技术十余年，在 AI 浪潮中打造面向未来的AI原生基础设施，构建 AI Infra、Agent Infra 等算力底座，支撑 AI 大模型与 Agent 智能体应用需求。凭借多年来的产业实践和技术创新，华为云连续5年蝉联国内容器软件市场份额 TOP1，获选 Gartner 容器管理魔力象限领导者，Omdia 产品战略与执行全球第一，技术实力获全球权威认可。  Powering the Agentic Future  这场阿姆斯特丹的思想碰撞，是云原生基础设施与 Agentic AI 的一场“双向奔赴”；云原生底层逻辑正在升级重塑，成为支撑智能时代运行的“数字神经系统”。在迈向 Agentic Future 的征途中，我们将持续开放创新，让算力更高效、让治理更简洁、让智能更无处不在。期待与全球开源力量并肩，在智能原生的时代浪潮中，跑出加速创新的时代脚步。 更多云原生技术动向关注容器魔方

 ▍1. 前言随着大语言模型（LLM）日益成为现代应用的核心，支持它们的基础设施必须不断演进，以满足苛刻的性能、可扩展性和成本要求。在生产环境中部署 LLM 面临着独特的挑战：模型需要大量资源，推理工作负载变化显著，用户期望低延迟和高吞吐量。传统的负载均衡器和 API 网关虽然在传统 Web 服务中表现出色，但缺乏智能路由 AI 推理流量所需的感知能力。Kthena[1] Router 正面应对这些挑战。它是一个 Kubernetes 原生的独立推理Router，专为 LLM 服务工作负载而设计。与通用代理或负载均衡器不同，Kthena Router 具有模型感知能力，根据推理引擎的实时指标做出智能路由决策。这使得其能够实现复杂的流量管理策略，显著提高吞吐量、降低延迟并降低运营成本。Kthena Router 能够与现有 API 网关基础设施无缝集成，同时提供专为 AI 工作负载设计的高级功能：模型感知路由：利用推理引擎（vLLM、SGLang、TGI）的实时指标做出智能路由决策LoRA 感知负载均衡：智能路由到已加载所需 LoRA Adapter 的 Pod，将数百毫秒的 Adapter Swap 延迟降低到接近零高级调度算法：包括Prefix Cache感知、KV Cache感知和公平性调度等PD分离：原生支持 xPyD（x-prefill/y-decode）部署模式Kthena Router 作为独立二进制文件部署，极简依赖，确保轻量级运行和简单部署。它持续监控推理引擎指标，以获取有关模型状态的实时信息，包括当前加载的 LoRA Adapter、KV Cache 利用率、请求队列长度和延迟指标（TTFT/TPOT）。这种实时感知能力使 Router 能够做出传统负载均衡器根本无法实现的最优路由决策。▍2. 架构Kthena Router 实现了一个清晰的模块化架构，专为性能和可扩展性而设计。该系统由几个核心组件协同工作，提供智能请求路由。Kthena Router 架构2.1 核心组件概述Router： 负责接收、处理和转发请求的核心执行框架。它协调所有其他组件之间的交互，并维护从初始接收到最终响应的请求生命周期。Listener： 管理 HTTP/HTTPS 监听器并处理指定端口上的传入流量。它为不同协议提供灵活的配置，并可以绑定到多个地址以服务各种类型的请求。监听器确保高效的连接处理，并支持流式和非流式请求模式。Controller： 一个 Kubernetes 原生组件，用于同步和处理 Pod 和自定义资源（CR），例如 ModelRoute 和 ModelServer。Controller监视集群中的变化，并相应地更新Router的内部状态，确保路由决策始终基于当前的集群拓扑。Filters： 包含两个关键子模块，在请求到达后端之前处理请求：Auth：处理流量认证和授权，支持 API Key、JWTRateLimit：管理全面的速率限制策略，包括输入token和输出token限制Backend： 提供访问各种推理引擎的抽象层。它掩盖了不同框架（如 vLLM、SGLang 和 TGI）之间Metrics接口访问方法和Metrics命名约定的差异，向调度器提供统一的接口。Metrics Fetcher： 持续从模型 Pod 上运行的推理引擎端点收集实时Metrics。它收集关键性能数据，包括：KV Cache利用率当前加载的 LoRA Adapter请求队列长度延迟指标（TTFT，TPOT）Datastore： 一个统一的数据存储层，提供对 ModelServer 到 Pod 关联、Base Model/LoRA 配置和运行时Metrics的高效访问。它作为所有路由相关信息的中央存储库，并支持实时更新的回调。Scheduler： Router的大脑，实现复杂的流量调度算法。它由一个调度框架和各种可插拔的调度算法插件组成。该框架集成并运行不同的调度插件，以过滤和评分与 ModelServer 对应的 Pod 集合，选择全局最优的 Pod 作为最终访问目标。Kthena Router 组件▍3. Router APIKthena Router 的路由行为由两个关键的自定义资源定义（CRD）控制：ModelServer 和 ModelRoute。这些声明式 API 允许您使用熟悉的 Kubernetes 模式定义复杂的路由策略。3.1 ModelRouteModelRoute 根据请求特征定义流量路由规则。它根据模型名称、LoRA Adapter、HTTP Header和其他条件确定哪些 ModelServer 应该处理请求。关键字段包括：ModelName：要在传入请求中匹配的模型名称LoRAAdapters：此路由支持的 LoRA 适配器名称列表Rules：有序的路由规则列表，每个规则包含：ModelMatch：匹配请求的条件（Header、URI 等）TargetModels：要路由到的 ModelServer 列表，可选权重RateLimit：基于token的速率限制配置有关 ModelRoute 的更多详细信息，请参阅 定义[2]。3.2 ModelServerModelServer 定义推理服务实例及其访问策略。它标识运行模型的 Pod，指定正在使用的推理框架，并定义如何处理流量。关键字段包括：WorkloadSelector：通过标签标识 Pod，并支持 PD（prefill-decode）组规范Model：指定服务器托管的Base Model名称InferenceFramework：指示推理引擎（vLLM、SGLang、TGI 等）WorkloadPort：定义推理服务监听的端口TrafficPolicy：配置超时、重试策略和其他流量处理行为KVConnector：为 PD 分离部署指定 KV Connector类型（HTTP、Nixl、LMCache、Mooncake）有关 ModelServer 的更多详细信息，请参阅 定义[3]。3.3 示例：基于HTTP Header的多模型路由对于分层服务产品，根据头将用户路由到不同大小的模型：apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelRoutemetadata: name: deepseek-multi-models namespace: defaultspec: modelName: "deepseek-multi-models" rules: - name: "premium" modelMatch: headers: user-type: exact: premium targetModels: - modelServerName: "deepseek-r1-7b" - name: "default" targetModels: - modelServerName: "deepseek-r1-1-5b"---apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelServermetadata: name: deepseek-r1-7b namespace: defaultspec: workloadSelector: matchLabels: app: deepseek-r1-7b workloadPort: port: 8000 model: "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B" inferenceEngine: "vLLM" trafficPolicy: timeout: 10s---apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelServermetadata: name: deepseek-r1-1-5b namespace: defaultspec: workloadSelector: matchLabels: app: deepseek-r1-1-5b workloadPort: port: 8000 model: "deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B" inferenceEngine: "vLLM" trafficPolicy: timeout: 10s流量处理过程：请求到达，模型名称为 "deepseek-multi-models"Router检查HTTP Header中是否存在 user-type: premium高级用户 → 路由到更大的 7B 模型以获得更好的质量普通用户 → 路由到更小的 1.5B 模型以提高成本效率测试高级路由：curl http://$ROUTER_IP/v1/completions \ -H "Content-Type: application/json" \ -H "user-type: premium" \ -d '{"model": "deepseek-multi-models", "prompt": "Explain quantum computing"}'这个示例演示了 ModelRoute 和 ModelServer CRD 如何通过标准 Kubernetes API 提供对复杂路由策略的灵活声明式控制。▍4. 核心功能4.1 智能调度插件真正将 Kthena Router 与传统负载均衡器区分开的是其一套模型感知调度插件。这些插件利用实时推理引擎指标做出智能路由决策，显著提高性能。4.1.1 LoRA 亲和性调度LoRA（低秩适应）Adapter 能够在不重新部署 Base Model 的情况下实现微调的模型行为。然而，加载和卸载 Adapter 会引入延迟。LoRA 亲和性插件通过智能路由最小化这种开销。工作原理：持续跟踪每个 Pod 上当前加载的 LoRA Adapter 状态将需要特定 LoRA 的请求优先路由到已加载该 Adapter 的 Pod通过缓存命中避免 Adapter 加载/卸载操作优势：消除 Adapter Swap 延迟: 将数百毫秒的 Adapter 切换延迟降至接近零提高响应速度: 避免动态加载 Adapter 带来的额外等待时间支持多 LoRA 场景: 高效处理多个 LoRA Adapter 的混合工作负载4.1.2 Least Latency 调度Least Latency 插件根据实时延迟指标将请求路由到响应最快的 Pod，优化用户体验和整体生成速度。工作原理：持续监控推理引擎的延迟指标综合评估 TTFT（首 token 时间）和 TPOT（每输出 token 时间）将请求路由到延迟最低的 Pod动态适应 Pod 性能变化关键指标：TTFT（首 token 时间）: 影响流式响应和用户感知延迟TPOT（每输出 token 时间）: 决定整体生成速度和吞吐量4.1.3 Least Request 调度Least Request 插件基于请求队列状态进行负载均衡，将请求路由到最不繁忙的 Pod，确保均匀的负载分布。工作原理：监控推理引擎的 num_requests_running 和 num_requests_waiting 指标计算每个 Pod 的总待处理工作负载（运行中 + 等待中）将新请求路由到负载最低的 Pod动态平衡各 Pod 之间的工作分配优势：防止热点: 避免部分 Pod 过载而其他 Pod 空闲均衡负载: 确保所有 Pod 的利用率趋于一致提高吞吐量: 通过最优负载分配最大化整体处理能力4.1.4 GPU Usage 调度GPU Usage 插件基于 GPU 缓存使用率进行负载均衡，将请求路由到缓存压力较小的 Pod，优化 GPU 资源利用率。工作原理：持续监控每个 Pod 的 GPU 缓存使用率指标计算可用缓存容量：score = (1.0 - GPU缓存使用率) × 100  优先将请求路由到 GPU 缓存使用率较低的 Pod避免因缓存耗尽导致的性能下降和请求失败优势：防止缓存溢出: 避免将请求发送到缓存已满的 Pod提高稳定性: 减少因缓存不足导致的请求失败和重试负载均衡: 确保 GPU 缓存资源在所有 Pod 间均衡使用提升吞吐量: 保持各 Pod 在最优缓存利用率区间运行4.1.5 Prefix Cache 感知调度现代推理引擎（如 vLLM 和 SGLang）实现 Prefix Cache 机制，将常用的 Prompt 前缀缓存起来以避免冗余计算。Prefix Cache 感知插件通过智能路由策略最大化前缀缓存的命中率，显著提升推理性能。核心机制：滚动哈希生成:将 Prompt 按固定大小（默认 64 字节）划分为块使用 xxHash 算法为每个块生成滚动哈希每个哈希值结合前一个块的哈希，形成依赖链哈希匹配时保证所有前置块也匹配，实现高效前缀识别内存缓存存储:使用三层映射结构：模型 → 哈希 → Pod采用 LRU（最近最少使用）缓存策略管理内存自动清理过期条目，保持缓存效率默认缓存容量 50,000 条，返回 Top-5 最佳匹配智能评分算法:根据前缀匹配长度对 Pod 评分评分公式：score = (匹配块数 / 总块数) × 100 优先选择具有最长匹配前缀的 Pod提高缓存命中率和推理效率适用场景：多轮对话系统，用户在同一 session 中发送多个相关请求具有固定 system prompt 的应用场景问答系统中频繁使用相同上下文的查询4.1.6 KV Cache Aware 调度KV Cache Aware 插件是一个高级调度插件,通过基于token级别的块匹配来智能路由请求,最大化 KV 缓存命中率。与简单监控缓存利用率不同,该插件实现了细粒度的内容感知调度,显著提升性能。核心机制：Token 块哈希:将传入的prompt分词后按固定大小(默认128个token)划分为块使用 SHA-256 为每个块生成标准化哈希值支持可配置的最大块数(默认128块)以平衡性能和准确性分布式缓存跟踪:使用 Redis 维护全局的块到 Pod 映射Redis key 格式: matrix:kv:block:{model}@{hash}  每个 key 存储包含该块的 Pod 列表及其缓存时间戳通过 Redis Pipeline 批量查询实现高效的分布式协调智能评分算法:查找每个token块在哪些 Pod 上已缓存从第一个块开始计算连续匹配长度优先选择具有最长连续匹配前缀的 Pod评分公式: score = (匹配块数 / 总块数) × 100Tokenizer 集成:支持多种tokenizer backend(本地和远程 vLLM)自动处理不同模型的分词差异确保一致的token到块的映射优势：精确匹配: 不仅考虑缓存容量,还考虑实际缓存的内容避免冷启动: 将请求路由到已经处理过相似prompt的 Pod提升吞吐量: 减少重复计算,在long system prompt场景下可实现 2.73 倍吞吐量提升降低延迟: TTFT 可降低 73.5%,显著改善用户体验更多技术细节请参考 KV Cache Aware 插件设计文档[4]。4.1.7 插件配置这些插件通过调度器框架协同工作。您可以通过Router配置来配置启用哪些插件及其相对权重。调度器框架按顺序运行启用的插件：Filter：插件过滤不合适的 Pod（例如，缓存不足、错误的 LoRA）Score：插件根据其条件对剩余 Pod 评分Select：为请求选择得分最高的 Pod这种可组合的架构允许您根据特定的工作负载需求定制路由行为。4.2 公平性调度公平性调度确保基于token消耗历史在用户之间公平分配资源。工作原理：跟踪每个用户每个模型的累积token使用量（输入 + 输出）分配与历史使用量成反比的请求优先级将请求排队并按优先级顺序处理防止任何单个用户垄断资源用例：具有共享基础设施的多租户平台具有公平共享策略的研究集群需要基于使用量的节流的 SLA 驱动系统4.3 PD分离支持对于高级部署模式，Kthena Router 原生支持PD分离（xPyD），其中计算密集型的Prefill阶段与token生成Decode阶段分离。工作原理：从 ModelServer CRD 识别 PD 组配置将Prefill请求路由到Prefill优化的 Pod通过可配置的连接器（HTTP、Nixl 等）传输 KV 缓存状态将Decode请求路由到Decode优化的 Pod对客户端透明地协调两阶段过程优势：通过将工作负载特征与硬件匹配来优化硬件利用率通过为每个阶段使用专用硬件来减少延迟通过更好的资源分配提高成本效率4.4 基于token的RateLimitKthena Router 提供全面的RateLimit功能，以保护您的推理基础设施免受过载，并确保跨用户的公平资源分配。Input token限制：控制每个用户或 API 密钥的传入prompt token速率Output token限制：限制生成的token以管理计算成本Local RateLimit：在每个Router实例基础上实施限制。Global RateLimit：使用 Redis 等中央存储在所有Router实例之间实施共享限制。4.5 可观测性Kthena Router 提供为生产 LLM 服务设计的全面可观测性功能：指标：在 /metrics endpoint公开详细指标，包括请求延迟、token消耗、调度器插件性能和RateLimit统计信息结构化访问日志：以 JSON 或文本格式记录完整的请求生命周期，包括路由决策、用时分布和token跟踪Debug endpoint：提供 /debug/config_dump/* API 来检查内部状态、ModelRoute/ModelServer 配置和实时 Pod 等指标标准集成：与 Prometheus、Grafana、ELK 等可观测性堆栈无缝协作，用于监控、告警和故障排除▍5. 性能Kthena Router 中的 ScorePlugin 模块利用可配置的可插拔架构来实现推理请求的多维评分和智能路由。为了演示智能调度的影响，我们基于 DeepSeek-R1-Distill-Qwen-7B 模型构建了一个标准化的基准测试环境，以评估不同调度策略在长短system prompt场景下的性能。实验结果表明，在long system prompt场景中，KV Cache Aware Plugin + Least Request Plugin 组合实现了 2.73 倍的吞吐量，并将 TTFT 延迟降低了 73.5%，显著优化了整体推理服务性能，验证了Cache感知调度对大规模模型推理的核心价值。5.1 实验设置使用 DeepSeek-R1-Distill-Qwen-7B 模型构建了标准化的基准测试环境，以评估不同调度策略的性能。表 1：实验环境配置5.2 Long System Prompt Scenario（4096 token）表 2：性能指标 - Long System Prompt ▍6. 结论Kthena Router 代表了 LLM 服务基础设施的重大飞跃。通过超越简单的负载均衡，实现模型感知、指标驱动的路由，它释放了以前无法实现的显著性能改进和成本节省。它是开源的，现在就可以使用。Kthena文档[5]提供了安装、配置和部署的全面指南。Kthena-router 示例目录[6]包含用于常见场景的即用型配置。无论您是运行单个模型还是管理复杂的多租户 LLM 平台，Kthena Router 都提供了最大化性能、最小化成本和提供卓越用户体验所需的智能路由功能。作者 | YaoZengzeng   相关链接[1] Kthena: https://kthena.volcano.sh/[2] ModelRoute 定义: cid:link_1[3] ModelServer定义: cid:link_2[4] KV Cache Aware 插件设计文档: cid:link_3[5] Kthena文档: https://volcano-sh.github.io/kthena/[6] Kthena-router 示例目录: cid:link_4 扫码进群，社区小助手k8s2222

Volcano[1] 社区 v1.14 现已正式发布。随着 AI 业务形态从单一的离线训练向在线推理、Agent 智能体等多元化场景延伸，调度系统面临着前所未有的挑战。v1.14[2] 通过架构级的创新，在保持大规模批量计算优势的同时，补齐了对延迟敏感型业务的调度短板，向着 “AI训推、RL、Agent全场景统一调度平台” 的目标迈出了坚实一步。  版本亮点  📌 v1.14.0 版本带来以下重磅更新：统一调度平台架构多调度器架构升级：动态节点分片机制 (Alpha)AI Agent 工作负载极速调度能力 (Alpha)网络拓扑感知调度增强HyperNode 级 Binpack 策略SubGroup 级精细化拓扑感知PodGroup 与 SubGroup 多层级 Gang SchedulingVolcano Job 分区支持混部能力增强全面支持通用操作系统（Ubuntu、CentOS 等）Cgroup V2 全面适配CPU 动态压制基于 Cgroup V2 的内存 QoS支持 CPU Burst支持 systemd driver 自动检测异构硬件支持昇腾 vNPU 调度（支持 MindCluster 和 HAMi 模式）Volcano Global 增强HyperJob 多集群作业自动拆分数据感知多集群调度Volcano Dashboard 增强PodGroup 全景可视化Job / Queue 全生命周期管理▍多调度器架构升级：动态节点分片机制 (Alpha)随着 Volcano 承载的工作负载类型日益丰富、规模持续扩大，单一调度器架构逐渐显露瓶颈。批量训练、AI Agent、微服务等不同类型的工作负载，对调度时延、资源利用模式的诉求各不相同。单调度器难以兼顾，而静态资源划分又会造成利用率低下。新引入的 Sharding Controller 构建了一套可扩展的多调度器架构，能够根据集群实时状态，为每个调度器动态计算候选节点池。与传统的静态分区不同，Sharding Controller 采用动态计算的方式划分资源，而非强制硬隔离。这种灵活机制让 Volcano 真正成为"一个平台调度所有负载"的统一调度平台，同时保持高吞吐、低时延。核心能力：动态分片策略：支持多种策略来计算动态候选节点池。当前版本率先支持基于 CPU 利用率的分片策略，并采用了可扩展的架构设计，以便未来轻松集成更多分片算法。节点池化管理：引入 NodeShard CRD，为特定调度器管理专属的动态候选节点池。支持大规模集群：通过在多个调度器之间灵活分配负载，天然适配大规模集群场景。多调度器协同：支持多种调度器组合的无缝协作。无论是部署多个 Batch Scheduler 进行负载分担，还是混合部署 Agent Scheduler 与 Batch Scheduler 以应对不同业务需求，都能灵活适配。配置示例：# Sharding Controller 启动参数--scheduler-configs="volcano:volcano:0.0:0.6:false:2:100,agent-scheduler:agent:0.7:1.0:true:2:100"--shard-sync-period=60s--enable-node-event-trigger=true# 参数格式: name:type:min_util:max_util:prefer_warmup:min_nodes:max_nodes🔗 相关 PR：cid:link_9设计文档：Sharding Controller Design[3]感谢社区开发者：@ssfffss, @Haoran, @qi-min▍AI Agent 工作负载极速调度 (Alpha)AI Agent 类业务对时延极度敏感，任务创建频繁且生命周期短，对调度器的响应速度和吞吐量提出了严苛要求。原生 Volcano Batch Scheduler 专为批量计算设计，按固定周期处理 Pod，难以满足 Agent 场景的毫秒级响应需求。为打造兼容批量计算与延迟敏感型业务的统一调度平台，v1.14 引入了专用的 Agent Scheduler。它通过 Sharding Controller 与批量调度器协同工作，各司其职又无缝配合，真正实现"一个平台、多种负载"。核心能力：极速调度通道：专为延迟敏感型负载（如 AI Agent）打造的独立调度器，提供极致响应速度。多 Worker 并行处理：采用多 Worker 并发消费调度队列的架构，大幅提升调度吞吐量。乐观并发控制：引入 Conflict-Aware Binder 机制，在实际绑定前预先解决冲突，减少无效操作。增强型调度队列：优化队列机制，支持紧急任务重试，确保关键任务不阻塞。统一平台融合：通过 Sharding Controller 与批量调度器无缝协作，共享集群资源。 🔗 相关 PR：  https://github.com/volcano-sh/volcano/pull/4804,  cid:link_11,  cid:link_12设计文档：Agent Scheduler Design[4]感谢社区开发者：@qi-min, @JesseStutler, @handan-yxh▍网络拓扑感知调度增强Volcano v1.14.0 对网络拓扑感知调度进行了进一步增强，满足分布式工作负载（包括 LLM 训练、推理、HPC 和其他网络密集型应用）日益增长的需求。核心增强：SubGroup 级精细化拓扑感知：支持在 SubGroup / Partition 粒度设置网络拓扑约束，调度颗粒度更精细。灵活的网络层级约束：新增 highestTierName，支持按名称指定允许跨越的最高网络层级。多层级 Gang Scheduling：同时支持 PodGroup 级别和 SubGroup 级别的 Gang Scheduling，确保分布式任务的整体性。Volcano Job 分区：支持将 Job 拆分为多个分区（Partition），便于管理 TP/PP/DP 等并行策略，并优化网络亲和性。HyperNode 级 Binpacking：在 HyperNode（如交换机、机架）层级进行资源装箱，减少网络碎片，提升通信效率。配置示例 - Volcano Job：apiVersion:batch.volcano.sh/v1alpha1 kind:Job metadata: name:llm-training-job spec: networkTopology: mode:hard highestTierAllowed:2 # 整个 Job 最多跨越 Tier 2 HyperNode tasks: - name:trainer replicas:8 partitionPolicy: totalPartitions:2 # 拆分为 2 个分区 partitionSize:4 # 每个分区 4 个 Pod minPartitions:2 # 至少需要 2 个分区 networkTopology: mode:hard highestTierAllowed:1 # 单个分区必须在 Tier 1 内 template: spec: containers: - name:trainer image:training-image:v1 resources: requests: nvidia.com/gpu:8 🔗 相关 PR：  cid:link_13,  cid:link_14,  cid:link_15,  cid:link_16,  cid:link_17设计文档：Network Topology Aware Scheduling[5]感谢社区开发者：@ouyangshengjia, @3sunny, @zhaoqi, @wangyang0616, @MondayCha, @Tau721▍混部能力全面升级：支持通用操作系统本次发布对 Volcano 的混部能力进行了全面改进，其中一个重要里程碑是：Volcano 混部能力正式支持通用操作系统（Ubuntu、CentOS 等），不再局限于 OpenEuler。这意味着更多用户可以使用 Volcano Agent 实现在离线混部，提升集群整体资源利用率。CPU 动态压制 (CPU Suppression)在线业务流量通常具有潮汐特性。为了在保障在线业务 SLA 的同时最大化资源利用，离线 Pod 的 CPU 配额需要随在线用量动态调整：在线用量高时压制离线配额，用量回落时逐步恢复，实现自适应的资源分配。核心设计：根据节点可分配 CPU 和实时用量，动态调整 BestEffort root cgroup 的 CPU 配额。采用"监控-事件-处理"架构，并实施保守更新策略，有效抑制抖动。配置示例：cpuThrottlingConfig: enable:true cpuThrottlingThreshold:80 # BE 配额上限为可分配 CPU 的 80% cpuJitterLimitPercent:1 # 配额变化超过 1% 才触发更新 cpuRecoverLimitPercent:10 # 单次恢复上限 10%内存 QoS (Cgroup V2)基于 Cgroup V2 实现混部场景的内存隔离。新增 ColocationConfiguration CRD，支持为指定工作负载配置内存 QoS 策略。核心能力：New API：通过标签选择器定义内存隔离策略的 ColocationConfiguration CRD动态计算：memory.high = pod.limits.memory * highRatio %memory.low = pod.requests.memory * lowRatio %memory.min = pod.requests.memory * minRatio %统一接口：可靠检测和支持 Cgroup V2 环境使用示例：apiVersion:config.volcano.sh/v1alpha1 kind:ColocationConfiguration metadata: name:colo-config1 spec: selector: matchLabels: app:offline-test memoryQos: highRatio:100 # memory.high = memory.limits * 100% lowRatio:50 # memory.low = memory.requests * 50% minRatio:0 # memory.min = memory.requests * 0%CPU Burst 与 Cgroup V2 全面支持CPU Burst 能力已扩展至通用操作系统。同时，Volcano Agent 现已全面适配 Cgroup V2 环境，支持自动检测 Cgroup 版本及驱动类型（如 systemd driver），无需人工干预即可在现代 Linux 发行版上无缝运行。 🔗 相关 PR： cid:link_18,  cid:link_19,  cid:link_20,  cid:link_21设计文档：CPU Throttle Design[6], Agent Cgroup V2 Adaptation[7]感谢社区开发者：@Haibara-Ai97, @JesseStutler, @ouyangshengjia▍昇腾 vNPU 调度v1.14 原生集成了昇腾 vNPU（虚拟 NPU）调度能力，实现昇腾 AI 处理器在多个工作负载之间的高效算力复用。提供两种模式，灵活适配不同部署场景。支持模式：1. MindCluster 模式集成自 Ascend MindCluster 调度插件：https://gitcode.com/Ascend/mind-cluster支持昇腾 310P 系列的动态虚拟化2. HAMi 模式由 HAMi 社区开发同时支持昇腾 310 和 910 系列支持异构昇腾集群（910A、910B2、910B3、310P）调度器配置：# MindCluster 模式 - name:deviceshare arguments: deviceshare.AscendMindClusterVNPUEnable:true # HAMi 模式 - name:deviceshare arguments: deviceshare.AscendHAMiVNPUEnable:true deviceshare.SchedulePolicy:binpack # 或 spread 🔗 相关 PR： cid:link_22,  cid:link_23使用文档：How to Use vNPU[8] 感谢社区开发者：@JackyTYang, @DSFans2014▍Volcano Global 增强Volcano Global v0.3.0 引入了两个重要功能，通过基于计算资源和数据局部性的智能调度，显著扩展了 Volcano Global 对 AI/ML 和大数据工作负载的能力。HyperJob：多集群作业自动拆分随着 AI 训练工作负载规模和复杂性的增长，企业越来越面临跨多个异构集群管理大规模训练作业的挑战。HyperJob 是构建在 Volcano Job 之上的更高级抽象。它组合多个 Volcano Job 模板，将训练能力扩展到单集群边界之外，同时保留每个集群内现有 Volcano Job 的全部能力。核心能力：Karmada 深度集成：自动生成 PropagationPolicy，精准配置集群亲和性与副本调度。状态统一聚合：将各集群子任务状态汇总为统一的 HyperJob 状态，全局可观测。自动资源生成：根据 ReplicatedJob 定义自动创建 VCJob 和 PropagationPolicy。HyperJob 资源示例（跨 2 个集群拆分大规模训练作业，共 256 个 GPU）：apiVersion:training.volcano.sh/v1alpha1 kind:HyperJob metadata: name:llm-training spec: replicatedJobs: - name:trainer replicas:2 templateSpec: tasks: - name:worker replicas:128 template: spec: containers: - name:trainer image:training-image:v1 resources: requests: nvidia.com/gpu:1数据感知调度在 AI 训练和大数据分析等高性能计算场景中，任务执行不仅依赖计算资源，还严重依赖数据资源。在多集群环境中，调度器可能会将任务分派到与数据源物理距离较远的集群，导致跨地域带宽成本过高和 I/O 延迟过高。数据感知调度框架引入 DataDependencyController，打通了逻辑数据需求与物理集群分布的壁垒。通过外部插件（如 Amoro）实时获取数据分布信息，自动将调度约束注入 Karmada，实现"计算随数据而动"的全自动工作流。核心能力：插件化架构：可扩展支持 Amoro、Hive、S3 等多种数据系统。声明式 API：DataSourceClaim / DataSource CRD，采用"声明-缓存"模式。自动亲和注入：将数据局部性转化为 ClusterAffinity 约束，注入 ResourceBinding。详见： Volcano Global v0.3.0 Release Notes[9]感谢社区开发者：@JesseStutler, @fx147, @Monokaix, @zhoujinyu, @anryko, @tanberBro▍Volcano Dashboard v0.2.0Volcano Dashboard v0.2.0 对资源管理能力进行了重大增强，使得通过 Web 界面管理 Volcano 资源更加便捷。核心增强：PodGroup 全景可视化：跨命名空间查看、搜索、过滤 PodGroup，支持 YAML 语法高亮。Job 生命周期管理：直接在界面创建、删除 Volcano Job，操作更便捷。Queue 管理增强：在线编辑 Queue 配额、权重，支持 YAML 直接修改。安全加固：默认配置 SELinux、Seccomp、非 root 运行及禁止提权，保障生产安全。详见： Volcano Dashboard v0.2.0 Release Notes[10]感谢社区开发者：@vzhou-p, @Shrutim1505, @JesseStutler, @karanBRAVO, @Sayan4444, @jayesh9747, @Alivestars24, @kuldeep, @Monokaix▍调度器稳定性与性能提升Reclaim 重构与增强对 Reclaim Action 进行了全面重构，并修复了 Capacity Plugin 中的关键逻辑问题，大幅提升多租户集群资源回收的准确性、稳定性和性能。主要改进：Reclaim Action 重构：重构了 reclaim 工作流，提高代码可读性、可维护性和测试覆盖率。增强的 Capacity Plugin 逻辑：修复了 reclaimableFn 和 preemptiveFn，正确处理标量资源并防止错误的抢占决策。稳定性提升：解决了资源计算中的边缘情况，防止调度死循环和误驱逐。 🔗 相关 PR： cid:link_24,  cid:link_25,  cid:link_26感谢社区开发者：@guoqinwill, @hajnalmt▍支持 Kubernetes 1.34Volcano 版本紧跟 Kubernetes 社区。v1.14 已全面支持最新的 Kubernetes v1.34，并通过完整的单元测试和 E2E 测试保障功能与稳定性。🔗 相关 PR：cid:link_27感谢社区开发者：@suyiiyii, @tunedev  总结：Volcano v1.14.0 — AI 时代的统一调度平台  Volcano v1.14 是一个里程碑式的版本。通过引入多调度器架构和 Agent Scheduler，Volcano 正式迈入统一调度平台新阶段，既能高效处理批量 AI 训练，又能满足 AI Agent 的极致时延要求。网络拓扑感知增强、通用操作系统混部支持、昇腾 vNPU 集成，进一步夯实了 Volcano 在 AI 基础设施领域的领先地位。同时，Volcano Global v0.3.0 通过 HyperJob 实现大规模分布式训练和数据感知调度，扩展了多集群能力。Volcano Dashboard v0.2.0 通过全面的资源管理功能显著改善了用户体验。立即体验 Volcano v1.14，共启 AI 时代统一调度新篇章！v1.14.0 发布地址：cid:link_8Volcano Global v0.3.0 发布地址：cid:link_6Volcano Dashboard v0.2.0 发布地址：cid:link_7   致   谢   Volcano v1.14 生态版本（含 Volcano Global v0.3.0、Dashboard v0.2.0）共有 55 位社区贡献者参与。衷心感谢每一位贡献者：相关链接[1] Volcano: https://volcano.sh/en/[2] Volcano v1.14.0: cid:link_8[3] Sharding Controller Design: cid:link_2[4] Agent Scheduler Design: cid:link_5[5] Network Topology Aware Scheduling: cid:link_0[6] CPU Throttle Design: cid:link_3[7] Agent Cgroup V2 Adaptation: cid:link_1[8] How to Use vNPU: cid:link_4[9] Volcano Global v0.3.0 Release Notes: cid:link_6[10] Volcano Dashboard v0.2.0 Release Notes: cid:link_7 扫码回复“Volcano” 进入技术群

作者：Kthena MaintainersKthena 是一个专为 Kubernetes 设计的云原生、高性能 LLM 推理路由和编排、调度系统。作为 Volcano 的子项目，Kthena[1] 致力于帮助 Volcano[2] 扩展除 AI 训练之外的边界，打造训推一体的完整解决方案。Kthena v0.3.0[3] 现已正式发布，标志着 Kthena 已经成为一个更加健壮且具有可扩展性的 AI 推理平台。此版本在 ModelServing、Router 和 ModelBooster 方面引入了重大增强。核心亮点包括：与 LeaderWorkerSet 的无缝集成、针对 PD 分离（Prefill-Decode Disaggregation）的高级网络拓扑感知调度，以及完善的 Router 可观测性框架。此外，本版本还带来了原生的 ModelServing 版本控制、对 vLLM 数据并行部署的支持，以及完整的 Router E2E测试套件，确保了生产环境的高稳定性和可靠性。  关键新特性概览  LeaderWorkerSet 支持：集成 LeaderWorkerSet (LWS) API，实现对分布式推理工作负载的高级管理。角色级 Gang 调度与拓扑感知：利用 Volcano 的 subGroupPolicy 新特性，实现精细化的角色级 Gang 调度和网络拓扑感知。ModelServing 分区版本控制：引入了基于 Revision 的原生 ModelServing 版本控制系统。Router 可观测性与调试：提供完善的 Router 可观测性文档和框架，并新增专用调试端口。增强的滚动更新：支持 maxUnavailable 参数，可调节更新速度以实现更快地发布。插件支持：为 ModelServing 提供灵活的插件架构，用于注入自定义配置逻辑。▍ModelServing 角色支持 LeaderWorkerSet分布式推理工作负载通常需要复杂的拓扑结构，其中一个 Leader Pod 管理多个 Worker Pod。手动配置这些关系容易出错。通过集成 Kubernetes LeaderWorkerSet (LWS) API，Kthena 简化了这些工作负载的部署和管理。核心能力：直接集成：ModelServing 角色（Role）现在可以利用 LWS 自动管理 Leader-Worker 组。简化拓扑：降低了定义需要严格协调的分布式推理服务的复杂性。相关内容：🧩 PR:cid:link_4cid:link_5贡献者: @zhiweideren▍角色级 Gang 调度与拓扑感知在 Prefill-Decode (PD) 分离场景中，Prefill 实例和 Decode 实例之间的通信开销至关重要。确保这些实例在物理位置上更接近（例如在同一个交换机或机架下）可以显著提升性能。Kthena 现在通过 Volcano 的 subGroupPolicy 实现了对 Gang 调度和网络拓扑感知的精细化、角色级控制。核心能力：声明式拓扑策略：直接在 ModelServing 规范中为整个 ServingGroup（groupPolicy）以及单个角色（rolePolicy）配置不同的网络拓扑限制。自动 Pod 分组：Controller自动为 Pod 打上 modelserving.volcano.sh/role 和 modelserving.volcano.sh/role-id 标签，使 Volcano 能够形成子组（subGroup）以进行精确的拓扑感知放置。性能优化：通过将相关任务部署在网络邻近的节点上，最小化角色间通信延迟并最大化带宽利用率，适用于高强度分布式推理任务。角色级 Gang 调度：subGroupPolicy 还强制执行角色级 Gang 调度，确保属于特定角色（例如所有 prefill-0 Pod）的所有 Pod 作为一个原子单元共同调度。这保证了角色不会出现部分部署的情况，这对于分布式推理工作负载的正确性至关重要。💡 注意：此特性需要针对 subGroupPolicy 支持的 Volcano v1.14+ 版本。相关内容：提案: Network Topology[4]🧩 PR: cid:link_6贡献者: @LiZhenCheng9527▍ModelServing 分区版本控制Kthena ModelServing 中的 partition 字段定义了滚动更新的边界，允许你对更新过程进行分区，以便在更新一部分 ServingGroup 的同时，让其他部分保持在旧版本。这主要用于金丝雀部署、分阶段发布以及在需要严格控制更新顺序的有状态应用中进行灰度更新。核心能力：Revision 追踪：自动追踪 ModelServing 配置的变更。分区保护：支持基于分区的更新，确保发布过程中的服务连续性。回滚：轻松回退到之前稳定的 Revision。相关内容：🧩 PR: cid:link_7cid:link_8cid:link_9贡献者: @FAUST-BENCHOU, @LiZhenCheng9527▍Router 可观测性与调试对推理 Router 的深度洞察对于诊断延迟问题和确保 SLA 合规性至关重要。新的可观测性框架和调试端口为运维人员提供了必要的工具。核心能力：调试端口：专用端口（默认 15000），用于实时查看路由表和上游健康状况。综合指标：提供详细的文档和配置，用于监控请求延迟、吞吐量和错误率。端到端测试：鲁棒的 E2E 测试框架涵盖了大多数路由场景，确保了可靠性。相关内容： 🧩PR & Issue:cid:link_10cid:link_11cid:link_2贡献者: @yashisrani, @FAUST-BENCHOU, @YaoZengzeng, @katara-Jayprakash  其他显著变化  [ModelServing] 支持 ModelServing 滚动更新中的 maxUnavailable 参数（@LiZhenCheng9527） PR: https://github.com/volcano-sh/kthena/pull/640 [ModelServing] 实现扩展插件框架（@hzxuzhonghu） PR: cid:link_13 [ModelServing] 支持 vLLM 数据并行部署和专家并行（Expert Parallel）模式[CLI] 为 PD 分离使用场景添加模板 (@huntersman） PR: cid:link_3 [Client] 使客户端 QPS 和 Burst 可配置 （@FAUST-BENCHOU） PR: cid:link_14 [Webhooks] 在 Helm chart 中默认启用 ModelServing Webhook （@VanderChen） PR: cid:link_15  [Infra] 通过 hack/local-up-kthena.sh 实现源码一键部署 （@FAUST-BENCHOU PR: cid:link_16  此外，Kthena v0.3.0 还对多项bug进行了修复，感谢 @WHOIM1205 @LiZhenCheng9527 @VanderChen @hzxuzhonghu @FAUST-BENCHOU。📌 即刻访问体验 Kthena v0.3.0: cid:link_1   贡献者  感谢所有为此次Release做出贡献的伙伴：  相关资料[1] Kthena: https://kthena.volcano.sh/[2] Volcano: https://volcano.sh/en/[3] Kthena v0.3.0: cid:link_1[4] Network Topology: cid:link_0 添加社区小助手回复“Kthena”进入技术交流群

今天，Volcano 社区[1]很高兴地宣布新的子项目 AgentCube。基于 Volcano 在大规模高性能计算调度领域多年的生产实践积累，AgentCube 将这种高并发、高吞吐的调度能力延伸至 AI 领域，构建了一套面向智能体（Agent）工作负载的 Serverless 编排层，旨在为高并发、长会话、对延迟极度敏感的智能体（Agent）工作负载提供 Serverless 化的编排与极速调度能力。  从 Kubernetes 到 Agent Native  随着大语言模型（LLM）技术的成熟，技术架构正从“无状态推理”向“自主智能体（Autonomous Agents）”演进。在这一进程中，Kubernetes 凭借其成熟的生态和对异构算力的标准化管理，已成为构建 AI 基础设施的事实标准。虽然原生 Kubernetes 提供了通用的容器编排原语以及多样化的工作负载抽象，但在面对 AI Agent 这种“高并发、短时效、强状态依赖”的新型负载时，仍存在着显著的粒度错配与机制缺位：1. 启动延迟与交互体验的矛盾： Agent 的交互通常要求毫秒级响应。然而，原生的 K8s Pod 启动流程（调度、IP 分配、镜像拉取、容器启动）往往在秒级甚至分钟级。对于需要频繁拉起 Code Interpreter（代码解释器）或临时子 Agent 的场景，这种冷启动延迟是用户无法接受的。2. 资源利用率的挑战：Agent 是典型的密集型负载。在一次会话中，90% 的时间 Agent 可能都在等待 LLM 生成 Token 或等待外部工具响应。如果在 K8s 上为每个 Agent 独占一个 Pod，会导致大量的 CPU/Memory 资源在等待期间被闲置浪费，却无法被其他任务复用。3. 会话状态管理的缺失：K8s 对“无状态（Stateless）”工作负载天然友好，但 Agent 高度依赖“上下文（Context/Memory）”。在原生 K8s 中，Pod 重启意味着内存数据丢失，开发者被迫在应用层通过外部存储重建上下文，这带来了巨大的复杂性和网络开销。4. 安全隔离难题：高级 Agent（如 Data Analyst）需要运行由 LLM 生成的不可信代码。但普通的 runC 容器如果运行 rm -rf / 具有极高风险。企业级 Agent 平台迫切需要一种既能快速启动，又能提供强隔离（如 MicroVM）的沙箱环境。为了在 Kubernetes 坚实的算力底座之上，填补上述机制空白，AgentCube 应运而生。  AgentCube 是什么？AgentCube 是一个构建在 Volcano 之上的高性能 AI Agent 编排层。它通过扩展 Kubernetes API，将 Agents 和 Tools（Code Interpreters、BrowserUse等） 提升为集群的一等公民。它不仅仅是一个 CRD，更是一套 面向 Agent 的 Serverless 操作系统。▍核心架构与抽象AgentCube 引入了两个核心的 CRD 来定义 Agent 工作负载：1. AgentRuntime: 面向长会话、复杂的对话式 Agent。支持定义会话的生命周期、资源配额以及持久化策略。2. CodeInterpreter: 面向短任务、高频的代码执行环境。强调“用完即毁”和极致的安全隔离，天然适配 MicroVM（如 Kuasar, Kata Containers, Firecracker）。AgentCube后续还将提供BrowserUse、ComputerUse、MobileUse等工作负载抽象支持。  AgentCube 关键技术亮点  为了解决上述痛点，AgentCube 在架构设计上引入了多项创新：▍1. 极速启动为了消除冷启动的挑战，AgentCube 实现了 Warm Pool（预热池） 机制。系统会预先启动并暂停一组持有基础环境的 MicroVM 沙箱。当 Agent 请求到来时，AgentCube 能够通过 "Claim-and-Go" 的方式，在毫秒级将预热的沙箱分配给会话，实现近乎零延迟的启动体验。▍2. 极速调度借助 Volcano 的 Agent Scheduler，AgentCube显著提升了Agent调度的吞吐和时延。高吞吐、低时延： 针对 Agent 突发流量，采用了乐观并发控制和精简的调度策略，大幅提升调度 TPS。统一调度支持： Volcano 的 Agent Scheduler 可以与原有的 Batch Scheduler 无缝配合，在协调 Agent 与传统的 Batch 作业潜在调度冲突的同时，确保整体集群的资源利用率和关键业务的 SLA。▍3. 原生会话管理AgentCube 引入了 Session ID 作为核心路由标识，便于保证业务上下文的连续性。请求路由： AgentCube Router 能够识别请求中的 x-agentcube-session-id，自动将其路由到对应的活跃沙箱。自动的沙箱激活： 当前会话对应的沙箱处于休眠状态时，AgentCube Router 能够自动激活沙箱。基于会话的端到端隔离： AgentCube 会自动为每个会话分配独立的沙箱环境，确保计算、内存与文件系统的完全隔离，防止跨租户的数据泄露。▍4. Serverless 化的弹性伸缩AgentCube 能够根据会话的活跃度自动管理沙箱生命周期。闲置的沙箱会被自动回收或休眠，释放物理资源供其他高优先级任务使用，真正实现资源按需分配与极致利用。  AgentCube 架构概览  AgentCube 采用了经典的控制面与数据面分离的架构设计，确保了系统的高可用性与扩展性：数据面 : 由 AgentCube Router 承载。它作为流量入口，负责鉴权、限流以及基于 Session ID 的智能路由。对于新会话，它向控制面申请资源；对于活跃会话，它直接将请求转发至对应的 Sandbox (MicroVM)。控制面 : 核心组件 Workload Manager 负责沙箱的全生命周期管理。它监控预热池 (Warm Pool) 的水位，自动补充 MicroVM 实例，并根据会话活跃度策略（如 TTL）执行沙箱的回收与垃圾清理。调度层: 集成 Volcano Agent Scheduler，通过异步并行调度和乐观锁机制，实现高并发下的毫秒级资源分配。  生态协作：共建标准化的 Agent 基础设施  作为开源中立的基础设施项目，AgentCube 旨在通过标准接口连接上下游生态，协作解决从容器编排到智能体应用落地的“最后一公里”难题。1. 南向兼容：基于标准接口的运行时适配AgentCube 坚持开放架构设计，通过深度集成 kubernetes-sigs/agent-sandbox 接口及 OCI 标准，实现对底层异构运行时的统一抽象与无感适配。运行时解耦： 支持通过 RuntimeClass 机制接入 Kuasar、Kata Containers、Firecracker 等安全容器技术，允许用户根据安全与性能需求灵活选择底层隔离方案。前沿探索： 社区正在评估 Wasm (WebAssembly) 技术，计划在未来版本中探索其在极轻量级 Agent 任务中的应用，以提供更多样化的算力供给。2. 北向集成：服务主流Agent框架在应用层，AgentCube 致力于成为 Dify、LangChain、CrewAI、LlamaIndex 等Agent框架的标准基础设施底座，相关适配工作正在快速迭代中。声明式管理： 将通过 Operator 模式提供声明式资源接口，帮助上层框架剥离底层的沙箱预热池管理与网络配置等逻辑。统一底座： 目标是实现业务编排与资源调度的解耦，使不同框架开发的应用能复用同一套云原生运维体系，降低基础设施的维护成本与碎片化程度。  灵活接入：兼顾开发与运维体验  AgentCube 设计了分层的接入接口，旨在同时满足上层业务开发者与底层平台工程师的诉求，让基础设施不再成为黑盒。1. 面向 Agent 开发者：标准 API 接入为了进一步降低接入门槛，AgentCube 提供了开箱即用的 Python SDK[2]。开发者无需深入理解 Kubernetes 的复杂概念，即可像调用本地函数一样申请、执行和释放沙箱。这使得 AgentCube 能够轻松集成到 Dify、LangChain、CrewAI、LlamaIndex 等主流框架中。📄 示例1：在agent代码中动态拉起一个CodeInterpreter并运行临时代# python from agentcube import CodeInterpreterClient # Initialize client (uses env vars for configuration) with CodeInterpreterClient() as client: # 1. Run a simple shell command print("User: whoami") print(client.execute_command("whoami")) # 2. Execute Python code code = """ import math print(f"Pi is approximately {math.pi:.4f}") """ output = client.run_code("python", code) print(f"Result: {output}")📄 示例2：通过kubectl agentcube命令行工具创建一个Agent# 1. Package an existing agent: kubectl agentcube pack -f examples/hello-agent --agent-name "my-agent" # 2. Build the container image: kubectl agentcube build -f examples/hello-agent # 3. Publish to AgentCube: kubectl agentcube publish \ -f examples/hello-agent \ --image-url "docker.io/username/my-agent" \ # 4. Invoke your agent: kubectl agentcube invoke -f examples/hello-agent --payload '{"prompt": "Hello World!"}' # 5. Check status: kubectl agentcube status -f examples/hello-agent2. 面向平台工程师：声明式 CRD 管理AgentCube 延续了云原生的声明式管理模式。运维团队可以通过 CRD (AgentRuntime, CodeInterpreter) 精细化定义资源池策略，直接复用现有的 Kubernetes 运维体系与工具链进行统一管理。📄 示例：定义一个CodeInterpreter，始终保持 10 个热备沙箱# YAML apiVersion: runtime.agentcube.volcano.sh/v1alpha1 kind: CodeInterpreter metadata: name: simple-codeinterpreter namespace: default spec: template: image: ghcr.io/volcano-sh/picod:latest sessionTimeout: "15m" maxSessionDuration: "8h" warmPoolSize: 10 # 预热水位想亲自体验？完整的安装部署文档与 Demo 示例，请访问 GitHub 仓库：cid:link_1  加入社区  AgentCube 是 Volcano 社区的一部分，遵循开源开放的原则。我们诚挚邀请对 AI Infra、Kubernetes 调度、Serverless 架构 感兴趣的开发者加入我们！GitHub: https://github.com/volcano-sh/agentcube( 欢迎Star ⭐️) Slack: CNCF Slack # volcano 频道Community Meeting: 关注  Volcano 社区双周会 [3]。让我们一起，为 AI Agent 时代构建更强大的基础设施！相关链接[1] Volcano 社区官网: https://volcano.sh/en/[2] Python SDK: cid:link_0[3] Volcano 社区双周会: https://zoom.us/j/91804791393 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。Website：https://volcano.shGitHub: cid:link_2每周例会：https://zoom.us/j/91804791393 添加社区小助手回复“Volcano”进入技术交流群

作者：Volcano Maintainers今天，我们激动地向全球开发者和 MLOps 工程师宣布，Volcano 社区迎来了一个新的子项目 Kthena！Kthena 是一个专为 Kubernetes 设计的云原生、高性能 LLM 推理路由和编排、调度系统。它旨在解决在生产环境中大规模编排、部署和服务 LLM 所面临的核心挑战，通过其独特的超节点拓扑感知的亲和性调度，KV Cache 感知的流量调度、Prefill/Decode 分离路由等高级功能，显著提升 GPU/NPU 资源利用率和吞吐，降低推理延迟，赋予企业前所未有的灵活性和控制力。作为 Volcano 的子项目，Kthena 将致力于帮助 Volcano 扩展除 AI 训练之外的边界，打造训推一体的完整解决方案。  LLM 服务化的“最后一公里”困境  大语言模型（LLM）正在以前所未有的速度重塑各行各业，但将其高效、经济地部署在生产环境中，特别是基于 Kubernetes 的云原生平台上，仍然困难重重。开发者们普遍面临以下挑战：1.  资源利用率低：LLM 推理，尤其是其独特的 KV Cache 机制，对 GPU、NPU 显存的占用是动态且巨大的。传统的负载均衡一般采用Round-Robin算法，无法感知这种负载特性，导致 GPU、NPU 资源闲置与请求排队并存，成本高昂。2.  延迟与吞吐量难以兼顾：LLM 推理分为“Prefill”（处理输入提示）和“Decode”（生成 Token）两个阶段，前者是计算密集型，后者是访存密集型。将两者混合调度，常常导致无法针对性优化，影响整体服务的响应速度和吞吐能力。因此PD分离的部署已经成为主流，但如何高效路由和调度，仍是一个难题。3.  多租户与多模型管理复杂：在企业环境中，通常需要同时提供多个不同模型、不同版本或经过 LoRA 微调的模型。如何实现请求的公平调度、优先级管理以及动态路由，是一个复杂的工程难题，业界甚至有些方案将AI网关与大模型一一对应。4.  缺乏K8s原生集成：许多现有的解决方案要么是外部系统，与 Kubernetes 生态割裂；要么过于复杂，无法满足生产级所需的简单易用性和灵活运维。  Kthena：云原生 LLM 推理的智能大脑  为了攻克上述难题，Kthena 应运而生。它并非要取代现有的 LLM 服务框架（如 vLLM, sgLang），而是作为它们上层的智能“交通枢纽”和“调度中心”，深度集成于 Kubernetes 之中。Kthena 架构图Kthena 的核心由两大组件构成：1）Kthena Router：一个独立、高性能面向多模型的router，负责接收所有推理请求，并根据 ModelRoute 规则，智能地将请求分发到后端的 ModelServer。2）Kthena Controller Manager：Kubernetes 控制平面的控制器，它主要包含多种控制器，负责 LLM 工作负载的编排与生命周期管理。它持续调谐并联动多类 CRD（如 ModelBooster、ModelServing、AutoScalingPolicy/AutoScalingPolicyBinding、以及 ModelRoute/ModelServer），将声明式API转化为运行时资源：ModelServing 控制器编排 ServingGroup 与 Prefill/Decode 角色分组；支持网络拓扑亲和调度和Gang调度、滚动升级与故障恢复；基于 AutoScalingPolicy 实现弹性扩缩容。这种架构使得 Kthena 成为连接用户请求与 LLM 模型的高度可编程的桥梁。  核心特性与优势  Kthena 的强大之处在于其专为 LLM 推理场景设计的核心功能：1) 生产级推理编排（ModelServing）LLM工作负载三层架构设计：ModelServing -> ServingGroup -> Role，一个API，支持LLM原生部署、PD分离部署，乃至大EP部署等多种部署形态，简化管理多LWS的负担。例如对于PD分离的大规模部署，可用一个ModelServing表示，根据负载的大小每个ModelServing可以包含任意数目的 ServingGroup（xPyD 分组）， 每个ServingGroup包含多个角色（Prefill Decode，他们通常部署在同一个超节点内以提升推理性能），相同的角色可以等价为一个LeaderWorkerSet，支持TP/PP/EP等多节推理并行计算。原生支持Prefill-Decode分离部署：将计算密集型的 Prefill 实例调度到配备高性能计算卡的节点组，而将访存密集型的 Decode 实例调度到配备高带宽显存的节点组，实现资源的最佳匹配和极致的端到端延迟优化。另可以独立伸缩，动态调整Prefill-Decode的比例，更灵活的应对各种复杂的业务场景（如长短句混合、实时推理等）。多并行范式支持：TP/PP/DP/EP 等并行模式灵活配置，最大化提升资源利用率和SLO内置拓扑感知、Gang 调度支持：Gang调度确保ServingGroup/Role“成组原子化”落地，避免资源浪费；拓扑感知调度通过将Role内的一组Pod调度到网络拓扑更优的节点，提升并行计算的数据传输时延。2) 开箱即用的模型上线（ModelBooster）针对主流的大模型，提供包括PD分离在内的多种部署范式模板，自动生成ModelRoute/ModelServer/ModelServing/Autoscaling等路由策略和生命周期管理资源覆盖通用的部署场景，至于更灵活的编排可通过ModelServing进行细粒度的控制3) 智能、模型感知的路由（Kthena Router）多模型路由：兼容OpenAI API，根据请求头或Body体内容，将流量调度到不同的基础模型。插件化调度算法：提供最少请求、最小时延、KV Cache 感知、Prefix Cache 感知、LoRA 亲和、GPU 利用率感知、公平调度等多种负载均衡算法，满足用户不同业务场景和部署形态的需求LoRA 模型热插拔无中断：感知推理引擎加载的LoRA 适配器，提供无中断的插拔和路由能力丰富的流量治理策略：基于权重的模型路由，金丝雀发布、Token级流控、故障转移·All-in-one实现架构，无需部署Envoy Gateway，原生支持PD分离的流量调度，将多层路由合并成一层，易于维护4) 成本驱动的自动扩缩容（Autoscaler）同构伸缩：支持稳定、突发双模式，按业务指标（CPU/GPU/内存/自定义）精准扩缩异构部署优化：在多推理引擎/异构加速器组合中按“成本-能力”贪心分配，最大化性价比5) 主流推理引擎与异构硬件支持支持多种主流推理引擎vLLM、SGLang、Triton/TGI 等，统一API抽象、标准化指标支持GPU/NPU 等异构混部，配合异构 Autoscaling 实现成本与 SLO 的动态平衡6) 内置流量控制与公平性调度公平调度：支持基于优先级和历史Token消耗的的公平调度，既兼顾用户的优先级，对高优先级用户提供更好的服务，又防止低优先级用户“饿死”流量控制：支持按照用户、模型、token长度进行精细化流量控制。  极致的性能提升  基于 Kthena Router 的调度插件架构，在长系统提示词场景（如 4096 tokens）下，采用“KV Cache 感知 + 最少请求”策略相较随机基线：吞吐可提升约 2.73 倍TTFT 降低约 73.5%端到端时延降低超过 60%短提示词场景差距会随提示词长度收敛，但在多轮对话、模板化生成、前缀高度相似的业务中，KV Cache 感知策略优势显著。实际收益与模型规模、Prompt长短、硬件紧密相关，但“按需组合、按场景选型”已被验证有效。  社区展望 / Call for Contribution  Kthena 在项目规划和发展的初期便得到了部分社区用户单位的关注和支持，但这只是一个开始。我们计划在未来支持更高效的调度算法、更广泛的大模型最佳部署实践，并持续深耕 LLM 推理的大规模部署和性能优化。“ 开源是技术创新的源头活水，也是推动产业标准化的最强引擎。作为Volcano项目的发起单位，华为云很荣幸能够与社区其他伙伴一起推出全新的Kthena分布式推理项目。这不仅是Volcano社区技术演进的重要里程碑，更是华为云在云原生AI领域长期投入与持续创新的有力见证。它将与华为云CCE（云容器引擎）、CCI（云容器实例）等基础设施深度结合，进一步释放包括昇腾（Ascend）在内的多元算力价值，为客户提供极致的算力性价比。我们希望通过Kthena，与全球开发者与伙伴，共建、共享一个开放、繁荣的云原生AI生态，为千行万业的智能化升级构筑最坚实的算力底座。”—— 祁小波，华为云通用计算服务产品部部长“ Kthena进一步巩固了Volcano在智能计算调度领域的领先地位。我们的平台利用Volcano的统一调度与资源池化能力，一站式满足通用计算与智能计算中训练、推理等多类算力需求。这使得算力资源能够在不同场景间灵活流转，有效避免了资源割裂的问题。展望未来，我们期待 Kthena结合Volcano的弹性伸缩能力与Volcano Global的跨集群调度特性，共同推动算力资源利用率进一步提升！”—— 杨磊，中电信人工智能公司 PaaS研发总监“ Volcano 项目自诞生之日起，便始终与社区以及各类 AI 场景深度共建、同频演进，逐步沉淀出一整套面向 AI 工作负载的调度与批处理生态。今天，Kthena 的出现，不仅将这条共建链路进一步拓展到大模型推理领域，把推理这一关键一环真正纳入 Volcano 生态之中，更是在统一编排与智能路由层面，将 Volcano 在调度、弹性伸缩以及多算力适配上的多年实践，凝练成一个令人振奋的里程碑式能力。借助既有的 Kubernetes / Volcano 生态，更多团队可以用更低的成本，获得更智能的调度决策和更高效的算力利用，并在开放协作的基础上持续演进。这不仅为道客解决了在推理场景中遇到的实际问题，也是我们所期待的云原生 AI 形态——一个足够开放、足够智能、值得我们长期投入和深度参与的社区方向。”—— 徐俊杰，DaoCloud 开源团队负责人，Kubernetes 社区指导委员会成员“ 自建大模型推理服务的生产级部署和运维难题，是一个覆盖推理服务全生命周期管理（部署、运维、弹性、故障恢复等），GPU集群稳定性，资源调度效率、推理服务性能提升，推理流量智能调度、AI可观测等领域的系统工程。而这也正是Kthena项目的技术定位。早在Kthena的规划阶段，小红书云原生团队就和Kthena贡献者做了深度的沟通，在推理流量智能调度方向，一起设计了多种流量调度策略和路由实现。未来，双方将继续在AI网关方向合作，结合小红书内部业务经验，一起为社区提供更精细化的AI流量智能调度能力，模型API管理能力，MCP协议支持等多种生产可用能力。”—— 空古(陈华昌)，小红书云原生业务网关负责人“ 在深入调研并试用Kthena这一云原生AI推理平台后，联通云对其展现出的前瞻能力印象深刻。我们尤为看好其与Volcano实现的联合调度特性，其网络拓扑感知与Gang Scheduling功能，能够有效解决大规模分布式模型推理场景下中，关于效率与可靠性的核心诉求，为破解复杂调度难题提供了极具潜力的解决方案。我们相信，Kthena卓越的低延迟、高吞吐与多模型智能路由能力，将为开源社区带来真正具备生产级的AI推理解决方案，助力开发者更高效地构建和管理云原生环境下的智能应用。”—— 卢照旭，联通云智算能力中心团队长“ 开放和协作是构建社区的未来、加速技术创新的核心动力。在CNCF，我们持续致力于推动基础设施向‘AI Native’演进，为整个云原生生态提供标准、中立且可扩展的基础能力。Volcano社区通过孵化Kthena子项目，将其在大规模批量计算和调度上积累的拓扑感知、Gang调度等核心经验，精准地应用到了LLM在线推理这一关键场景。Kthena的价值在于，它提供了一套专为大模型设计、可供业界参考借鉴的云原生调度原语和抽象，这有助于将复杂的LLM推理工作负载，真正以Kubernetes原生的一等公民身份进行高效管理。这不仅是Volcano项目技术演进的重要一步，更是社区生态在解决AI规模化部署挑战中贡献的一份重要实践经验。我们诚挚邀请全球的开发者、研究人员和所有云原生爱好者加入，共同贡献智慧，完善这些关键AI基础设施，加速 AI Native 进程。”—— Kevin Wang，Volcano Maintainer、CNCF TOC 副主席  立即开始探索 Kthena  GitHub 仓库: cid:link_1Volcano 官网: https://kthena.volcano.sh/社区（加入我们的 Slack）: https://cloud-native.slack.com/archives/C011GJDQS0N让我们一起，为 LLM 插上云原生的翅膀，释放 AI 的全部潜能！ Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。 更多云原生技术动向关注容器魔方

华为云云容器引擎CCE支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。在华为云云容器引擎CCE使用Volcano的调度中，在替换节点池、节点滚动升级等场景，需要使用新节点池替换旧节点池。在这些场景下，为做到业务不感知，可以在业务触发变更时，将业务的Pod软亲和调度到新的节点池上。这种软亲和调度会尽量将新创建的Pod或者重调度的Pod调度到新的节点池，如果新节点池资源不足，或者新节点池无法调度，也要能将Pod调度到旧节点池上。节点池替换、节点滚动升级等场景中，业务不需要也不应该感知，所以不会在业务负载中声明节点亲和配置，而需要在集群调度层面，使用软亲和方式，在业务变更时将Pod尽量调度到新的节点池上。Volcano的目标是在业务负载未配置节点软亲和时，在调度层将业务的Pod软调度到指定节点上。  调度优先级介绍  节点池软亲和调度，是通过节点池上的标签（Label）进行软亲和，具体是通过给每一个节点进行打分的机制来排序筛选最优节点。📝 原则：尽可能把Pod调度到带有相关标签的节点上。🔍 打分公式如下：score = weight * MaxNodeScore * haveLabel参数说明：weight：节点池软亲和plugin的权重。MaxNodeScore：节点最大得分，值为100。haveLabel：节点上是否存在插件中配置的label，如果有，值为1，如果节点上没有，值为0。  前提条件  ✅ 已创建v1.19.16及以上版本的集群，具体操作请参见购买Standard/Turbo集群。✅ 集群中已安装1.11.5及以上版本的Volcano插件，具体操作请参见Volcano调度器。  配置Volcano节点池软亲和调度策略  1、在节点池上配置用于亲和调度的标签。登录CCE控制台，单击集群名称进入集群。在左侧选择“节点管理”，在右侧选择“节点池”页签。单击节点池名称后的“更新”，在弹出的“更新节点池”页面中配置参数，在“K8s标签”中配置对应的标签。示例如下：2、单击左侧导航栏的“配置中心”，切换至“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。3、设置Volcano调度器配置参数，JSON格式的配置示例如下。... "default_scheduler_conf": { "actions": "allocate, backfill, preempt", "tiers": [ { "plugins": [ { "name": "priority" }, { "name": "gang" }, { "name": "conformance" } ] }, { "plugins": [ { "name": "drf" }, { "name": "predicates" }, { "name": "nodeorder" } ] }, { "plugins": [ { "name": "cce-gpu-topology-predicate" }, { "name": "cce-gpu-topology-priority" }, { "name": "cce-gpu" }, { // 开启节点池亲和性调度 "name": "nodepoolaffinity", // 节点池亲和性调度权重及标签设置 "arguments": { "nodepoolaffinity.weight": 10000, "nodepoolaffinity.label": "nodepool=nodepool1" } } ] }, { "plugins": [ { "name": "nodelocalvolume" }, { "name": "nodeemptydirvolume" }, { "name": "nodeCSIscheduling" }, { "name": "networkresource" } ] } ] }, ...4、 完成以上配置后，单击“确定”。 🌍 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。📌 更多Volcano云原生批量计算 技术应用，请访问社区仓库或官网：1️⃣ Volcano云原生批量计算社区官网：https://volcano.sh2️⃣ Volcano GitHub 仓库: cid:link_53️⃣ Volcano云原生批量计算公开课：cid:link_34️⃣ 华为云云容器引擎CCE：cid:link_4 更多云原生技术动向关注容器魔方

华为云云容器引擎CCE支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。集群中的调度是将pending状态的Pod分配到节点运行的过程，在CCE集群之中，Pod的调度依赖于集群中的调度器（kube-scheduler或者Volcano调度器）。调度器是通过一系列算法计算出Pod运行的最佳节点，但是Kubernetes集群环境是存在动态变化的，例如某一个节点需要维护，这个节点上的所有Pod会被驱逐到其他节点，但是当维护完成后，之前被驱逐的Pod并不会自动回到该节点上来，因为Pod一旦被绑定了节点是不会触发重新调度的。由于这些变化，集群在一段时间之后就可能会出现不均衡的状态。为了解决上述问题，Volcano调度器可以根据设置的策略，驱逐不符合配置策略的Pod，让其重新进行调度，达到均衡集群负载、减少资源碎片化的目的。  重调度功能介绍  ▍负载感知重调度（LoadAware）在K8s集群治理过程中，常常会因CPU、内存等高使用率状况而形成热点，既影响了当前节点上Pod的稳定运行，也会导致节点发生故障的几率的激增。为了应对集群节负载不均衡等问题，动态平衡各个节点之间的资源使用率，需要基于节点的相关监控指标，构建集群资源视图，在集群治理阶段，通过实时监控，在观测到节点资源率较高、节点故障、Pod 数量较多等情况时，可以自动干预，迁移资源使用率高的节点上的一些Pod到利用率低的节点上。图1 LoadAware策略示意图 使用该插件时，highThresholds需要大于lowThresholds，否则重调度器无法启用。正常节点：资源利用率大于等于30%且小于等于80%的节点。此节点的负载水位区间是期望达到的合理区间范围。热点节点：资源利用率高于80%的节点。热点节点将驱逐一部分Pod，降低负载水位，使其不超过80%。重调度器会将热点节点上面的Pod调度到空闲节点上面。空闲节点：资源利用率低于30%的节点。▍CPU和内存资源碎片率整理策略（HighNodeUtilization）从分配率低的节点上驱逐Pod。这个策略必须与Volcano调度器的binpack策略或者kube-scheduler调度器的MostAllocated策略一起使用。阈值可以分为CPU和内存两种资源角度进行配置。  前提条件  ✅ 已创建v1.19.16及以上版本的集群，具体操作请参见购买Standard/Turbo集群。✅ 集群中已安装1.11.5及以上版本的Volcano插件，具体操作请参见Volcano调度器。  约束与限制  ❌ 重调度之后的Pod，需要调度器进行调度，重调度器并未进行任何对于Pod和节点的标记行为，所以被驱逐的Pod调度到节点的行为完全被调度器控制，存在驱逐之后，被驱逐的Pod调度到原来节点的可能性。❌ 重调度功能暂不支持Pod间存在反亲和性的场景。如果使用重调度功能驱逐某个Pod后，由于该Pod与其他已运行的Pod存在反亲和性，调度器仍可能将其调度回驱逐前的节点上。❌ 配置负载感知重调度（LoadAware）时，Volcano调度器需要同时开启负载感知调度；配置CPU和内存资源碎片率整理策略（HighNodeUtilization）时，Volcano调度器需要同时开启binpack调度策略。  配置负载感知重调度策略  配置负载感知重调度（LoadAware）时，Volcano调度器需要同时开启负载感知调度，示例步骤如下。1、登录CCE控制台，单击集群名称进入集群。2、单击左侧导航栏的“插件中心”，在右侧找到Volcano调度器，单击“编辑”，在“扩展功能”中开启“重调度”的开关，单击“确定”完成插件配置更新。3、单击左侧导航栏的“配置中心”，通过“调度配置”页面启用负载感知调度。详情请参见负载感知调度。4、在“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。5、配置负载感知重调度策略。使用Volcano 1.11.21及更新版本，JSON格式的重要参数配置示例如下，其他参数请参见控制台“开始使用”中的JSON示例。{ ... "deschedulerPolicy": { "profiles": [ { "name": "ProfileName", "pluginConfig": [ { "args": { "ignorePvcPods": true, "nodeFit": true, "priorityThreshold": { "value": 100 } }, "name": "DefaultEvictor" }, { "args": { "evictableNamespaces": { "exclude": ["kube-system"] }, "metrics": { "type": "prometheus_adaptor" }, "targetThresholds": { "cpu": 80, "memory": 85 }, "thresholds": { "cpu": 30, "memory": 30 } }, "name": "LoadAware" } ], "plugins": { "balance": { "enabled": ["LoadAware"] } } } ] }, "descheduler_enable": "true", "deschedulingInterval": "10m" ... }表1 集群重调度策略关键参数表2 deschedulerPolicy配置参数 6、完成以上配置后，单击“确定”。  配置资源碎片整理策略  配置CPU和内存资源碎片率整理策略（HighNodeUtilization）时，Volcano调度器需要同时开启binpack调度策略，示例步骤如下。1、登录CCE控制台，单击集群名称进入集群。2、单击左侧导航栏的“插件中心”，在右侧找到Volcano调度器，单击“编辑”，在“扩展功能”中开启“重调度”的开关，单击“确定”完成插件配置更新。3、单击左侧导航栏的“配置中心”，通过“调度配置”页面启用装箱策略(binpack)。详情请参见装箱调度（Binpack）。4、在“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。5、配置资源碎片整理策略，JSON格式的重要参数配置示例如下，其他参数请参见控制台“开始使用”中的JSON示例。{... "deschedulerPolicy": { "profiles": [ { "name": "ProfileName", "pluginConfig": [ { "args": { "ignorePvcPods": true, "nodeFit": true, "priorityThreshold": { "value": 100 } }, "name": "DefaultEvictor" }, { "args": { "evictableNamespaces": { "exclude": ["kube-system"] }, "thresholds": { "cpu": 25, "memory": 25 } }, "name": "HighNodeUtilization" } ], "plugins": { "balance": { "enabled": ["HighNodeUtilization"] } } } ] }, "descheduler_enable": "true", "deschedulingInterval": "10m"...}参数说明deschedulingInterval重调度的周期。deschedulerPolicy集群重调度策略，详情请参见表4。表3 集群重调度策略关键参数表4 deschedulerPolicy配置参数 6. 完成以上配置后，单击“确定”。  使用案例  ▍资源碎片整理策略（HighNodeUtilization）使用案例1、单击集群控制台左侧导航栏的“节点管理”，查看集群之中的节点，发现存在部分分配率过低的节点。2、单击左侧导航栏的“配置中心”，在“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。3、编辑Volcano参数，设置CPU和内存的阈值为25。即表示节点的分配率小于25%时，该节点上的Pod会被驱逐。4、设置该策略后，将192.168.44.152节点上的Pod迁移到节点192.168.54.65，达到碎片整理的目的。  常见问题  当输入参数错误时，会有报警事件，例如：输入的配置不符合阈值范围、输入的配置格式不正确。如下图所示，可以按照事件提示进行修改。 🌍 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。📌 更多Volcano云原生批量计算 技术应用，请访问社区仓库或官网：Volcano云原生批量计算社区官网：https://volcano.shVolcano GitHub 仓库: cid:link_8Volcano云原生批量计算公开课：cid:link_6华为云云容器引擎CCE：cid:link_7 更多云原生技术动向关注容器魔方

 华为云云容器引擎CCE支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。装箱调度（Binpack）是一种优化算法，以最小化资源使用量为目标，将资源合理地分配给每个任务，使所有资源都可以实现最大化的利用价值。在集群工作负载的调度过程中使用Binpack调度策略，调度器会优先将Pod调度到资源消耗较多的节点，减少各节点空闲资源碎片，提高集群资源利用率。  前提条件  ✅ 已创建v1.19及以上版本的集群，详情请参见购买Standard/Turbo集群。✅ 已安装Volcano插件，详情请参见Volcano调度器。  Binpack功能介绍  Binpack调度算法的目标是最大限度地填满现有节点，尽量避免将Pod调度至空闲节点。具体实现中，调度器会对所有满足条件的节点进行打分，资源利用率越高，得分越高，调度优先级也越高。Binpack算法能够尽可能填满节点，将应用负载靠拢在部分节点，这非常有利于集群节点的自动扩缩容功能。Binpack为Volcano调度器的多个调度插件之一，与其他调度插件协同工作，共同影响节点的最终得分。用户可自定义Binpack插件的全局权重，并分别为CPU、内存基础资源以及 GPU、NPU等扩展资源配置打分权重，从而控制Binpack在调度决策中的影响程度。在计算Binpack得分时，调度器会综合考虑Pod所请求的各类资源，并基于各资源的打分权重进行加权平均，以确定节点的最终得分。  Binpack算法原理  在对节点打分时，Binpack会结合插件的全局权重和各资源维度（如CPU、内存、GPU等）的权重值，计算出节点Binpack得分。节点Binpack得分的计算流程如下：1️⃣ 首先，对Pod请求资源中的每类资源依次打分，以CPU为例，CPU资源在待调度节点的得分信息如下：CPU.weight * (request + used) / allocatable即CPU权重值越高，得分越高，节点资源使用量越满，得分越高。Memory、GPU等资源原理类似。其中：CPU.weight为用户设置的CPU权重request为当前Pod请求的CPU资源量used为当前节点已经分配使用的CPU量allocatable为当前节点CPU可用总量2️⃣ 通过Binpack策略的节点总得分如下：binpack.weight * (CPU.score + Memory.score + GPU.score) / (CPU.weight+ Memory.weight+ GPU.weight) * 100即binpack插件的权重值越大，得分越高，某类资源的权重越大，该资源在打分时的占比越大。其中：binpack.weight为用户设置的装箱调度策略权重CPU.score为CPU资源得分，CPU.weight为CPU权重Memory.score为Memory资源得分，Memory.weight为Memory权重GPU.score为GPU资源得分，GPU.weight为GPU权重 图1 Binpack策略示例3️⃣ 如图1所示，假设集群中存在两个节点，分别为Node 1和Node 2，当前有一个Pod请求了CPU、内存和GPU资源。在调度Pod时，Binpack策略将对两个节点进行打分。假设集群中CPU.weight配置为1，Memory.weight配置为1，GPU.weight配置为2，binpack.weight配置为5。Binpack对Node 1的打分信息如下：各资源按照公式计算得分，具体信息如下：CPU Score：CPU.weight * (request + used) / allocatable = 1 * （2 + 4）/ 8 = 0.75Memory Score：Memory.weight * (request + used) / allocatable = 1 * (4 + 8) / 16 = 0.75GPU Score： GPU.weight * (request + used) / allocatable = 2 * （4 + 4）/ 8 = 2节点总得分按照 binpack.weight * (CPU.score + Memory.score + GPU.score) / (CPU.weight+ Memory.weight+ GPU.weight) * 100 公式进行计算，具体如下：假设binpack.weight配置为5，Node 1在Binpack策略下的得分：5 * （0.75 + 0.75 + 2）/（1 + 1 + 2）* 100 = 437.5Binpack对Node 2的打分信息如下：CPU Score：CPU.weight * (request + used) / allocatable = 1 * （2 + 6）/ 8 = 1Memory Score：Memory.weight * (request + used) / allocatable = 1 * (4 + 8) / 16 = 0.75GPU Score：GPU.weight * (request + used) / allocatable = 2 * （4 + 4）/ 8 = 2Node 2在Binpack策略下的得分：5 * （1 + 0.75 + 2）/（1 + 1 + 2）* 100 = 468.754️⃣ 综上，Node 2得分大于Node 1，按照Binpack策略，Pod将会优先调度至Node 2。  配置装箱调度策略  安装Volcano后，Binpack策略默认生效。如果默认配置无法达到您降低资源碎片的目标，可以通过“配置中心 > 调度配置”页面自定义Binpack策略权重和各资源维度权重值，增加或降低Binpack策略在整体调度中的影响力。1、登录CCE控制台，单击集群名称进入集群。2、在左侧选择“配置中心”，在右侧选择“调度配置”页签。3、在“资源利用率优化调度”配置中，启用装箱策略 (binpack)。名称说明默认值装箱调度策略权重增大该权重值，可提高装箱策略在整体调度中的影响力。10CPU权重增大该权重值，优先提高集群CPU利用率。1内存权重增大该权重值，优先提高集群Memory利用率。1自定义资源类型指定Pod请求的其他自定义资源类型，例如nvidia.com/gpu。增大该权重值，优先提高指定资源的利用率。-4、图2 资源利用率优化调度5、修改完成后，单击“确认配置”。 📌 更多Volcano云原生批量计算 技术应用，请访问社区仓库或官网：Volcano云原生批量计算社区官网：https://volcano.shVolcano GitHub 仓库: cid:link_6Volcano云原生批量计算公开课：cid:link_4华为云云容器引擎CCE：cid:link_5 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。 更多云原生技术动向关注容器魔方  

华为云云容器引擎CCE支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。一般情况下，Kubernetes在调度工作负载时会使用自带的默认调度器，若需要使用Volcano调度器的能力，您可以为工作负载指定调度器。关于Kubernetes调度器的详情请参见为Pod指定调度器。  约束与限制  调度大量工作负载的场景下，Volcano会打印较多的日志，建议搭配日志服务使用，否则可能导致日志过多占满所在节点磁盘。  使用Volcano调度工作负载  使用Volcano调度工作负载时，只需要在Pod的spec字段中设置schedulerName参数并指定参数值为volcano，示例如下：1、使用yaml创建queue：apiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: q1spec:  reclaimable: true  weight: 12、在Pod的spec字段中设置schedulerName参数并指定参数值为volcano：apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx  labels:    app: nginxspec:  replicas: 4  selector:    matchLabels:      app: nginx  template:    metadata:      annotations:        # 指定作业到q1队列        scheduling.volcano.sh/queue-name: "q1"        volcano.sh/preemptable: "true"      labels:        app: nginx    spec:      # 指定调度器为Volcano      schedulerName: volcano      containers:      - name: nginx        image: nginx        imagePullPolicy: IfNotPresent        resources:          limits:            cpu: 1            memory: 100Mi          requests:            cpu: 1            memory: 100Mi        ports:        - containerPort: 80 同时，Volcano还支持设置负载所属队列和抢占属性等，可通过Pod的注解实现。目前Volcano支持的Pod注解配置如下：Pod注解说明scheduling.volcano.sh/queue-name: "<queue-name>"指定负载所在队列，其中<queue-name>为队列名称。volcano.sh/preemptable: "true"表示作业是否可抢占。开启后，认为该作业可以被抢占。取值范围：true：开启抢占。（默认为开启状态）false：关闭抢占。 可通过查询Pod详情查看Pod是否由Volcano调度，以及被分配的队列：1、使用以下命令查询Pod详情并获取scheduling.k8s.io/group-name的值：kubectl describe pod <pod_name>Pod的scheduling.k8s.io/group-name值回显如下：2、查看Pod是否由Volcano调度，以及被分配的队列：kubectl describe pg <group_name>回显如下：Spec:  Min Member:  1  Min Resources:    Cpu:     100m    Memory:  100Mi  Queue:     q1Status:  Conditions:    Last Transition Time:  2023-05-30T01:54:43Z    Reason:                tasks in gang are ready to be scheduled    Status:                True    Transition ID:         70be1d7d-3532-41e0-8324-c7644026b38f    Type:                  Scheduled  Phase:                   RunningEvents:  Type    Reason     Age              From     Message  ----    ------     ----             ----     -------  Normal  Scheduled  0s (x3 over 2s)  volcano  pod group is ready 📌 更多Volcano云原生批量计算社区运用，请访问社区仓库或官网：Volcano云原生批量计算社区：https://volcano.shVolcano GitHub: cid:link_2Volcano云原生批量计算公开课：cid:link_0华为云云容器引擎CCE：cid:link_1 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。 更多云原生技术动向关注容器魔方 

 Volcano 是一个基于Kubernetes的云原生批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。  Volcano Scheduler  Volcano Scheduler是负责Pod调度的组件，它由一系列action和plugin组成。action定义了调度各环节中需要执行的动作；plugin根据不同场景提供了action 中算法的具体实现细节。Volcano Scheduler具有高度的可扩展性，您可以根据需要实现自己的action和plugin。图1 Volcano Scheduler工作流 Volcano Scheduler的工作流程如下：客户端提交的Job被调度器识别到并缓存起来。周期性开启会话，一个调度周期开始。将没有被调度的Job发送到会话的待调度队列中。遍历所有的待调度Job，按照定义的次序依次执行enqueue、allocate、preempt、reclaim、backfill等动作，为每个Job找到一个最合适的节点。将该Job 绑定到这个节点。action中执行的具体算法逻辑取决于注册的plugin中各函数的实现。关闭本次会话。  Volcano自定义资源  Pod组（PodGroup）：Pod组是Volcano自定义资源类型，代表一组强关联Pod的集合，主要用于批处理工作负载场景，比如Tensorflow中的一组ps和worker。队列（Queue）：容纳一组PodGroup的队列，也是该组PodGroup获取集群资源的划分依据。作业（Volcano Job，简称vcjob）：Volcano自定义的Job资源类型。区别于Kubernetes Job，vcjob提供了更多高级功能，如可指定调度器、支持最小运行Pod数、 支持task、支持生命周期管理、支持指定队列、支持优先级调度等。Volcano Job更加适用于机器学习、大数据、科学计算等高性能计算场景。应用扩缩容优先级策略（Balancer与BalancerPolicyTemplate）：开启Volcano应用扩缩容优先级策略后，将会在集群中新增两类CRD资源，其中BalancerPolicyTemplate用来进行优先级策略定义，Balancer用来申明扩缩容优先级的作用范围。一个Balancer CR资源对应一个BalancerPolicyTemplate CR资源，两者结合共同申明哪些工作负载使用了哪些优先级策略。详情请参见应用扩缩容优先级策略。 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。更多信息，请访问：Volcano云原生批量计算社区：https://volcano.shVolcano GitHub: cid:link_2Volcano云原生批量计算公开课：cid:link_0华为云云容器引擎CCE：cid:link_1 添加云原生小助手k8s2222进入技术交流群