在云原生技术快速普及的今天，Kubernetes（K8s）已成为容器编排的事实标准。然而，其复杂的命令行操作、陡峭的学习曲线以及零散的管理工具链，让许多开发者与运维团队望而却步。由微擎团队打造的 W7Panel 微擎面板，正是为解决这一痛点而生的可视化云原生综合管控平台。 一、产品概述W7Panel 并非要替代 Kubernetes 集群，而是作为其强大的“可视化驾驶舱”。它通过对底层复杂的容器编排能力进行图形化封装，将原本需要大量命令行和 YAML 文件的操作，整合至一个统一的 Web 界面。这使得用户无需深入理解 K8s 的繁琐细节，即可完成从应用部署、日常运维到故障排查的全生命周期管理，真正实现了“降低门槛，提升效率”的目标。 二、核心运维能力全景W7Panel 集成了集群运维所需的全部核心功能，让用户告别多工具切换的困扰：集群资源监控实时监控集群、节点及容器的运行状态，直观展示 CPU、内存等关键资源的使用情况，帮助用户快速掌握集群负载。应用统一管理支持通过镜像部署、YAML 文件导入、内置应用商店一键安装等多种方式创建应用，并可随时进行服务更新与弹性扩缩容。WebDAV 文件管理内置在线文件系统，支持配置文件和业务代码的上传下载、在线编辑、压缩解压及权限修改，无需额外搭建文件服务器。域名网关与证书管理可统一配置反向代理与业务域名，并支持自动申请、续期和管理 HTTPS 加密证书，保障业务安全。持久化存储管控提供统一的存储卷管理界面，轻松完成数据挂载与存储资源分配，确保业务数据持久化留存。日志与故障诊断集中汇总容器运行日志与集群事件，支持快速检索异常信息，高效定位并解决线上故障。节点运维工具提供服务器节点的配套运维功能，方便处理硬件资源与运行环境相关的维护操作。 三、差异化特色优势相较于传统的服务器面板或普通的 K8s 管理工具，W7Panel 拥有以下独到优势：标准化应用交付体系将应用封装为标准化单元，支持打包导出、批量分发、一键部署与版本更新，特别适合商用应用的分发场景。内置应用商店生态平台自带应用市场，汇集各类网站、接口服务及开发组件，开箱即用，大幅缩短项目搭建周期。集群私有 DNS 解析内置内网域名解析服务，简化集群内部服务调用，并支持内网连通性测试与网络问题排查。本地镜像全生命周期管理支持容器镜像的导入、导出、打包与版本管理，完美适配离线机房及自定义镜像迭代场景。一体化内置文件服务无需额外搭建 FTP 或文件服务器，在面板内即可完成所有业务文件与配置文件的统一管理。 四、与传统单机面板的本质区别W7Panel 面向的是集群化云原生场景，与市面上常见的单机服务器面板存在本质区别：对比维度传统单机面板微擎面板 W7Panel底层架构基于单机运行，无分布式调度能力依托 K8s 集群，支持多节点高可用与弹性扩容适用场景小型单机站点微服务、分布式系统、多业务集群等云原生项目管理范围仅负责网站基础运行覆盖应用、域名、存储、日志、监控等完整运维链路扩容迁移受单机硬件限制，跨机迁移繁琐计算存储分离，横向扩展简单高效使用门槛无容器概念屏蔽复杂 K8s 指令，可视化操作兼顾专业与易用 五、适用人群独立开发者希望低成本使用 K8s 部署个人项目，规避复杂命令行学习成本。中小型技术团队需要统一管控研发、测试、生产等多套环境，集中管理所有业务、域名与存储资源。运维工程师与平台管理员可为研发人员提供可视化操作权限，减少底层集群命令授权，降低日常运维工作量。私有化部署企业需要自主掌控业务数据与运行环境，不依赖第三方公有云托管服务。 六、产品定位W7Panel 拥有清晰的产品定位：它不是 仅适用于单台服务器的传统主机面板。它不是 只提供一键部署、缺乏深度运维能力的简易工具。它不是 只负责应用发布、缺少配套存储与域名管理的单一功能页面。它的核心定位是：一个面向 Kubernetes 集群、覆盖应用全生命周期的一体化云原生管控平台。 七、快速上手流程初次使用 W7Panel，可遵循以下标准化流程快速开展业务：集群接入绑定你的 Kubernetes 集群，查看节点资源与整体运行状态。业务部署通过应用商店、镜像仓库或配置文件创建你的业务应用。配套配置为应用绑定业务域名、开启 HTTPS、挂载存储卷，并管理业务文件。日常运维实时监控运行指标，查看运行日志，及时处理异常故障。更详细的功能说明与操作步骤，可参考官方发布的用户指南。

在云原生技术快速普及的今天，Kubernetes（K8s）已成为容器编排的事实标准。然而，其复杂的命令行操作、陡峭的学习曲线以及零散的管理工具链，使得许多开发者与运维团队望而却步。由微擎团队打造的 W7Panel 微擎面板，正是为解决这一痛点而生的可视化云原生综合管控平台。 一、产品定位：K8s的“可视化驾驶舱”W7Panel 并非要替代 Kubernetes 集群，而是作为其强大的“可视化驾驶舱”。它通过对底层复杂的容器编排能力进行图形化封装，将原本需要大量命令行和 YAML 文件的操作，整合至一个统一的 Web 界面。这使得用户无需深入理解 K8s 的繁琐细节，即可完成从应用部署、日常运维到故障排查的全生命周期管理，真正实现了“降低门槛，提升效率”的目标。 二、核心能力：一站式运维管理W7Panel 集成了集群运维所需的全部核心功能，让用户告别多工具切换的困扰：集群资源监控实时监控集群、节点及容器的运行状态，直观展示CPU、内存等关键资源的使用情况，帮助用户快速掌握集群负载。应用统一管理支持通过镜像部署、YAML文件导入、内置应用商店一键安装等多种方式创建应用，并可随时进行服务更新与弹性扩缩容。WebDAV文件管理内置在线文件系统，支持配置文件和业务代码的上传下载、在线编辑、压缩解压及权限修改，无需额外搭建文件服务器。域名网关与证书管理可统一配置反向代理与业务域名，并支持自动申请、续期和管理HTTPS加密证书，保障业务安全。持久化存储管控提供统一的存储卷管理界面，轻松完成数据挂载与存储资源分配，确保业务数据持久化留存。日志与故障诊断集中汇总容器运行日志与集群事件，支持快速检索异常信息，高效定位并解决线上故障。节点运维工具提供服务器节点的配套运维功能，方便处理硬件资源与运行环境相关的维护操作。 三、差异化优势：不止于管理相较于传统的服务器面板或普通的K8s管理工具，W7Panel拥有以下独到优势：标准化应用交付体系将应用封装为标准化单元，支持打包导出、批量分发、一键部署与版本更新，特别适合商用应用的分发场景。内置应用商店生态平台自带应用市场，汇集各类网站、接口服务及开发组件，开箱即用，大幅缩短项目搭建周期。集群私有DNS解析内置内网域名解析服务，简化集群内部服务调用，并支持内网连通性测试与网络问题排查。本地镜像全生命周期管理支持容器镜像的导入、导出、打包与版本管理，完美适配离线机房及自定义镜像迭代场景。一体化内置文件服务无需额外搭建FTP或文件服务器，在面板内即可完成所有业务文件与配置文件的统一管理。微应用扩展能力依托wujie微前端框架，支持第三方工具嵌入控制台，可按需拓展面板功能，灵活适配团队个性化需求。 四、与传统单机面板的本质区别W7Panel面向的是集群化云原生场景，与市面上常见的单机服务器面板在底层架构、适用场景和管理维度上存在本质区别： 对比维度传统服务器面板微擎面板 W7Panel底层架构基于单台服务器，无分布式调度能力依托K8s集群，支持多节点高可用与弹性扩容适用场景小型单机站点、简单博客官网微服务、分布式系统、多业务集群等云原生项目管理范围仅负责网站基础运行覆盖应用、域名、存储、日志、监控等完整运维链路扩容迁移受单机硬件限制，跨机迁移繁琐计算存储分离，横向扩展简单高效使用门槛无容器概念，适合简单建站屏蔽复杂K8s指令，可视化操作兼顾专业与易用    五、适用人群与场景W7Panel主要面向需要使用Kubernetes，但又不希望重度依赖命令行操作的用户，主要分为以下四类：独立开发者希望低成本使用K8s部署个人项目，规避复杂命令行学习成本，专注于业务开发。中小型技术团队需要统一管控研发、测试、生产等多套环境，集中管理所有业务、域名与存储资源，简化团队协作。运维工程师与平台管理员可为研发人员提供可视化操作权限，减少底层集群命令授权，降低日常运维工作量，提升故障处理效率。私有化部署企业需要自主掌控业务数据与运行环境，不依赖第三方公有云托管服务，确保数据安全与合规。

在云原生技术快速普及的今天，Kubernetes（K8s）已成为容器编排的事实标准。然而，其复杂的命令行操作、陡峭的学习曲线以及零散的管理工具链，使得许多开发者与运维团队望而却步。由微擎团队打造的 W7Panel 微擎面板，正是为解决这一痛点而生的可视化云原生综合管控平台。 一、产品概述W7Panel 并非要替代 Kubernetes 集群，而是作为其强大的“可视化驾驶舱”。它通过对底层复杂的容器编排能力进行图形化封装，将原本需要大量命令行和 YAML 文件的操作，整合至一个统一的 Web 界面。这使得用户无需深入理解 K8s 的繁琐细节，即可完成从应用部署、日常运维到故障排查的全生命周期管理，真正实现了“降低门槛，提升效率”的目标。 二、核心运维能力全景W7Panel 集成了集群运维所需的全部核心功能，让用户告别多工具切换的困扰：集群资源监控实时监控集群、节点及容器的运行状态，直观展示 CPU、内存等关键资源的使用情况，帮助用户快速掌握集群负载。应用统一管理支持通过镜像部署、YAML 文件导入、内置应用商店一键安装等多种方式创建应用，并可随时进行服务更新与弹性扩缩容。WebDAV 文件管理内置在线文件系统，支持配置文件和业务代码的上传下载、在线编辑、压缩解压及权限修改，无需额外搭建文件服务器。域名网关与证书管理可统一配置反向代理与业务域名，并支持自动申请、续期和管理 HTTPS 加密证书，保障业务安全。持久化存储管控提供统一的存储卷管理界面，轻松完成数据挂载与存储资源分配，确保业务数据持久化留存。日志与故障诊断集中汇总容器运行日志与集群事件，支持快速检索异常信息，高效定位并解决线上故障。节点运维工具提供服务器节点的配套运维功能，方便处理硬件资源与运行环境相关的维护操作。 三、差异化特色优势相较于传统的服务器面板或普通的 K8s 管理工具，W7Panel 拥有以下独到优势：标准化应用交付体系将应用封装为标准化单元，支持打包导出、批量分发、一键部署与版本更新，特别适合商用应用的分发场景。内置应用商店生态平台自带应用市场，汇集各类网站、接口服务及开发组件，开箱即用，大幅缩短项目搭建周期。集群私有 DNS 解析内置内网域名解析服务，简化集群内部服务调用，并支持内网连通性测试与网络问题排查。本地镜像全生命周期管理支持容器镜像的导入、导出、打包与版本管理，完美适配离线机房及自定义镜像迭代场景。一体化内置文件服务无需额外搭建 FTP 或文件服务器，在面板内即可完成所有业务文件与配置文件的统一管理。微应用扩展能力依托 wujie 微前端框架，支持第三方工具嵌入控制台，可按需拓展面板功能，灵活适配团队个性化需求。 四、与传统单机面板的本质区别W7Panel 面向的是集群化云原生场景，与市面上常见的单机服务器面板在底层架构、适用场景和管理维度上存在本质区别：对比维度传统服务器面板微擎面板 W7Panel底层架构基于单台服务器，无分布式调度能力依托 K8s 集群，支持多节点高可用与弹性扩容适用场景小型单机站点、简单博客官网微服务、分布式系统、多业务集群等云原生项目管理范围仅负责网站基础运行覆盖应用、域名、存储、日志、监控等完整运维链路扩容迁移受单机硬件限制，跨机迁移繁琐计算存储分离，横向扩展简单高效使用门槛无容器概念，适合简单建站屏蔽复杂 K8s 指令，可视化操作兼顾专业与易用 五、适用人群W7Panel 主要面向需要使用 Kubernetes，但又不希望重度依赖命令行操作的用户，主要分为以下四类：独立开发者希望低成本使用 K8s 部署个人项目，规避复杂命令行学习成本，专注于业务开发。中小型技术团队需要统一管控研发、测试、生产等多套环境，集中管理所有业务、域名与存储资源，简化团队协作。运维工程师与平台管理员可为研发人员提供可视化操作权限，减少底层集群命令授权，降低日常运维工作量，提升故障处理效率。私有化部署企业需要自主掌控业务数据与运行环境，不依赖第三方公有云托管服务，确保数据安全与合规。 六、产品定位W7Panel 拥有清晰的产品定位，它不是仅适用于单台服务器的传统主机面板，不是只提供一键部署、缺乏深度运维能力的简易工具，也不是只负责应用发布、缺少配套存储与域名管理的单一功能页面。其核心定位是：一个面向 Kubernetes 集群、覆盖应用全生命周期的一体化云原生管控平台。

9月8日至9日，全球云原生与 AI 基础设施顶级盛会 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 将于上海国际会议中心举行，CNCF、OpenInfra、PyTorch 三大基金会首次齐聚，云原生、开放基础设施与 AI 三大技术生态将在同一会场交汇。本届大会值得关注的变化，是焦点从“模型能力”推进到了“Agent 规模化落地”——当 Agent 成为企业生产力的组成部分，从算力调度到智能体平台，技术栈的各层能力都在向 Agent 场景持续优化和适配。作为战略级赞助商，华为将在会上全方位分享从算力底座到智能体应用等开源创新与产业实践，既有通智融合调度、多云算力池化、云边AI协同、Agentic AI 容器等开源基础设施层面的深耕，也有企业级智能体平台的商用赋能。本文与你一探究竟： ▍01 面向 AI 训推、RL、Agent 的全场景统一调度大模型与智能体应用正加速迈向生产环境，传统云原生架构在面对万卡扩展性、异构算力碎片化以及 RL/Agent 高并发短生命周期任务时，面临高延迟与资源浪费等挑战。针对这些智算瓶颈，华为云开源技术团队协同社区伙伴，以 CNCF Volcano 为内核，给出了一套解法——构建一条从集群调度、推理服务到 Agent 运行时的完整云原生 AI 技术栈，实现通智一体化调度：调度层，夯实通智一体调度基座：Volcano 在成熟的云原生批量调度能力基础上，面向高并发、短生命周期的 Agent 任务推出 Agent Scheduler，通过多 Worker 并行调度与乐观并发控制提升调度效率；结合 NodeShard 动态节点分片与队列管理，实现 Batch Scheduler 和 Agent Scheduler 的资源协同，兼顾训练作业的规模化运行与推理、Agent 任务的快速响应，形成训推一体、通智协同的调度最佳实践。推理层，突破大模型推理瓶颈：面向 LLM 生产部署的推理服务平台 Kthena 支持 PD 分离部署与PD场景下的自动扩缩容。支持多种可组合的流量路由策略，兼容 vLLM/SGLang 等主流推理引擎， 在复杂对话场景下可帮助企业降低 20% 以上的全局延迟。运行时层，专为 AI Agent 打造的弹性沙箱引擎：Volcano 社区面向 Agent 工作负载的 AgentCube，原生支持 AI Agent 的轻量级与有状态运行时；以预热池（Warm Pool）技术实现隔离容器毫秒级拉起，为多 Agent 并发协同提供类 Serverless 的极速体验。现场相关议题，欢迎关注：🎙️ 议题：Serving AI at Massive Scale: The Cloud-Native Inference Plane Behind Huawei Celia[1]  (Kevin Wang, CNCF TOC Vice Chair , Tech Lead of Cloud Native Open Source， Huawei )🎙️议题：Volcano: A Unified Scheduling Platform for Cloud Native AI[2] ( Zicong Chen, Volcano Maintainer, Software Engineer at Huawei Cloud; DongYang, WangCloud Native AI Infrastructure Engineer,SenseTime)🎙️ 议题：Accelerating RL with AgentCube: Cloud-Native Multi-Agent Collaboration[3]（Zhencheng Lee,Senior Cloud Develop Engineer at Huawei Cloud）🎙️议题：Beyond Model Sharding: Atomic Scheduling and Disaggregated LLM Serving with LeaderWorkerSet[4] (Kay Yan， Principal Software Engineer, DaoCloud； Zicong Chen , Volcano Maintainer, Software Engineer at Huawei Cloud）📍 欢迎打卡 Volcano 社区展台（9月8日15:00-19:00，9月9日 13:15-15:30，T-2，Grand Ballroom I ） 与技术大咖面对面，来自华为云等企业的社区专家将现场探讨云原生 AI 调度的前沿方向与实践经验。 ▍02 打破资源边界，跨云 AI 算力池化算力不应该被困在单一集群里。当企业同时拥有公有云、私有云与边缘节点，算力管控的复杂度随拓扑同步上升：训练任务需要弹性，推理任务需要就近，业务高峰需要冗余。云原生多云编排引擎 Karmada  正成为企业构建跨云“超级 AI 算力池”的核心纽带，让算力在不同环境之间按需流动：海量 AI 任务跨集群动态分发：通过 Karmada 统一联邦控制面，根据公有云、私有云及边缘端的异构算力空闲度，自动分发大规模 AI 训练与推理任务，让算力匹配任务，而不是让任务迁就集群。生产级高可用与渐进式交付：联合 Argo 实现单一声明式规范下的跨云 Canary 灰度发布；支持有状态工作负载在集群故障时平滑迁移与数据恢复，为跨云生产环境提供可靠性保障。🎙️ 议题：Building a Multi-Cluster Progressive Delivery Platform with Karmada & Argo[5] (Zhuang Zhang, Karmada Maintainer, Software Engineer at Huawei  Cloud)🎙️ 议题：Karmada Project Lightning Talk[6]（Hongcai Ren, Karmada Maintainer，Senior Software Engineer at Huawei Cloud; Maintainer, Yiheng Ci ）🎙️ 议题：Multi-cluster Orchestration System: Karmada Updates and Use Cases[7]（Hongcai Ren, Karmada Maintainer，Senior Software Engineer at Huawei Cloud; Zongqing Li,Senior Cloud-Native R&D Engineer, Trip.com ）📍 华为云技术人员将在 Karmada 社区展台（9月8日 10:30-14:30, 9月9日 10:30-12:45, T-2,Grand Ballroom I ） 驻场，与现场开发者共同探讨分布式云原生与多云 AI 算力池化的技术与案例，欢迎现场交流。 ▍03 云边协同：KubeEdge驱动边缘AI规模化演进作为 CNCF 首个毕业的云原生边缘计算项目，KubeEdge 已广泛应用于交通、能源、制造、航天、汽车等各行各业。本届大会，来自华为云，Harmony Cloud 和 VMware 的 KubeEdge TSC 成员将联合带来“毕业报告”式的深度分享。核心架构层面，解析 KubeEdge 如何通过松耦合设计高效管理海量边缘节点与应用；落地实践层面，直面智慧城市、工业物联网 (IIoT)、边缘人工智能、机器人和零售等多个行业的实际部署案例场景真实挑战，分享应对策略；生态层面，解读全新发布的 Certified KubeEdge 一致性认证体系及社区治理的最新动态，为计划规模化落地边缘AI的企业提供参考路径。🎙️ 议题：Solving Industrial Challenges with KubeEdge: A Post-Graduation Report[8]（Yue Bao, Senior Software Engineer at Huawei Cloud; Huan Wei, Senior Technical Director, Harmony Cloud; Yin Ding, Engineering Leader at VMware ） ▍04 赋能企业级智能落地，华为云 AgentArts 等产品重磅亮相作为本届 KubeCon 的重要看点之一，华为云智果 AgentArts 智能体平台、 华为云果办 OfficeAce 办公智能体 、openJiuwen 等一系列智能体相关的产品与创新技术也将重磅亮相。华为云智果（AgentArts）是面向企业级 AI Agent 的全生命周期工程与运行底座，助力企业快速构建、部署和运营能自主执行任务的AI智能体。它向下纳管计算与模型资源，提供完整的 Agent 托管能力。向上对编排、运行与运维进行标准化，通过引入多层控制器、自进化、Agent 认证鉴权、Agent 记忆、会话级隔离、动态令牌和精细化权限控制等机制，解决 Agent 落地生产环境时的工程化与合规难题，为智能体的高并发调度、复杂流程执行、数据安全合规及自动化运维提供标准化、可观测的 Harness 基础设施支撑。openJiuwen 与 AgentArts 内核同源度超过 90%，通过开放核心框架和底层能力，大幅降低了企业及软件开发服务商的二次开发门槛，支持开发者基于开源版本构建本地化、兼容企业生态的智能体应用。其 WorkSwarm 蜂群智能体的多任务模式与高效协同，结合 Coordination Engineering 的多智能体标准化范式 与 Agent Swarm 的双层协同自演进机制，在底层算力亲和加速的保障下 ，全面助力智能体快速构建与应用，携手行业伙伴共同打造智能体生态。华为云果办（OfficeAce）是一款面向个人与企业用户的办公全场景智能体，以AI重构桌面办公体验，通过自动化处理重复事务、智能整合信息及协作辅助，为企业员工打造具备专业 Skills 技能的 Agent 专家团队，将用户从繁琐操作中解放出来，大幅提升办公效率；同时，面向企业提供智能体接入、统一运营、安全治理等企业级能力，推动 AI 从单点办公辅助融入真实业务流程，实现规模化应用。🎙️ 议题：openJiuwen A2X Registry: An Efficient MCP Service Registration and Discovery Solution[9] ( Wei Zheng,Senior Engineer, Huawei)🎙️ 议题：Coordination Engineering：The Next Leap of AI Agent Engineering Paradigm[10] (Shuo Cheng, Agent Technical Expert, Huawei)📍 欢迎亲临华为云“智能体全栈平台 Full-Stack Agent Platform”展台（9月8日-9日，Grand Ballroom I 华为展区），现场体验华为云智能体平台从开发、部署到运营的全流程能力。 ▍05 AI 算力底座：面向 Agentic AI 的容器基础设施作为全球云原生与 AI 领域的先驱者与 CNCF 创始成员，华为云凭借多年来的产业实践和技术创新，引领面向 Agentic AI 的容器基础设施，为企业级 Agent 运行提供调度、弹性与安全的一体化支撑，并以丰富的商用落地实践，为智能体规模化应用持续赋能：在调度层面，基于 Volcano 实现 CPU 与 GPU 异构算力的统一调度，满足 AI 训练、推理及 Agent 任务对计算资源的差异化需求。在安全隔离层面，升级 Agent Sandbox 安全沙箱技术，实现轻量级隔离与亚秒级极速冷启动，为高频工具调用与动态代码执行提供全链路安全保障。弹性层面，依托 CCE Turbo 的极速扩容、资源预热与异构算力加速能力，结合 CCE Autopilot 与 CCI 的 Serverless 容器弹性，提供从资源预热、亚秒级扩容到超大资源池的端到端弹性能力，从容应对 Agent 任务突发流量与资源洪峰。同时，华为云 AI 容器团队持续参与 Volcano、Karmada、KubeEdge、Kmesh 等开源社区的贡献与建设，推动云原生技术生态从 AI Native 向 Agentic Native 演进。📍 欢迎打卡 KubeCon China 2026 “面向 Agentic AI 的容器基础设施”展台（9月8日-9日，Grand Ballroom 1 华为展区）， 现场直击 CCE Autopilot + CCI 秒级弹性伸缩与 Agent Sandbox 安全隔离实效，解锁企业级容器 AI 新引擎。从开源社区的前沿探索到企业级商用落地，华为云全栈架构创新极致重构 AI 算力底座，让智能体跑在坚实的算力底座上，也让平台能力真正转化为企业生产力，为千行万业在 Agentic AI 时代的智能化转型提供澎湃动力。期待与您共赴 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026，共探 Agent 时代无尽可能！👉 访问大会官网获取完整议程：https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/议题索引[1] Serving AI at Massive Scale: The Cloud-Native Inference Plane Behind Huawei Celia:https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1224671[2] Volcano: A Unified Scheduling Platform for Cloud Native AI: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222060[3] Accelerating RL with AgentCube: Cloud-Native Multi-Agent Collaboration: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1304033[4] Beyond Model Sharding: Atomic Scheduling and Disaggregated LLM Serving with LeaderWorkerSet: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222146[5] Building a Multi-Cluster Progressive Delivery Platform with Karmada & Argo: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1225153[6] Karmada Project Lightning Talk: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222021[7] Multi-cluster Orchestration System: Karmada Updates and Use Cases:https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222012[8] Solving Industrial Challenges with KubeEdge: A Post-Graduation Report: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1225125[9] openJiuwen A2X Registry: An Efficient MCP Service Registration and Discovery Solution:https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/?id=1242199[10] Coordination Engineering：The Next Leap of AI Agent Engineering Paradigm: https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/?id=1227642 关注魔方公众号，获取更多前沿资讯

“这 YAML 文件怎么又写错了？”,“kubectl logs 看了半天，日志在哪？”,“域名、存储、监控……能不能在同一个地方搞定？” 这是不是每个K8s运维和开发人员每天的真实写照？ Kubernetes 的强大毋庸置疑，但它的复杂性和陡峭的学习曲线，也成了无数开发者迈向云原生路上的“拦路虎”。面对满屏的命令行和分散的管理工具，你是不是也渴望一个能“一统江湖”的利器？ 今天，我们就来深度评测一款专为解决这一痛点而生的产品——微擎面板 W7Panel。它不是一个简单的“花架子”，而是一个真正能让你把K8s运维效率“拉满”的全生命周期管理平台。 一、微擎面板是什么？一张图对比传统面板简单来说，微擎面板（W7Panel）就是Kubernetes的“可视化司令部”。它不替代K8s，而是将K8s底层复杂的命令行操作，转化为直观、易用的图形化界面。 我们用一个表格，看看它和传统服务器面板的天壤之别： 维度传统服务器面板微擎面板 W7Panel管理对象单台服务器整个K8s集群核心场景网站、数据库、FTP分布式应用、微服务、云原生操作方式点击管理单个服务可视化编排整个应用生命周期目标用户站长、个人开发者研发团队、运维工程师、平台团队   划重点： 微擎面板不是让你“一键搭建WordPress”，而是让你“一键部署、管理、运维一个由多个微服务组成的、高可用的云原生应用”。 二、功能全覆盖：从“能用”到“好用”的质变微擎面板将原本分散在 kubectl、Dashboard、Ingress Controller、StorageClass 等工具中的能力，全部整合到一个统一界面，实现了真正的“一站式”： 集群状态，一目了然告别 kubectl top nodes 和 kubectl get pods -A。现在，集群节点、命名空间、Pod的运行状态、资源消耗（CPU/内存）以可视化图表呈现，异常节点和Pod一眼就能识别，点击即可进行扩缩容、重启等操作。  应用部署，像逛应用商店内置丰富的应用商店，从数据库到中间件，一键部署。独创的“标准化应用交付单元”，让团队可以轻松打包自己的业务应用，实现“一次打包，到处运行”，版本迭代和灰度发布也变得异常简单。强大的 MicroApp 拓展机制，允许你或社区开发各种插件，无缝融入控制台，实现无限功能扩展。  网络配置，傻瓜式操作统一管理域名、证书、路由。配置HTTPS？只需在面板中输入域名，选择证书，系统自动完成Ingress配置和SSL证书绑定。内置私有DNS，解决了集群内部服务发现和调试的痛点，再也不用记住复杂的Service名称。  文件管理，本地体验集成了完整的 WebDAV 文件系统。你可以像管理本地电脑一样，在线编辑、上传、下载、压缩、解压Pod内的文件，甚至可以直接在面板上管理集群的本地镜像仓库，提交、导入、删除镜像，无需登录服务器。  日志事件，快速排障聚合了所有Pod的日志和集群事件。服务报错、资源异常，不用再 SSH 到节点上敲 journalctl 或 kubectl describe，所有信息都在一个界面里，按时间线清晰排列，排障效率提升数倍。 三、用了微擎面板，你能获得什么？告别“命令恐惧”零基础也能玩转K8s，让团队成员从繁琐的命令行中解放出来，专注于业务本身。告别“多工具切换”一个面板搞定所有，大幅减少上下文切换带来的时间浪费和认知负荷。应用交付“快人一步”从开发到测试再到生产，标准化应用包让交付链路更顺畅，迭代周期更短。数据安全“尽在掌握”支持私有化部署，所有数据留在你的环境内，满足企业最严苛的数据合规和隐私保护要求。故障处理“快、准、稳”集中式的监控、日志和事件，让问题定位时间从“小时级”缩短到“分钟级”。 四、这些人，现在就应该试试 个人开发者想用K8s搭建个人项目，但不想在运维上耗费过多精力，专注代码本身。 中小研发团队没有专职运维，开发人员需要一套简单、直观的工具来自助发布和管理应用。️ 运维/平台团队需要为整个研发团队提供一个低门槛、标准化的集群操作界面，解放自己，赋能他人。 政企/内网用户对数据安全和自主可控有极高要求，需要一个不依赖任何公有云、完全本地化的云原生管理平台。 五、新手入门，一分钟上手接入集群在W7Panel中输入你的K8s集群连接信息，秒级接入。部署应用从应用商店一键安装或上传你的标准化应用包。配置网络为你的应用绑定域名，配置SSL证书，开启对外服务。管理文件通过WebDAV连接到Pod，编辑配置文件或上传静态资源。日常运维查看监控仪表盘，浏览日志，轻松应对各种突发状况。 写在最后Kubernetes 是云原生时代的“操作系统”，而微擎面板 W7Panel 就是那个让所有人都能轻松驾驭这个操作系统的“图形化桌面”。它弥补了K8s在易用性上的短板，让云原生的强大能力真正服务于每一个人。 如果你正在使用K8s，并且厌倦了繁琐的命令行和多工具切换的混乱，不妨试试微擎面板。它或许就是你一直在寻找的，那把开启云原生高效运维之门的钥匙。

在云原生技术快速普及的今天，Kubernetes（K8s）已成为容器编排的事实标准。然而，其复杂的命令行操作、陡峭的学习曲线以及零散的管理工具链，让许多开发者与运维团队望而却步。由微擎团队打造的 W7Panel 微擎面板，正是为解决这一痛点而生的可视化云原生综合管控平台。 一、产品概述W7Panel 并非要替代 Kubernetes 集群，而是作为其强大的“可视化驾驶舱”。它通过对底层复杂的容器编排能力进行图形化封装，将原本需要大量命令行和 YAML 文件的操作，整合至一个统一的 Web 界面。这使得用户无需深入理解 K8s 的繁琐细节，即可完成从应用部署、日常运维到故障排查的全生命周期管理，真正实现了“降低门槛，提升效率”的目标。 二、核心运维能力全景W7Panel 集成了集群运维所需的全部核心功能，让用户告别多工具切换的困扰：集群资源监控实时监控集群、节点及容器的运行状态，直观展示 CPU、内存等关键资源的使用情况，帮助用户快速掌握集群负载。应用统一管理支持通过镜像部署、YAML 文件导入、内置应用商店一键安装等多种方式创建应用，并可随时进行服务更新与弹性扩缩容。WebDAV 文件管理内置在线文件系统，支持配置文件和业务代码的上传下载、在线编辑、压缩解压及权限修改，无需额外搭建文件服务器。域名网关与证书管理可统一配置反向代理与业务域名，并支持自动申请、续期和管理 HTTPS 加密证书，保障业务安全。持久化存储管控提供统一的存储卷管理界面，轻松完成数据挂载与存储资源分配，确保业务数据持久化留存。日志与故障诊断集中汇总容器运行日志与集群事件，支持快速检索异常信息，高效定位并解决线上故障。节点运维工具提供服务器节点的配套运维功能，方便处理硬件资源与运行环境相关的维护操作。 三、差异化特色优势相较于传统的服务器面板或普通的 K8s 管理工具，W7Panel 拥有以下独到优势：标准化应用交付体系将应用封装为标准化单元，支持打包导出、批量分发、一键部署与版本更新，特别适合商用应用的分发场景。内置应用商店生态平台自带应用市场，汇集各类网站、接口服务及开发组件，开箱即用，大幅缩短项目搭建周期。集群私有 DNS 解析内置内网域名解析服务，简化集群内部服务调用，并支持内网连通性测试与网络问题排查。本地镜像全生命周期管理支持容器镜像的导入、导出、打包与版本管理，完美适配离线机房及自定义镜像迭代场景。一体化内置文件服务无需额外搭建 FTP 或文件服务器，在面板内即可完成所有业务文件与配置文件的统一管理。 四、与传统单机面板的本质区别W7Panel 面向的是集群化云原生场景，与市面上常见的单机服务器面板存在本质区别：对比维度传统单机面板微擎面板 W7Panel底层架构基于单机运行，无分布式调度能力依托 K8s 集群，支持多节点高可用与弹性扩容适用场景小型单机站点微服务、分布式系统、多业务集群等云原生项目管理范围仅负责网站基础运行覆盖应用、域名、存储、日志、监控等完整运维链路扩容迁移受单机硬件限制，跨机迁移繁琐计算存储分离，横向扩展简单高效使用门槛无容器概念屏蔽复杂 K8s 指令，可视化操作兼顾专业与易用 五、适用人群独立开发者希望低成本使用 K8s 部署个人项目，规避复杂命令行学习成本。中小型技术团队需要统一管控研发、测试、生产等多套环境，集中管理所有业务、域名与存储资源。运维工程师与平台管理员可为研发人员提供可视化操作权限，减少底层集群命令授权，降低日常运维工作量。私有化部署企业需要自主掌控业务数据与运行环境，不依赖第三方公有云托管服务。 六、产品定位W7Panel 拥有清晰的产品定位：它不是 仅适用于单台服务器的传统主机面板。它不是 只提供一键部署、缺乏深度运维能力的简易工具。它不是 只负责应用发布、缺少配套存储与域名管理的单一功能页面。它的核心定位是：一个面向 Kubernetes 集群、覆盖应用全生命周期的一体化云原生管控平台。 七、快速上手流程初次使用 W7Panel，可遵循以下标准化流程快速开展业务：集群接入绑定你的 Kubernetes 集群，查看节点资源与整体运行状态。业务部署通过应用商店、镜像仓库或配置文件创建你的业务应用。配套配置为应用绑定业务域名、开启 HTTPS、挂载存储卷，并管理业务文件。日常运维实时监控运行指标，查看运行日志，及时处理异常故障。更详细的功能说明与操作步骤，可参考官方发布的用户指南。 项目地址：http://github.com/w7panel/w7panel

一、产品概述：Kubernetes 的“平民化”入口在数字化转型的浪潮中，Kubernetes 已成为云原生时代的事实标准，但其复杂的命令行操作、陡峭的学习曲线和分散的运维工具，让许多个人开发者与中小企业望而却步。微擎面板（W7Panel）正是为解决这一痛点而生。它是一款基于 Kubernetes 架构打造的云原生应用全生命周期管理平台，其核心价值在于不替代 Kubernetes，而是作为可视化的统一运维控制台，将原本分散的命令行、配置文件和独立工具，整合为一个直观、易用的图形界面 。 该平台致力于成为云原生场景下的一站式管理入口，覆盖从应用部署上线、日常运维到故障排查的完整链路，实现对集群、应用、文件、域名、存储和日志的一体化集中管控，显著降低了云原生技术的使用门槛 。 二、核心功能：一站式全链路运维微擎面板将云原生运维的日常高频操作整合到统一平台，其核心功能覆盖了以下七大模块：集群资源监控实时查看集群、节点和容器的运行状态与资源占用情况，帮助用户直观掌握集群整体负载和健康状态 。应用部署管理支持通过应用商店、Docker Compose、Helm、YAML 等多种方式创建、更新和扩缩容应用，实现对业务服务的统一管控 。文件与配置维护内置 WebDAV 文件管理功能，支持在线浏览、编辑、上传下载、压缩解压和权限调整，方便统一管理业务配置文件与容器内文件 。域名与访问网关提供一站式配置业务域名和反向代理的功能，并可自动签发与管理 Let's Encrypt 免费 HTTPS 证书，统一管理外部访问入口 。持久化存储管控统一管理集群存储卷，处理数据持久化挂载和存储资源分配，基于分布式存储方案保障业务数据稳定留存 。日志与故障排查集中查看应用运行日志和集群事件，快速定位运行异常，完成线上问题诊断 。节点侧运维提供贴近日常运维的节点操作能力，用于处理服务器资源、运行环境相关的维护工作 。 三、差异化核心特色与常规的 K8s 管理工具相比，微擎面板具备多项独有功能，形成了鲜明的产品辨识度：标准化应用交付将应用从单纯的镜像或 YAML 配置升级为标准化交付单元，支持打包、分发、一键安装和持续更新，适配商业化应用分发场景 。内置应用商店集成统一的应用市场，各类网站、服务、数据库（如 MySQL、Redis）和 AI 组件均可一键部署，大幅缩短项目落地周期 。MicroApp 微应用集成基于 wujie 框架实现子应用嵌入，第三方业务工具可以无缝集成进面板控制台，灵活拓展平台能力边界 。集群私有 DNS 解析内置私有域名解析能力，支持集群内部服务互通、内网代理和网络连通诊断，简化内部调用配置 。本地镜像全生命周期管理支持集群本地镜像的查看、导入、打包提交和版本整理，完美适配离线部署和自定义镜像迭代场景 。智能应用依赖管理具备自动检测与配置依赖应用的能力，例如安装 WordPress 时会自动检查 MySQL 并配置连接参数，让部署更智能 。GPU 算力虚拟化支持 vGPU 技术，允许像分配 CPU 和内存一样灵活调度 GPU 资源，单卡支持多应用共享，大幅降低 AI 算力成本 。 四、微擎面板 vs. 传统服务器面板微擎面板与传统服务器面板在底层架构、适用场景和管理维度上存在本质区别，是对传统运维模式的全面升级 ： 对比维度传统服务器面板微擎面板（W7Panel）底层架构基于单台服务器，无集群编排能力基于 K8s 集群，支持多节点弹性调度与高可用核心场景个人单机建站、本地网站运维云原生应用、微服务、多节点集群业务管理管理范围主要关注服务是否正常运行覆盖应用交付、域名、存储、日志、排障全链路扩展能力受单机硬件限制，跨节点迁移复杂计算存储解耦，支持集群弹性扩容与分布式存储技术门槛面向传统单机运维，无容器概念屏蔽底层 K8s 复杂命令，可视化操作兼具云原生能力   五、适用用户群体微擎面板主要面向需要使用 Kubernetes，但又不希望重度依赖命令行操作的用户，主要分为以下四类 ：个人开发者自主搭建网站、API 接口或小程序等项目，希望轻量化管理云原生应用，降低学习成本，专注于业务开发 。中小技术团队统一管理多套业务应用、域名、文件和存储，将研发与测试环境的运维入口集中，简化团队协作，提升整体效率 。运维 / 平台团队为研发和业务人员提供低门槛的 K8s 可视化操作界面，减少底层命令行操作授权，降低运维负担，实现运维标准化 。私有化部署项目方需要自主掌控应用、业务数据与运行环境，不依赖第三方公有云平台的企业或项目，确保数据安全与合规 。 六、产品定位与边界微擎面板有清晰的产品定位，并非以下类型的工具 ：不是脱离 Kubernetes、仅适用于单机的通用服务器面板。不是仅提供一键安装、缺乏后期持续维护能力的简易部署工具。不是只负责应用发布，而缺失文件、域名、存储、故障排查等功能的单一页面。其本质是围绕应用全生命周期设计的一体化云原生管控平台，而非单一功能工具。 七、快速上手：从安装到部署的极简路径微擎面板的安装流程被简化到极致，即使是零基础的用户也能快速上手 ：环境准备确保服务器配置不低于 2 核 4G，并开放 6443、80、443、9090 四个关键端口 。一键安装在服务器终端执行以下命令，约 10 分钟即可完成部署 ：curl -sfL https://cdn.w7.cc/w7panel/install.sh | sh -首次配置安装成功后，访问 http://{服务器IP}:9090，设置管理员账号密码即可进入主界面 。新手操作逻辑初入面板，可遵循以下链路理解其操作流程 ：环境接入首先接入集群，查看节点状态与整体资源运行环境。应用交付通过应用商店或自定义方式，创建、部署和管理业务应用。配套配置配置域名和 HTTPS 访问入口，挂载持久化存储，管理业务文件。运维排障在运行期间持续监控状态、查看日志，处理故障并完成日常运维。该平台设计初衷是串联部署、接入、维护、排障的全流程，为用户提供一套完整、高效、易用的云原生管理解决方案。

一、产品概述微擎面板（W7Panel）是一款基于 Kubernetes 架构打造的云原生应用全生命周期管理平台。它并非要替代 Kubernetes，而是作为一个可视化的统一运维控制台，将原本分散在命令行、配置文件和多个独立运维工具中的操作，整合到一个直观的图形界面中，旨在解决云原生技术底层操作复杂、门槛高、日常运维繁琐等痛点问题。 该平台是面向云原生场景的一站式管理入口，覆盖了应用从部署上线、日常运维到故障排查的完整业务链路，实现了对集群、应用、文件、域名、存储和日志的一体化集中管控。 二、核心功能：一站式全链路运维微擎面板将云原生运维的日常高频操作整合到统一平台，核心功能覆盖以下七大模块：集群资源监控实时查看集群、节点和容器的运行状态与资源占用情况，帮助用户掌握集群整体负载。应用部署管理支持通过镜像、YAML、应用商店等多种方式创建、更新和扩缩容应用，实现对业务服务的统一管控。文件与配置维护内置 WebDAV 文件管理功能，支持在线浏览、编辑、上传下载、压缩解压和权限调整，方便统一管理业务配置文件。域名与访问网关提供一站式配置业务域名和反向代理的功能，并可自动签发与管理 HTTPS 证书，统一管理外部访问入口。持久化存储管控统一管理集群存储卷，处理数据持久化挂载和存储资源分配，保障业务数据稳定留存。日志与故障排查集中查看应用运行日志和集群事件，快速定位运行异常，完成线上问题诊断。节点侧运维提供贴近日常运维的节点操作能力，用于处理服务器资源和运行环境相关的维护工作。 三、差异化核心特色与常规的 Kubernetes 管理工具相比，微擎面板具备多项独有功能，形成了鲜明的产品辨识度：标准化应用交付将应用从单纯的镜像或 YAML 配置升级为标准化交付单元，支持打包、分发、一键安装和持续更新，适配商业化应用分发场景。内置应用商店集成统一的应用市场，各类网站、服务和组件均可一键部署，大幅缩短项目落地周期。MicroApp 微应用集成基于 wujie 框架实现子应用嵌入，第三方业务工具可以无缝集成进面板控制台，拓展平台能力边界。集群私有 DNS 解析内置私有域名解析能力，支持集群内部服务互通、内网代理和网络连通诊断，简化内部调用配置。本地镜像全生命周期管理支持集群本地镜像的查看、导入、打包提交和版本整理，适配离线部署和自定义镜像迭代场景。一体化 WebDAV 文件工具无需额外搭建文件服务，即可在面板内完成业务文件的全部操作，兼顾线上文件维护与配置修改需求。 四、微擎面板 vs. 传统服务器面板微擎面板与传统服务器面板在底层架构、适用场景和管理维度上存在本质区别： 对比维度传统服务器面板微擎面板（W7Panel）底层架构基于单台服务器，无集群编排能力基于 K8s 集群，支持多节点弹性调度与高可用核心场景个人单机建站、本地网站运维云原生应用、微服务、多节点集群业务管理管理范围主要关注服务是否正常运行覆盖应用交付、域名、存储、日志、排障全链路扩展能力受单机硬件限制，跨节点迁移复杂计算存储解耦，支持集群弹性扩容与分布式存储技术门槛面向传统单机运维，无容器概念屏蔽底层 K8s 复杂命令，可视化操作兼具云原生能力    五、适用用户群体微擎面板主要面向需要使用 Kubernetes，但又不希望重度依赖命令行操作的用户，主要分为以下四类：个人开发者自主搭建网站、API 接口或小程序等项目，希望轻量化管理云原生应用，降低学习成本。中小技术团队统一管理多套业务应用、域名、文件和存储，将研发与测试环境的运维入口集中，简化团队协作。运维/平台团队为研发和业务人员提供低门槛的 K8s 可视化操作界面，减少底层命令行操作授权，降低运维负担。私有化部署项目方需要自主掌控应用、业务数据与运行环境，不依赖第三方公有云平台的企业或项目。 六、产品定位与边界微擎面板有清晰的产品定位，并非以下类型的工具：它不是脱离 Kubernetes、仅适用于单机的通用服务器面板。它不是仅提供一键安装、缺乏后期持续维护能力的简易部署工具。它不是只负责应用发布，而缺失文件、域名、存储、故障排查等功能的单一页面。其本质是围绕应用全生命周期设计的一体化云原生管控平台，而非单一功能工具。 七、新手使用逻辑初次使用微擎面板，可以遵循以下业务链路来理解其操作逻辑：环境接入首先接入集群，查看节点状态与整体资源运行环境。应用交付创建、部署和管理各类业务应用。配套配置配置域名和 HTTPS 访问入口，挂载持久化存储，管理业务文件。运维排障在运行期间持续监控状态、查看日志，处理故障并完成日常运维工作。该平台设计初衷是串联部署、接入、维护、排障的全流程，为用户提供一套完整的云原生管理解决方案。

这 YAML 文件怎么又写错了？”,“kubectl logs 看了半天，日志在哪？”,“域名、存储、监控……能不能在同一个地方搞定？” 这是不是每个K8s运维和开发人员每天的真实写照？ Kubernetes 的强大毋庸置疑，但它的复杂性和陡峭的学习曲线，也成了无数开发者迈向云原生路上的“拦路虎”。面对满屏的命令行和分散的管理工具，你是不是也渴望一个能“一统江湖”的利器？ 今天，我们就来深度评测一款专为解决这一痛点而生的产品——微擎面板 W7Panel。它不是一个简单的“花架子”，而是一个真正能让你把K8s运维效率“拉满”的全生命周期管理平台。 一、微擎面板是什么？一张图对比传统面板简单来说，微擎面板（W7Panel）就是Kubernetes的“可视化司令部”。它不替代K8s，而是将K8s底层复杂的命令行操作，转化为直观、易用的图形化界面。 我们用一个表格，看看它和传统服务器面板的天壤之别：维度传统服务器面板微擎面板 W7Panel管理对象单台服务器整个K8s集群核心场景网站、数据库、FTP分布式应用、微服务、云原生操作方式点击管理单个服务可视化编排整个应用生命周期目标用户站长、个人开发者研发团队、运维工程师、平台团队划重点： 微擎面板不是让你“一键搭建WordPress”，而是让你“一键部署、管理、运维一个由多个微服务组成的、高可用的云原生应用”。 二、功能全覆盖：从“能用”到“好用”的质变微擎面板将原本分散在 kubectl、Dashboard、Ingress Controller、StorageClass 等工具中的能力，全部整合到一个统一界面，实现了真正的“一站式”： 集群状态，一目了然告别 kubectl top nodes 和 kubectl get pods -A。现在，集群节点、命名空间、Pod的运行状态、资源消耗（CPU/内存）以可视化图表呈现，异常节点和Pod一眼就能识别，点击即可进行扩缩容、重启等操作。  应用部署，像逛应用商店内置丰富的应用商店，从数据库到中间件，一键部署。独创的“标准化应用交付单元”，让团队可以轻松打包自己的业务应用，实现“一次打包，到处运行”，版本迭代和灰度发布也变得异常简单。强大的 MicroApp 拓展机制，允许你或社区开发各种插件，无缝融入控制台，实现无限功能扩展。  网络配置，傻瓜式操作统一管理域名、证书、路由。配置HTTPS？只需在面板中输入域名，选择证书，系统自动完成Ingress配置和SSL证书绑定。内置私有DNS，解决了集群内部服务发现和调试的痛点，再也不用记住复杂的Service名称。  文件管理，本地体验集成了完整的 WebDAV 文件系统。你可以像管理本地电脑一样，在线编辑、上传、下载、压缩、解压Pod内的文件，甚至可以直接在面板上管理集群的本地镜像仓库，提交、导入、删除镜像，无需登录服务器。  日志事件，快速排障聚合了所有Pod的日志和集群事件。服务报错、资源异常，不用再 SSH 到节点上敲 journalctl 或 kubectl describe，所有信息都在一个界面里，按时间线清晰排列，排障效率提升数倍。 三、用了微擎面板，你能获得什么？告别“命令恐惧”零基础也能玩转K8s，让团队成员从繁琐的命令行中解放出来，专注于业务本身。告别“多工具切换”一个面板搞定所有，大幅减少上下文切换带来的时间浪费和认知负荷。应用交付“快人一步”从开发到测试再到生产，标准化应用包让交付链路更顺畅，迭代周期更短。数据安全“尽在掌握”支持私有化部署，所有数据留在你的环境内，满足企业最严苛的数据合规和隐私保护要求。故障处理“快、准、稳”集中式的监控、日志和事件，让问题定位时间从“小时级”缩短到“分钟级”。 四、这些人，现在就应该试试 个人开发者想用K8s搭建个人项目，但不想在运维上耗费过多精力，专注代码本身。 中小研发团队没有专职运维，开发人员需要一套简单、直观的工具来自助发布和管理应用。️ 运维/平台团队需要为整个研发团队提供一个低门槛、标准化的集群操作界面，解放自己，赋能他人。 政企/内网用户对数据安全和自主可控有极高要求，需要一个不依赖任何公有云、完全本地化的云原生管理平台。 五、新手入门，一分钟上手接入集群在W7Panel中输入你的K8s集群连接信息，秒级接入。部署应用从应用商店一键安装或上传你的标准化应用包。配置网络为你的应用绑定域名，配置SSL证书，开启对外服务。管理文件通过WebDAV连接到Pod，编辑配置文件或上传静态资源。日常运维查看监控仪表盘，浏览日志，轻松应对各种突发状况。 写在最后Kubernetes 是云原生时代的“操作系统”，而微擎面板 W7Panel 就是那个让所有人都能轻松驾驭这个操作系统的“图形化桌面”。它弥补了K8s在易用性上的短板，让云原生的强大能力真正服务于每一个人。 如果你正在使用K8s，并且厌倦了繁琐的命令行和多工具切换的混乱，不妨试试微擎面板。它或许就是你一直在寻找的，那把开启云原生高效运维之门的钥匙。

做云原生开发、集群运维的朋友，一定都有同款痛苦：部署应用要写一堆 YAML，排错得敲满屏 kubectl 命令；管理域名、文件、存储要切换 N 个工具；传统服务器面板只适配单机，完全 hold 不住 K8s 集群…… 今天给大家安利一款专为 Kubernetes 打造的全生命周期管理平台 ——微擎面板 W7Panel，一套面板搞定应用部署、域名配置、文件管理、故障排查全流程，新手也能轻松玩转云原生！ 一、微擎面板到底是什么？一句话讲明白微擎面板（W7Panel）是面向 Kubernetes 场景的可视化云原生管理控制台。它不是用来替代 K8s，而是把原本分散在命令行、配置文件、各类工具里的运维操作，全部收拢到同一个可视化界面。 很多人会把它和传统服务器面板弄混，两者差别巨大：✅ 传统面板：主打单机服务器，适合网站、本地数据库管理✅ 微擎面板：底座是 K8s 集群，面向分布式云原生应用，覆盖应用从上线到长期维护完整链路 划重点：它不是简易一键安装工具，也不是脱离 K8s 的单机面板，核心定位是应用全生命周期运维中枢。 二、一个面板搞定所有运维工作，功能全覆盖不用来回切换工具，集群、应用、网络、文件、存储、日志，全部集中管理：🔹 集群资源可视化监控实时查看集群、节点、容器运行状态，CPU / 内存 / 资源占用一目了然，节点运维操作直接在面板完成。 🔹 应用快速部署分发内置应用商店，各类常用应用一键安装；独创标准化应用交付单元，方便打包、分发、迭代升级；基于 MicroApp 拓展机制，各类功能无缝融入控制台。🔹 域名 & HTTPS 网络一站式配置统一管理域名路由，自动配置 SSL 证书；内置私有 DNS，兼顾集群内部服务互通与网络诊断，内外网访问一键搞定。 🔹 WebDAV 在线文件 + 本地镜像管理自带完整文件管理功能：在线编辑、上传下载、压缩解压、调整权限；支持集群本地镜像导入、提交、整理，不用登录服务器操作镜像。 🔹 日志事件一体化故障排查聚合全部容器日志、集群运行事件，服务报错、资源异常直接界面查看，不用远程登录节点敲命令，排障速度翻倍。 专属特色，辨识度拉满对比普通 K8s 可视化工具，微擎面板独有优势：标准化应用交付、集群私有 DNS、完整 WebDAV 文件系统、深度节点运维、灵活 MicroApp 功能拓展。 三、用上微擎面板，你能收获什么？1. 大幅降低 K8s 使用门槛不用死记硬背命令，不用手写复杂 YAML，可视化点击操作，零基础开发者也能上手集群。2. 告别多工具来回切换部署、域名、文件、日志、存储全部统一入口，省去切换多款软件的时间，日常运维效率大幅提升。3. 应用上线迭代更简单应用商店 + 标准化应用包，个人项目、企业业务快速部署、一键更新，缩短业务落地周期。4. 私有化部署，数据完全自主可控支持本地私有化部署，集群、业务数据全部留存自有环境，满足企业内网、数据合规、隐私管控需求。5. 线上故障快速定位止损监控、日志、资源状态集中展示，异常问题一眼定位，减少线上故障处理耗时。 四、这些人群，一定要试试微擎面板👨 个人独立开发者自己搭建后端、网站、AI 项目，想用 K8s 实现高可用，但不想花费大量时间钻研底层运维，快速部署管理项目。 👥 中小研发团队缺少专职运维，研发人员需要自助发布应用、配置域名、排查问题，统一管理所有业务，节省运维人力成本。 🛠 运维 / 平台团队需要给研发、测试提供低门槛集群操作界面，屏蔽底层复杂 K8s 细节，减少重复琐碎的运维工作。 🏢 私有化部署场景政企内部业务、涉密项目、内网服务，不依赖第三方公有云，需要一套自主可控的云原生管理平台。 五、新手入门标准操作链路，一看就会初次使用不用迷茫，跟着这条完整流程走，覆盖业务全生命周期：接入集群，查看节点、资源整体运行状态通过应用商店 / 镜像部署业务应用配置域名、SSL 证书，开通对外访问入口WebDAV 管理业务文件，配置持久化存储日常查看监控日志，在线处理故障、迭代更新应用整套流程闭环，全程无需切换其他工具，真正实现一站式云原生运维。 写在最后Kubernetes 功能强大，但复杂的命令和配置一直劝退很多使用者；传统单机面板又无法适配分布式集群场景。微擎面板 W7Panel 完美填补了这个缺口，以可视化操作简化底层复杂能力，打通应用交付、接入、维护、排障全链路。不管是个人开发者、中小企业，还是专业运维团队，只要你正在使用 K8s、想要摆脱繁琐命令行操作，微擎面板都是高性价比的一站式云原生管理方案，让云原生运维变得简单高效！ 项目地址：http://github.com/w7panel/w7panel

微擎面板生态面向国内开发者免费开放 Docker 镜像加速源，配套服务器资源由微擎 IDC 提供，底层能力依托微擎镜像缓存开源项目实现。 仓库地址：https://github.com/w7panel/w7panel-registrycache  镜像源映射对照表 原始镜像地址微擎加速镜像地址docker.ioregistry.cdn.w7.ccdhi.iodhi.registry.cdn.w7.ccgcr.iogcr.registry.cdn.w7.ccghcr.ioghcr.registry.cdn.w7.ccregistry.k8s.iok8s.registry.cdn.w7.ccmcr.microsoft.commcr.registry.cdn.w7.ccnvcr.ionvcr.registry.cdn.w7.ccquay.ioquay.registry.cdn.w7.cc使用示例 拉取 docker.io 镜像示例： #原命令docker pull nginx:latest#替换加速源后docker pull registry.cdn.w7.cc/nginx:latest其余仓库镜像替换规则同理，仅需将域名替换为对应加速域名即可正常拉取。

LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获20k+申请，发起2200+课题，毕业超千名实习生，发放超过390万美金报酬。2026年秋季(Term 3）申请时间为8月3日 – 8月18日（23:59 UTC)，远程实习将从 9月 7 日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3100美金，约合￥20916人民币）。 今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于即日起前点击阅读全文，或到官方平台申请：https://mentorship.lfx.linuxfoundation.org/  KubeEdge社区介绍 KubeEdge 社区已经连续6年参与 LFX Mentorship 计划，过去已为学员提供30+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8.2k+Stars和2.3k+Fork，吸引了全球来自35+国家的120+贡献组织及1800+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。 社区地址：🌍https://github.com/kubeedge/kubeedge在 LFX Mentorship 2026秋季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象  秋季计划申请者需在2026年8月18日前在 LFX 官网[1]完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定，对 Mentee 的申请者有以下要求[2]:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026年秋季活动流程如下：Mentee 注册与项目申请：8月3日-8月18日（00:00 UTC/23:59 UTC)申请者审核期： 8月19日-9月1日（11:00 AM PDT/18:00 UTC)申请者入选通知：9月2日-9月4日实习正式开始：9月7日中期考核：10月20日（11:00 AM PDT/18:00 UTC)首次津贴支付：10月21日结项考核、实习报告提交：11月24日（11:00 AM PDT/18:00 UTC)最终津贴支付批准：11月25日本期结束最终日期：11月27日申请者需要在8月18日前完成 Mentee 注册和项目申请，流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply 实习申请结果预计将在9月2日—9月4日通知到申请人。主线开发日期为2026年9月7日 – 11月24日，全程线上协作，无需线下参与。结项需要在2026年11月24日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  KubeEdge课题   最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍Modernize KubeEdge Controllers and Admission Webhooks课题描述：KubeEdge 当前的云端 Controller 与 Admission Webhook 使用了不同的实现和部署方式。Controller Manager 已经采用 controller-runtime Manager 和 Reconcile 模型，而 Admission 仍然作为独立命令、HTTP Server、Webhook 注册流程、Deployment 和 Service 运行。当前 Kubebuilder 和 controller-runtime 推荐将 Reconcile Controller 与 Admission Webhook Server 运行在同一个 Controller Manager 进程中，从而统一 Kubernetes Client、Scheme、Cache、生命周期、健康检查、Leader Election、Metrics、日志和证书管理。本项目旨在升级 KubeEdge 的 Go 和 Kubebuilder 相关技术栈，将 controller-runtime、controller-tools 与 KubeEdge 使用的 Kubernetes 版本对齐，把现有 Admission Handler 迁移到 controller-runtime Webhook 框架，并最终将 Controller 与 Admission 能力合并到统一的 Controller Manager 组件中。项目同时将引入自动化依赖漏洞检查和工具链版本管理，增强 KubeEdge 的依赖安全基线。预计输出件：梳理 KubeEdge 当前使用的 Go、Kubernetes、controller-runtime、controller-tools、代码生成、Controller Manager 和 Admission Webhook 实现。根据 KubeEdge 使用的 Kubernetes 版本确定合适的 Go、controller-runtime、controller-tools 和 Kubebuilder 兼容版本。提交设计提案，说明统一 Controller Manager 架构、迁移步骤、兼容策略、证书管理、异常处理和回退方案。   统一升级 go.mod、Builder 镜像、Dockerfile、Makefile、构建脚本、GitHub Actions 和贡献者文档中的 Go 版本。   升级 controller-runtime 及相关 Controller 开发依赖，并确保与 KubeEdge Kubernetes 依赖兼容。   根据需要，将现有 Controller 改造为当前 controller-runtime 推荐的 Reconcile 和 Manager 模式。   将 Admission Webhook Server 集成到 KubeEdge Controller Manager 进程中。将现有 Validating 和 Mutating Admission Handler 迁移为 controller-runtime Admission Handler，或者适用情况下使用 Kubebuilder 风格的 Validator 和 Defaulter。   通过同一个 controller-runtime Manager 统一注册 Controller 和 Webhook，并共享 Scheme、Client、Cache、Logger、健康检查和生命周期。   使用 controller-tools Marker 和声明式 Manifest 替代当前手工创建 WebhookConfiguration 的方式。   在完成功能一致性验证后，合并或移除独立 Admission Command、Deployment、Service、配置、RBAC 和证书处理逻辑。保持现有 Device、DeviceModel、Rule、RuleEndpoint、NodeUpgradeJob 和离线迁移等 Admission 能力。   为统一组件补充 Leader Election、Health、Readiness、Metrics、Graceful Shutdown 和 Webhook 就绪检查。   升级并统一  controller-gen、setup-envtes 和相关代码生成工具。  重新生成并验证 CRD、RBAC、WebhookConfiguration 和 API 生成代码。 为 Reconcile Controller 和 Admission Webhook 增加单元测试及基于 envtest 的集成测试。增加端到端测试，验证组件合并前后的 Controller 和 Admission 行为一致。 接入 govulncheck 等 Go 漏洞检查，并记录漏洞处理规则。   验证 AMD64 和 ARM64 构建链路，确保生成文件和 Vendor 依赖一致。   更新安装、升级、开发和故障排查文档。   发布技术博客或贡献者指南，介绍升级后的 KubeEdge Controller 架构。前置技能：Go; Kubernetes; KubeEdge; Kubebuilder; controller-runtime; controller-tools; Admission Webhook; CRD; GitHub Actions; Docker; Linux课题导师：Wei Hu (@WillardHu)wei.hu@daocloud.ioChuanhao Jin  (@chuanhao jin)jch995321@gmail.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/104f564b-8f94-436b-b52e-8915ff290ef9Github Issue：cid:link_1  ▍Enable RuntimeClass and Confidential Containers on KubeEdge课题描述： Kubernetes RuntimeClass 允许工作负载选择指定的容器运行时处理器，包括标准 OCI 运行时、Kata Containers 和机密容器运行时。目前 KubeEdge 尚未为运行在边缘节点上的工作负载提供完整的 RuntimeClass 支持，因此依赖替代运行时或更强运行时隔离能力的工作负载无法正常部署到边缘节点。本项目旨在为 KubeEdge 实现端到端 RuntimeClass 支持，并结合 Kata Containers 和 Confidential Containers 生态进行验证。学员需要研究 RuntimeClass 资源如何在 KubeEdge 云边组件之间同步、缓存和使用，并确保 Edged 能够正确解析 spec.runtimeClassName，选择对应的运行时处理器。第一阶段聚焦于使用当前支持的 KubeEdge 与 Kata Containers 环境完成 RuntimeClass 验证，识别具体缺失的集成链路。基本 RuntimeClass 流程完成后，可以在具备测试环境和社区支持的情况下，进一步使用 Intel TDX 等技术验证机密工作负载，包括远程证明以及受保护的密钥或 Secret 下发。预计输出件：研究上游 Kubernetes RuntimeClass 工作流程，识别 KubeEdge 在资源同步和运行时选择方面缺失的能力。使用可复现的 KubeEdge 和 Kata Containers 环境验证当前行为。提交设计提案，说明 RuntimeClass 同步、边缘侧缓存、运行时处理器解析、兼容性和异常处理方案。完成所需代码改造，使 RuntimeClass 资源可以从 Kubernetes 控制面同步到 KubeEdge 边缘节点。支持边缘工作负载通过 spec.runtimeClassName 指定运行时。确保 Edged 能够正确选择对应的 CRI Runtime Handler。至少使用一种替代运行时完成验证，例如 Kata Containers。正确处理 RuntimeClass 不存在、配置无效或运行时处理器不可用等情况。增加单元测试和端到端测试，覆盖 RuntimeClass 同步、运行时选择、EdgeCore 重启和云边重新连接。提供可复现的部署清单、配置文件、验证脚本、架构文档和故障排查说明。发布技术博客或用户指南，介绍如何在 KubeEdge 中运行基于 RuntimeClass 的安全工作负载。可选：在 Intel TDX 或其他受支持的机密计算平台上，使用 Confidential Containers Runtime 验证机密工作负载。可选：在 RuntimeClass 和 Confidential Containers 基础集成完成后，演示一个边缘机密 AI 推理场景。前置技能：Go; Kubernetes; KubeEdge; RuntimeClass; Containerd; Container Runtime Interface; Kata Containers; Confidential Containers; Linux; Confidential Computing 课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/ef5b6ae6-99be-42e0-aeae-897684b0e9c8Github Issue：cid:link_2 ▍Comprehensive Example Restoration for KubeEdge Ianvs: Phase IV (2026 Term 3)课题描述： Ianvs 充当着 KubeEdge SIG AI 分布式基准测试工具套件的角色。随着越来越多的贡献者参与其中，KubeEdge Ianvs 目前已拥有多达 30 个样例，且这数字仍在不断增长。然而由于AI类依赖包的快速演进和验证机制的复杂性，KubeEdge Ianvs 面临着日益增多的可用性问题。具体地，随着 Python 版本、第三方库及 Ianvs 功能快速迭代，部分历史样例可能变得过时。这也导致用户报告的 Issue 激增，亟需避免被未稳定贡献代码误损原有功能、修复与实际能力不再匹配的文档。若不进行系统干预，对边缘 AI 开发者、尤其是新入行者而言这些样例可能变得难以使用。因此，我们尝试通过全面的样例修复工作来强化 Ianvs 可用性。 预计输出件：诊断和修复多个样例中的错误，包括依赖关系清单、许可证扫描和运行时配置。文档更新，包括修订带有可复现步骤指南的教程，发布以开发人员为重点的常见故障调试演示手册。编写并上传相应的博客到KubeEdge网站。使用GitHub Actions针对多个Python版本、关键的 Ianvs/上游更新来完善CI管道测试示例，并阻止破坏已验证示例的PR。前置技能：Python; Benchmark; KubeEdge-Ianvs; AI/ML 课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comKai-Wei Chou (@ken6078)ken60786213@gmail.com 课题链接：https://mentorship.lfx.linuxfoundation.org/project/0a346d47-1eff-480c-990d-fa8bf6d9e24aGithub Issue：cid:link_3 ▍KubeEdge-Ianvs Simulation Sandbox: Environment-Isolated Execution课题描述：对于大多数分布式人工智能方案开发者而言，构建和部署大规模云边协作系统通常既复杂又繁琐。尽管 KubeEdge-Ianvs 目前提供了一个单节点算法测试器，可以使用测试数据集评估准确率指标，但对于大规模节点而言，在实际环境中测量带宽、计算能力和峰值内存等系统级指标却极其困难且成本高昂。此外，在单个共享的 Python 进程中执行所有测试用例很容易引发依赖冲突、路径污染以及致命的内存溢出 (OOM) 崩溃，尤其是在运行 LLM、VLA 和基础模型等高负载模型以及轻量级示例时。为了应对这些挑战，本项目旨在引入一种工业级分布式协作系统仿真方案，该方案采用单机上的工作节点嵌套模式，提供低成本、可扩展的测试能力、强大的环境隔离以及精确的系统级指标分析。预计输出件：恢复仿真核心功能：鉴于之前的提案，恢复并扩展 Ianvs 2022 仿真提案（Ianvs PR #35）及其实现（Ianvs PR #39，已发现 5 个以上缺陷），构建仿真控制器，将每个测试用例隔离在独立的瞬态运行时环境中，并强制执行系统级资源配额和边界控制机制，以限制边缘节点资源（CPU 和内存），从而避免依赖冲突和内存溢出 (OOM) 风险。关键组件包括：仿真控制器环境管理员：在测试用例控制器中引入仿真控制器，以在单台机器上提供工作节点嵌套的工作节点系统，模拟多节点系统。实现仿真环境管理员，以解析系统配置、检查主机环境要求（例如，内存 > 4GB），并自动构建、部署、关闭和删除仿真环境。仿真控制器仿真作业管理器：开发关键的仿真作业管理器，负责算法镜像构建（例如 Docker）、YAML 生成、作业部署/删除以及使用工作进程监控仿真结果列表。同时，部署一个使用临时运行时环境和系统资源配额（CPU 和内存）的隔离执行层，以彻底防止依赖冲突和内存溢出崩溃。使用多维指标验证集群：使用 kind + edgecore + Sedna 一体化脚本完成 KubeEdge 原生集群模拟验证。多维指标集成：将底层系统指标（CPU 利用率、峰值内存、实际运行时间）与上层算法指标对齐，并在现有的 StoryManager 排行榜中统一呈现，从而实现分布式 AI 的端到端综合性能评估。前置技能：KubeEdge; Kubernetes; Docker; Linux Kernel mechanisms; Go; Python; Benchmark; AI/ML; KubeEdge-Sedna; KubeEdge-Ianvs课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：https://mentorship.lfx.linuxfoundation.org/project/0aca7087-4985-4d22-a7c2-b8d5845e962bGithub Issue：cid:link_4如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。今年秋季，KubeEdge 社区期待在 LFX Mentorship 见到您！Reference：[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

由 Linux Foundation 组织的 LFX Mentorship 计划[1]，从 2019 年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。该项目往年已获 2w+ 申请，累计课题量 2200+，毕业实习生 1500+，发放超过 390 万美金报酬。LFX Mentorship 2026 秋季 ( Term 3 ）申请时间为8月3日 – 8月18日（23:59 UTC )，正式研发工作将从 9 月 7 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区认可的同时，完成工作还能获取报酬 (位于中国的开发者报酬为3000美金，约合20000人民币）。Volcano社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者即日起可前往官网申请（在校/在职符合条件均可）:🔍 https://mentorship.lfx.linuxfoundation.org/   Volcano 社区介绍  Volcano （cid:link_7）是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.9k+ Star 和 2.4K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。在大模型/AI 推理领域，Volcano Kthena 依托社区在集群拓扑感知与大规模算力调度的优势，结合 KV Cache 感知路由与 Prefill/Decode 分离等高级特性，通过算力与时延的极限优化，显著提升 GPU/NPU 资源利用率与系统吞吐，从而高效解决生产环境中 LLM 大规模部署与服务的核心挑战，助力用户释放模型推理与服务的算力潜能。期待与你在LFX Mentorship 2026 秋季计划协作开拓AI大数据、LLM大模型推理等场景应用的更多可能。  面 向 对 象 本期计划申请者需2026年8月18日前在LFX官网[1]完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下参与开源社区共建。依据官方规定，对Mentee申请者有以下要求[2]:在参加该计划时您至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026 Term3（秋季） 申请及实习流程如下：Mentee注册与项目申请：8月3日-8月18日（00:00 UTC/23:59 UTC)申请者审核期： 8月19日-9月1日（18:00 UTC)申请者入选通知：9月2日-9月4日实习正式开始：9月7日中期考核：10月20日（18:00 UTC)首次津贴支付：10月21日结项评估：11月24日（18:00 UTC)最终津贴支付批准：11月25日本期结束最终日期：11月27日参与者如有意向如何申请？流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply主线开发日期为2026年9月7日-11月24日，全程线上协作，无需线下参与。结项需要在2026年11月24日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  欢迎申报 Volcano 课题  今年秋季，Volcano 社区带来以下 4 个课题，欢迎各位申请者加入：▍Volcano 通用 xPU 拓扑感知调度课题描述：当前，Volcano 主要根据 Node 上 xPU 资源的总量进行调度，但对 GPU、NPU 等加速设备之间的物理互联关系缺少感知。对于通信密集型 AI 作业，仅仅满足设备数量并不意味着能够获得合适的通信拓扑。例如，一台 16 卡 NPU 服务器可能包含两个相互独立的 8 卡 HCCS 互联域。如果一个互联域空闲 6 张卡，另一个空闲 2 张卡，那么 Node 上虽然共有 8 张空闲 NPU，却无法满足“8 张卡位于同一互联域”的调度要求。NVLink、NVSwitch 以及其他 xPU 高速互联也存在类似问题。多机训练场景还需要区分两类拓扑：普通多节点集群中，NVLink、NVSwitch 或 HCCS 仅存在于单个 Node 内，节点之间通过 InfiniBand 或 RoCE 通信；GB200 NVL72 等系统中，多个 Kubernetes Node 上的 GPU 通过机架级 NVLink 背板组成同一个跨节点高速互联域。本课题将在 Volcano 中实现通用的 xPU 拓扑感知调度能力。调度器需要在 Pod 绑定之前感知设备拓扑及其可用状态，根据作业需求选择合适的 HyperNode 或跨节点互联域、Node、节点内设备互联域以及具体设备。拓扑信息的来源与调度逻辑需要解耦。调度器通过统一接口消费标准化的拓扑信息，底层可以来自 Node Annotation、拓扑 CRD、Device Plugin 配套组件、厂商接口或 DRA ResourceSlice。课题前期可以使用 KWOK 和模拟拓扑数据完成开发及验证，不依赖真实的 NVL72 等硬件环境。预期产出：设计并实现厂商无关的 xPU 拓扑模型及拓扑信息接入接口，统一表达节点内设备互联域、跨节点高速互联域、设备状态以及与 HyperNode 的关系。实现可选的 xPU 拓扑感知调度插件，根据互联域的实际可用设备进行过滤和打分，并支持具体设备选择、Gang 级资源预留及失败回滚。将设备拓扑及其空闲、已分配、已预留和异常状态集成到 Volcano 现有调度缓存中，通过索引和增量更新控制调度开销。基于 KWOK 构建功能和性能测试，覆盖单节点多互联域、无跨节点 xPU 背板的多机作业，以及 NVL72 风格的跨节点互联场景。输出单元测试、集成或 E2E 测试、性能测试报告、使用文档及拓扑接入指南。若条件允许，可进一步对接模拟或真实 Device Plugin，但不作为课题验收的硬性要求。前置技能：熟练使用 Go，具备实际的 Kubernetes 开发经验熟悉 Kubernetes 调度器、控制器或资源管理机制具备 GPU、NPU 或其他 xPU 的使用和资源管理经验了解分布式 AI 作业、Gang 调度或设备拓扑者优先了解 Volcano、Kubernetes Device Plugin、DRA、NVLink、NVSwitch、HCCS 等技术者优先具备测试、性能分析或调度算法开发经验者优先课题导师：Zicong Chen（ @JesseStutler ）jessestutler97@gmail.comYang Wang（ @wangyang0616 ）wangyang8216@gmail.comJoão Azevedo（ @devzizu ）jazevedo960@gmail.comHajnal Mate（ @hajnalmt ）hajnalmt@gmail.com原始 Issue：cid:link_2课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/087b7172-482e-4ae8-af7a-a27f56fbe09f ▍支持 Pod 原地滚动更新功能课题描述：目前，Kthena 的 RollingUpdate 策略主要通过删除旧资源、创建新资源的方式更新工作负载。这种方式适用于任意 Pod 模板变更，但当更新内容仅为容器image时，会带来不必要的资源开销。Kubernetes 支持直接修改现有 Pod 中容器的image。更新后，Kubelet 会重新启动受影响的容器，同时保留原有 Pod 对象。本项目计划为 ModelServing 增加明确的原地滚动更新（Inplace Rolling Update）策略，并完善其安全性、服务可用性、异常恢复及状态展示等相关语义，从而降低镜像更新成本，提升模型服务升级效率。预期产出：完成原地滚动更新功能的设计提案，并在 Kthena 社区会议中进行分享；完成相关功能的代码实现；补充对应的单元测试和端到端测试；编写并完善用户使用指南。 Device Plugin，但不作为课题验收的硬性要求。前置技能：Go 语言开发；熟悉 Kubernetes 基础概念及工作负载更新机制；对云原生、容器编排或模型服务方向感兴趣；具备良好的开源协作与沟通能力。课题导师：ZhenCheng Lee（ @LiZhenCheng9527 ）lizhencheng6@huawei.comJinYu Zhou（ @FAUST-BENCHOU ）2319109590@qq.com原始 Issue：cid:link_3课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/6c797658-daa1-40d6-b24c-3bf496e75755 ▍Volcano Dashboard：Kthena 资源管理与运维可观测性课题描述：Volcano Dashboard 已支持 Job、Queue、Pod 和 PodGroup 等资源的查看与管理，但目前尚未覆盖 Volcano 推理子项目 Kthena 的相关资源。用户在管理和排查 Kthena 工作负载时，仍然需要依赖 kubectl 或其他工具，难以在统一界面中查看服务状态、路由配置、发布进度以及相关资源之间的关系。本课题将在 Volcano Dashboard 中增加对 Kthena 的支持，重点覆盖 ModelServing、ModelBooster、ModelRoute 和 ModelServer 等核心资源，并结合实际运维需求完善资源管理、状态展示和问题排查能力。除了基本的资源列表和详情页面，Dashboard 还需要清晰展示资源 Conditions、实例状态、发布进度、路由关系，以及 Kthena 资源与 Pod、PodGroup、Queue 等底层资源之间的关联。用户可以通过统一界面了解 Kthena 工作负载的整体运行情况，并快速定位服务异常、发布失败或路由配置问题。预期产出：在 Volcano Dashboard 中支持 ModelServing、ModelBooster、ModelRoute 和 ModelServer 等主要 Kthena 资源，提供与现有 Dashboard 风格一致的列表、详情和必要的管理操作。展示 Kthena 资源的 Conditions、实例状态、发布进度和路由信息，并支持在 Kthena 资源与相关 Pod、PodGroup、Queue 等对象之间快速导航。完善 Kthena 的运维和问题排查体验，通过服务健康状态、路由关系和关联资源信息，帮助用户理解工作负载当前状态并定位异常。完成所需的 Kubernetes RBAC 和部署配置调整，并补充自动化测试、用户文档和使用示例。前置技能：熟悉 TypeScript、React 和 Next.js具备 Kubernetes API 和 RBAC 的实际使用经验了解 Kubernetes CRD 及资源状态管理机制具备 Web 管理平台或可观测性功能开发经验了解 Volcano、Kthena 或 AI 推理系统者优先具备自动化测试、技术设计和开源协作经验者优先课题导师：ZhenCheng Lee（ @LiZhenCheng9527 ）lizhencheng6@huawei.comKuldeep Singh（ @de6p ）de6p97@gmail.comZicong Chen（ @JesseStutler ）jessestutler97@gmail.com原始 Issue：cid:link_1课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/b2d21cb7-4380-4375-9384-ca791e652f0d ▍构建支持 KVCache 的调度器端到端（E2E）测试套件课题描述：Kthena Router 已具备较为完善的调度器插件端到端测试框架，目前覆盖 Prefix Cache、Least Request、Least Latency、LoRA Affinity、Random 和 GPU Usage 等调度策略。KVCache 感知调度器插件虽然已经实现，但仍缺少覆盖完整运行链路的端到端测试，包括 Router、模拟后端、Tokenization、ZMQ 事件以及 Redis 等组件之间的协作。本项目计划基于现有 Router 插件测试框架，构建一套可复用的 KVCache 感知调度器 E2E 测试套件。除了验证实际路由行为外，还将提供通用的环境搭建、缓存状态注入、运行状态观测和结果断言工具，为后续新增 KVCache 调度测试场景提供基础设施支持。预期产出：在 test/e2e/router/ 目录下构建可复用的 KVCache 感知 E2E 测试套件。提供 llm-d-sim、ZMQ Bridge、Redis、缓存状态注入、请求生成和路由结果断言等共享 Fixture 与辅助工具。验证完整的数据链路：通过 ZMQ 分发 KV Cache 所有权事件，检查 Redis 中生成的映射关系，并确认 Router 在副本评分和路由决策时能够正确使用这些信息。提供可独立运行该测试套件的专用命令或 Make Target。编写相关文档，帮助贡献者快速添加新的 KVCache 感知测试场景。将测试套件集成至 CI，确保环境能够稳定、确定性地清理，并在测试失败时输出 Router、Redis、ZMQ 和后端状态等有效诊断信息。前置技能：GoKubernetes基于 Kind 的 E2E 测试RedisZMQ可观测性与指标监控分布式系统调试课题导师：Jinyu Zhou（ GitHub:@FAUST-BENCHOU ; LFX ID：@benchou8 ）2319109590@qq.comJprakash（ GitHub:@katara-Jayprakash LFX ID：@lfxkatara1 ）katarajayprakash@icloud.com原始 Issue：cid:link_4 课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/16e5821d-2ae3-4145-a729-1b0c755b613b  更多Volcano课题，请访问LFX Mentorship官网；对课题有任何问题，欢迎直接向课题导师发送邮件或在GitHub仓库提交Issue提问。附：相关指引链接[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_5[6] Volcano/Kthena GitHub: cid:link_6关注容器魔方，获取更多前沿资讯

导读：将一张昇腾 NPU 按算力和显存进行细粒度切分，让空闲算力在多个模型之间弹性共享，空闲时充分利用，竞争时各得其所。本文介绍华为云云容器引擎 CCE 如何通过 FlexNPU 实现 NPU 算力共享，覆盖核心架构、调度策略、隔离机制、共享效果验证及高校教学落地实践。 ▍一、为什么需要 NPU 算力共享整卡分配与模型真实需求不匹配Kubernetes 中传统 NPU 资源通常按整卡申请。一个模型即使仅需整卡 20%～30% 的算力，也必须独占一张物理卡。两张卡均未跑满，但剩余算力难以分配给其他 Pod。对于小参数模型、开发调试、低并发在线服务及教学实验，这种资源浪费尤为突出。简单共享难以避免相互干扰若直接让多个进程共享同一张 NPU 而缺乏资源控制，当某一模型请求突增时，将占用更多执行资源，导致同卡其他模型受到干扰。此类"邻居干扰"使无约束共享方案难以满足多业务共存的诉求。Kubernetes 需要理解算力与显存传统 Device Plugin 仅告知调度器"该节点有 8 张 NPU"。在算力共享场景中，调度器还需掌握：每张卡剩余多少可保障算力每张卡还有多少可用显存当前已创建多少共享实例新实例应放置于哪张物理卡应优先集中放置还是分散放置因此，FlexNPU 不仅是节点侧的设备代理，更需要与 Kubernetes 及 Volcano 调度体系深度协同。 ▍二、CCE FlexNPU 核心方案FlexNPU 面向昇腾硬件生态设计，采用 Client-Server 架构将应用发起的 NPU API 调用与物理设备执行解耦。业务容器不再直接持有 /dev/davinciX 等物理设备，而是通过容器内的 FlexNPU Client 发起调用，由宿主机侧的 aclserver 访问真实 NPU。核心组件包括 flexnpu-device-plugin、flexnpu-runtime、flexnpu-daemon 和容器侧 flexnpu-client，各组件通过共享内存或轻量网络链路完成请求转发。▲ CCE FlexNPU 整体架构 整体调用流程如下：当前，FlexNPU 支持将一张昇腾 910B 细粒度切分为多个 NPU 共享实例，关键规格如下：指标规格算力最小切分比例1%，步长 1%显存最小分配单位128 MiB单卡最大实例数32单机最大实例数128FlexNPU 对算力并非简单的静态硬切分，而是保障下限、弹性共享——设备存在空闲算力时，业务可使用超过申请值的算力；多个业务同时繁忙时，保障每个实例获得约定的算力份额，避免过载业务影响同卡其他模型。1. Device Plugin：将 NPU 变为可声明资源flexnpu-device-plugin 负责将算力与显存抽象为两种 Kubernetes 扩展资源：资源名称含义volcano.sh/flexnpu-core.percentage算力保障比例（%）volcano.sh/flexnpu-memory.128mi显存容量，以 128 MiB 为单位资源申请示例：resources: requests: volcano.sh/flexnpu-core.percentage: "50" volcano.sh/flexnpu-memory.128mi: "300" limits: volcano.sh/flexnpu-core.percentage: "50" volcano.sh/flexnpu-memory.128mi: "300"其中 flexnpu-core.percentage: "50" 表示申请 50% 的算力保障；flexnpu-memory.128mi: "300" 表示申请 300 × 128 MiB = 37.5 GiB 显存。用户由此可根据模型真实需求精确申请资源，而非只能声明"一张 NPU"。2. Volcano 调度：算力、显存与实例数的多维约束CCE Volcano 调度器通过 flexnpuaffinity 插件参与 FlexNPU 资源放置，配置示例如下： - name: flexnpuaffinity arguments: scheduleMode: binpackCCE Volcano 插件提供 binpack 和 spread 两种调度方式：调度方式策略适用场景binpack优先填充已使用的物理卡，保留完整物理卡提升资源利用率spread将负载分散到不同物理卡或节点均衡负载、降低单卡压力以 binpack 为例，调度逻辑为：调度过程中，插件需同时校验以下约束：约束条件说明Pod 申请的算力保障 ≤ 物理卡剩余可分配算力算力维度Pod 申请的显存 ≤ 物理卡剩余显存显存维度单卡实例数 < 32实例槽位单机实例总数 < 128实例槽位设备型号 = Ascend 910B硬件兼容这是一种算力、显存与实例槽位共同参与的多维资源调度，而非简单统计物理卡数量。3. Runtime：容器启动阶段透明注入flexnpu-runtime 工作于 OCI 容器创建链路中。Pod 启动时，它将共享实例所需的运行环境注入业务容器：FlexNPU Client 动态库client.conf 等通信配置共享内存目录共享设备相关配置业务容器不直接挂载真实物理 NPU，真正持有并访问物理设备的是宿主机侧的 aclserver。此举将物理设备控制权保留在宿主机侧，降低业务容器直接操作设备、影响同卡其他实例的风险。4. Client 与 aclserver：API 调用与物理执行解耦FlexNPU Client 以动态链接库形式存在于业务容器内部。当 PyTorch、vLLM 等上层框架调用 aclInit、aclrtMalloc、aclrtMemcpy、aclrtCreateStream 等接口时，请求首先由 FlexNPU Client 接管，Client 将调用类型、参数、虚拟句柄及数据描述传递给宿主机侧的 aclserver，由后者调用真实 Ascend Runtime 完成执行。AI 框架和模型代码无需针对算力共享场景重新开发，通过动态库透明接管底层硬件 API，实现上层应用零侵入。5. 双链路通信降低代理开销FlexNPU 支持两类通信路径：链路类型协议用途TAP 链路TCP/IP实例注册、控制指令、状态交互、轻量参数传递Shared Memory 链路共享内存 (/dev/shm)高频数据交互，Client 与执行端映射同一块共享内存区域相比让大块数据反复经过 Socket 缓冲区，共享内存能够减少内核协议栈处理和进程间数据复制，显著降低代理开销。 ▍三、算力共享的关键：空闲可借，竞争有保FlexNPU 的资源策略并非将一张卡静态切分为若干互不流动的小块。假设同一张 NPU 上部署两个模型：模型 A 申请 25% 算力，模型 B 申请 75% 算力。此处的比例表达的是竞争状态下的算力保障。场景一：仅模型 A 有负载模型 B 当前无任务，卡上存在大量空闲算力。FlexNPU 不会将模型 A 限制在 25%，模型 A 可使用设备上的空闲计算能力，实际使用量最高可达当前可用的整卡算力。因此，较小的资源声明不会令单独运行的模型被限制在少量资源内。场景二：模型 A、B 同时繁忙两个模型均产生大量计算任务时，系统进入资源竞争状态：模型 A：至少获得约定的 25%模型 B：至少获得约定的 75%模型 A 即使持续过载，也无法明显侵占模型 B 的保障份额。这套策略可概括为：空闲可借、竞争归还、保障下限。与固定硬切分相比，避免了实例空闲时资源无法利用的问题；与无约束共享相比，又能在竞争时保护不同业务的算力份额。部署策略空闲资源利用率竞争时算力保障整卡独占低强静态硬切分中强无约束共享高弱FlexNPU 保障型共享高强 ▍四、显存隔离与算力共享的语义差异显存和算力是两种性质不同的资源，需区别对待。显存是容量型资源。 当一个实例申请 32768 MiB 显存时：32768 MiB ÷ 128 MiB = 256Pod 中配置为：volcano.sh/flexnpu-memory.128mi:"256"该额度约束实例可使用的显存容量上限，一个实例的异常显存申请不会侵占其他实例已分配的显存空间。算力是可共享的执行资源。 算力随负载动态流动：状态行为无竞争使用自身保障份额 + 空闲算力有竞争恢复各实例的最低保障因此，FlexNPU 同时实现了：显存容量隔离、算力下限保障、空闲算力弹性复用、同卡业务间算力隔离。 ▍五、效果验证：同卡双模型共享推理实测为验证 FlexNPU 的算力共享与隔离效果，在同一张昇腾 910B 上部署两个模型：模型算力保障显存DeepSeek-R1-Distill-Llama-8B25%32768 MiBQwen2-VL-2B-Instruct75%32768 MiB操作演示：基于华为云CCE进行同卡双模型推理延迟实测 测试方法：持续向 Qwen2-VL-2B-Instruct 发送稳定请求对 DeepSeek-R1-Distill-Llama-8B 逐步增加请求压力同时观察两个模型的端到端推理延迟测试结论：随着 DeepSeek-R1-Distill-Llama-8B 请求压力增加，其自身请求开始排队，推理延迟逐渐上升Qwen2-VL-2B-Instruct 的延迟曲线保持平稳，未随 DeepSeek 的过载同步抬升DeepSeek 的过载未明显侵占 Qwen 已获得的算力保障这表明 FlexNPU 在共享物理资源的同时维持了实例间的保障边界。当 Qwen 当前无负载时，DeepSeek 可使用卡上的空闲算力；当 Qwen 恢复请求后，系统重新保障其 75% 的约定份额。FlexNPU 由此同时实现了：低负载时空闲算力充分流动，高负载时各业务各得其所。 ▍六、高校人工智能教学落地：一台服务器支撑 128 名学生同时在线FlexNPU 已在某高校人工智能教学场景成功落地。在传统整卡模式下，每名学生的实验环境需独占一张 NPU。同时支撑 128 名学生在线开展模型推理、AI 框架实践和课程实验，所需资源为：128 名学生 ÷ 每台 8 张 910B = 16 台 8 卡服务器此方案存在明显问题：单个学生实验通常无法持续跑满整张 910B大量 NPU 在课程等待、代码编辑和低负载推理阶段处于空闲状态实验资源成本高，扩容周期长学生环境之间仍需独立管理和隔离引入 FlexNPU 后，一台配备 8 张 910B 的服务器可切分出最多 128 个 FlexNPU 实例：一名学生 → 一个独立 Pod → 一个 FlexNPU 实例 → 独立算力保障 + 独立显存额度资源规模对比：方案服务器数量可支撑学生数传统整卡独占16 台 × 8 卡 910B128 名FlexNPU 方案1 台 × 8 卡 910B128 名服务器数量降至传统方案的 1/16。教学任务具有典型的间歇性特征：编辑代码 → 等待 → 启动模型 → 短时推理 → 查看结果。并非所有学生都会在同一时刻持续占用设备。FlexNPU 在保障各学生基本算力的同时，将暂时空闲的 NPU 能力提供给正在执行实验的实例，契合教学负载的真实使用规律。同时，每个学生的实验运行于独立 Pod 和共享实例中：显存额度相互隔离算力竞争时有最低保障单个学生任务异常或过载不会无限挤占其他学生的算力教师可通过 Kubernetes 统一创建、回收和管理实验环境对于高校而言，此模式不仅降低了硬件投入，也使课程资源能够按班级规模快速交付，提升实验环境的可管理性和并发能力。 ▍七、典型适用场景场景说明多小模型同卡部署不同模型分别申请所需显存和算力保障，通过 binpack 集中到同一张卡，释放更多完整 NPU在线业务与低优先级任务混部在线服务获得明确算力保障，离线任务使用设备空闲能力；低优先级任务过载时不明显影响在线服务性能AI 开发和测试环境为开发者按需分配小规格共享 NPU，避免调试任务长期占用整卡 ▍八、总结传统整卡分配模式难以适应小模型推理、开发测试、人工智能教学等细粒度资源需求；无约束共享虽可提高利用率，却易产生相互干扰。华为云 CCE FlexNPU 将算力共享、显存隔离与云原生调度统一于同一套体系，其核心价值在于：细粒度切分：算力最小支持 1%，显存以 128 MiB 为单位弹性共享：无竞争时，实例可使用更多空闲算力算力保障：资源竞争时，保障各实例的算力份额显存隔离：防止实例越界占用其他业务的显存云原生调度：通过 Device Plugin 与 Volcano 实现声明式申请与自动放置透明接入：Client-Server 架构，上层模型代码无需修改规模化交付：单卡最多 32 个实例，单机最多 128 个实例在某高校人工智能教学项目中，一台 8 卡 910B 服务器通过 FlexNPU 支撑了 128 名学生同时在线，而传统整卡方案实现相同规模需 16 台 8 卡服务器。FlexNPU 的价值不仅在于将一张物理卡切分为更多实例，更在于：让多个业务共享同一张 NPU 时，空闲算力能够充分流动，资源竞争时又能守住各自的算力份额。 参考资料[1] 华为云 CCE 官方文档: cid:link_0[2] Volcano 调度器项目主页: https://volcano.sh/关注魔方公众号，获取更多前沿资讯

Kthena[1] 是面向高扩展性模型推理的云原生 AI 服务平台。它依托 Volcano[2]在集群拓扑感知与大规模算力调度的优势，结合 KV Cache 感知路由与 Prefill/Decode 分离等高级特性，显著提升 GPU/NPU 资源利用率与系统吞吐，实现算力与时延的极限优化，高效解决生产环境中 LLM 大规模部署与服务的核心挑战，全面释放模型推理与服务的算力潜能。Kthena v1.0.0 现已正式发布。这是 Kthena 在 Kubernetes 原生大模型推理领域迈出的重要一步。本次发布全面聚焦生产就绪能力：提升 Gateway API 路由准确性；为预填充/解码（P/D）分离工作负载提供原生的角色级自动扩缩容，大幅提升资源利用率；提供更安全的角色级滚动更新，保障服务发布零中断；增强Router调度性能；能为多轮对话进行会话加速；通过 Prometheus 指标和示例仪表盘提供更丰富的缓存感知路由可观测性；进一步完善 CLI 使用体验。同时，Kthena v1.0.0 对 autoscaler API 进行了重要整合，正式移除AutoscalingPolicyBinding ，目标配置现在通过 homogeneousTarget、heterogeneousTarget 和 disaggregatedTarget 直接定义在 AutoscalingPolicy 中，带来更纯粹易用的一站式声明配置。  Kthena v1.0.0 版本亮点 ▍核心特性概览AutoscalingPolicy 整合与 P/D 协同式分离扩缩容： 移除 AutoscalingPolicyBinding，将自动扩缩容目标配置统一整合到 AutoscalingPolicy 中；新增的 disaggregatedTarget 支持Perfill/Decode工作负载的角色级协同扩缩容。每个角色均可根据自身指标独立扩缩容，同时通过比例约束，将 P/D 副本比例维持在合理范围内。面向多轮对话的会话加速： Router可以优先处理近期已完成会话的后续请求，从而在高并发对话场景下提高 KV-Cache的命中率。路由调度与可观测性增强： 通过 Pod 级在途请求跟踪、基于 Redis 的多Router状态同步、可配置的 Pod 指标抓取，以及缓存感知 Prometheus 指标，提高调度准确性和运维可观测性。角色级滚动更新可用性控制： 进一步增强 RoleRollingUpdate，现在每个角色都可以通过 maxUnavailable 独立控制升级节奏。Gateway API 与 HTTPRoute 行为修正： Kthena Router现在能够遵循 HTTPRoute 主机名配置，在后端选择和 URL 重写过程中始终使用同一条已匹配的路由规则，并修正 PathPrefix 语义，同时遵循 Gateway 监听器的 allowedRoutes 配置。CLI 与 OpenAI 兼容 API 增强： CLI 提供更丰富的状态信息，并新增对 ModelRoute 和 ModelServer 的支持；Router 新增兼容 OpenAI API 的接口。▍AutoscalingPolicy 整合与 P/D 协同式分离扩缩容Kthena v1.0.0 引入了一套更简洁、更强大的自动扩缩容 API。用户现在可以在单个 AutoscalingPolicy 资源中统一配置扩缩容目标、指标采集方式和扩缩容边界。新的 disaggregatedTarget 模式专为基于Role的工作负载部署提供 P/D 协同自动扩缩容，尤其适用于PD分离部署。Prefill和Decode可以分别依据自身指标作出扩缩容决策，同时由自动扩缩容器应用共享约束，使两侧能够协调扩缩，而不会各自变化并逐渐偏离合理比例。每个角色都可以独立定义副本范围、指标和指标来源；运维人员还可以配置 ratioConstraint，将 P/D 副本比例维持在合理区间内。disaggregatedTarget 配置示例：spec:  disaggregatedTarget:    targetRef:      apiVersion: workload.serving.volcano.sh/v1alpha1      kind: ModelServing      name: vllm-qwen-pd-ms    roles:      prefill:        minReplicas: 1        maxReplicas: 8        metrics:          - name: prefill_waiting_requests            targetValue: "1"        metricSources:          prefill_waiting_requests:            prometheus:              serverURL: http://kube-prometheus-stack-prometheus.test.svc.cluster.local:9090              query: sum(vllm:num_requests_waiting{namespace="autoscale-demo", service="vllm-prefill"})      decode:        minReplicas: 1        maxReplicas: 16        metrics:          - name: decode_gpu_cache_usage            targetValue: "0.75"        metricSources:          decode_gpu_cache_usage:            prometheus:              serverURL: http://kube-prometheus-stack-prometheus.test.svc.cluster.local:9090              query: sum(vllm:gpu_cache_usage_perc{namespace="autoscale-demo", service="vllm-decode"})    ratioConstraint:      numeratorRole: prefill      denominatorRole: decode      minRatio: "0.25"      maxRatio: "1"相关变更：Issue： Proposal of merge autoscalingPolicybingding into autoscalingPolicy  #1172[3]PR：merge autoscalingpolicybinding to autoscalingpolicy #1203[4]Implementation of PD disaggregation auto-scaler #1258[5]贡献者：@LiZhenCheng9527 ▍面向多轮对话工作负载的会话加速Kthena v1.0.0 新增会话加速能力，旨在优化多轮对话、智能体工作流和 RAG 链等后续请求依赖先前响应的场景。在这些工作负载中，后续请求通常会复用较长的公共前缀。如果请求在无关流量之后等待过久，对应后端中的 KV-Cache 可能已被淘汰，进而增加 TTFT。会话加速允许 Router 跟踪近期完成的会话，并在等待队列中优先处理这些会话的后续请求。使用会话加速功能，相较于 llm-d router default 延迟能够降低 20%。该机制与用户公平性调度相互独立，并提供专用的会话加速配置，包括会话请求头选择、等待请求准入上限，以及用于高级缓存命中优化的可选宽限期。此功能旨在提高并发多轮请求下的缓存复用机会，但本身并不进行 KV-Cache 感知调度。若要最大限度发挥 KV-Cache 优势，运维人员还应确保同时使用会话加速和 KV-Cache 感知调度。Helm 配置示例：networking:  kthenaRouter:    sessionBoost:      enabled: true      header: X-Session-ID      maxSessions: 4096      inflightPerPod: 16      gracePeriod: 0s相关变更：Issue：Improve multi-round conversation case #1190[6]PR：session boost queue to optimize multi conversation scenario #1183[7]贡献者：@YaoZengzeng、@hzxuzhonghu、@FAUST-BENCHOU、@LiZhenCheng9527 ▍更智能的路由调度与缓存感知可观测性Router现在可以更好的利用的负载信号进行调度决策。Kthena 能够跟踪每个 Pod 的排队的请求数量，并通过 Redis 在多个Router副本之间同步这些计数器，使 least-request 插件能够依据实时全局负载作出决策，而不再局限于当前Router的本地状态。缓存感知调度的可观测性也得到了显著增强。prefix-cache 和 kvcache-aware 评分插件现在通过Router现有的 /metrics 端点导出 Prometheus 指标，将以往仅记录在 klog 中的信息转化为可查询、带模型标签的时间序列，便于开展压力测试和进行请求调度。为准确衡量缓存效果，Kthena 使用匹配比例直方图取代简单的命中/未命中计数器。kthena_router_prefix_cache_match_ratio 和 kthena_router_kvcache_aware_match_ratio 用于表示提示词中已存在于最佳匹配候选 Pod 上的数据块占比，其中 0 表示完全未命中。运维人员既可以通过 le="0.0" 桶推导缓存命中率，也可以直观了解Cache的实际复用程度。相关变更：Issue：Observability for prefix-cache and kvcache-aware Score Plugins[8]PR：feat(router): add per-pod in-flight request tracking with Redis sync #962[9]Add SGLang tokenizer support for KV-cache-aware scheduling #997[10]router: add observability metrics for prefix-cache and kvcache-aware score plugins #1194[11]feat(router): make pod metrics update interval configurable #1151[12]perf(router): cache parsed prompt to avoid redundant ParsePrompt call #1123[13]fix: parallelize pod metrics scraping loop with bounded concurrency #1255[14]贡献者：@hzxuzhonghu、@blenbot、@kube-gopher、@rajnish-jais、@nabrahma ▍角色级滚动更新可用性控制Kthena v0.4.0 引入了 RoleRollingUpdate，但在角色更新期间，系统会一次性删除 ServingGroup 中某个角色的全部旧副本。只有一个 servingGroup 的时候，会导致服务在角色级发布期间暂时不可用。Kthena v1.0.0 为 RoleRollingUpdate 新增角色级 maxUnavailable 支持。运维人员现在可以使用绝对数量或百分比，为每个角色独立控制更新步长。角色级滚动更新由此具备与 ServingGroup 级更新类似的可用性控制能力。角色级发布配置示例：spec:  rolloutStrategy:    type: RoleRollingUpdate  template:    roles:    - name: prefill      replicas: 2      maxUnavailable: 1      # entryTemplate and workerTemplate omitted    - name: decode      replicas: 4      maxUnavailable: 25%      # entryTemplate and workerTemplate omitted相关变更：Issue：Control the number of unavailable Role replicas in RoleRollingUpdate #1188[15]PR：Role rollingupdate support maxUnavailable settings #1239[16]贡献者：@hzxuzhonghu、@LiZhenCheng9527 ▍Gateway API 与 HTTPRoute 行为修正Kthena Router现在能够更准确地处理 Gateway API 流量。Router会遵循 HTTPRoute.spec.hostnames，在后端选择和 URL 重写过滤器处理过程中始终使用同一条已匹配的 HTTPRoute 规则，并在同一路由内优先选择更具体的路径规则。由此可以避免请求误用其他链路中的后端。本次发布还修正了 Gateway API 的 PathPrefix 匹配语义，并确保Router仅在满足 Gateway 监听器 allowedRoutes 约束时接纳 HTTPRoute。相关变更：PR：feat: honor HTTPRoute hostnames and matched rule selection #1174[17]Fix HTTPRoute PathPrefix matching #1119[18]fix(router): respect Gateway allowedRoutes #1263[19]贡献者：@zhy76、@Monti-27、@avinxshKD ▍CLI 与 OpenAI 兼容 API 增强Kthena CLI 现在能够展示更实用的状态信息，并支持更多资源类型：kthena get model-servings 新增 READY 和 STATUS 列。kthena get model-boosters 新增 STATUS 列。新增对 kthena get model-routes 和 kthena get model-servers 的支持。新增对 kthena describe model-route 和 kthena describe model-server 的支持。Router还新增了兼容 OpenAI API 的 GET /v1/models 端点，以标准列表响应格式返回当前可用的模型名称。相关变更：PR：feat: add STATUS and READY columns to kthena get output #978[20]feat: add CLI support for ModelRoute and ModelServer resources #981[21]feat: support /v1/models endpoint  #996[22]贡献者：@anirudh240、@madmecodes ▍其他功能增强通过设置 scale 子资源标签选择器，为 ModelServing 新增 KEDA/HPA 兼容能力。#839为 controller-manager 新增调试端口，可用于查看缓存中的 ServingGroup 和 Role 配置。#900新增 SGLang Dynamo 模拟器测试覆盖与 SGLang 推理模拟器集成。#920、#1231为Router新增 pprof 端点支持。#1057在 Helm Chart 中新增 controller-manager 的 debugPort 配置。#1032改进 ModelBooster 的 GPU 与离线环境支持。#972、#1141、#1146、#945新增 GPU 使用率插件 E2E 测试覆盖。#1199更新快速入门文档，并推荐用户优先从 ModelServing 开始使用 Kthena。#1260新增 DeepSeek-v4 模型服务示例。#936、#937新增 KV 缓存感知调度器插件文档。#910更加具体版本信息可以查看 Kthena v1.0.0 的 Release Note：cid:link_1Kthena 诚挚邀请广大开发者、运维人员和 AI 基础设施团队体验 Kthena v1.0.0，并与我们共同塑造下一代云原生大模型推理平台。 相关链接[1] Kthena v1.0.0: https://kthena.volcano.sh/[2] Volcano: https://volcano.sh/[3] Proposal of merge autoscalingPolicybingding into autoscalingPolicy #1172: cid:link_4[4] merge autoscalingpolicybinding to autoscalingpolicy #1203: cid:link_5[5] Implementation of PD disaggregation auto-scaler #1258: cid:link_6[6] Improve multi-round conversation case #1190: cid:link_2[7] session boost queue to optimize multi conversation scenario #1183: cid:link_7[8] Observability for prefix-cache and kvcache-aware Score Plugins: cid:link_0[9] feat(router): add per-pod in-flight request tracking with Redis sync #962: cid:link_16[10] Add SGLang tokenizer support for KV-cache-aware scheduling #997: cid:link_17[11] router: add observability metrics for prefix-cache and kvcache-aware score plugins #1194: cid:link_8[12] feat(router): make pod metrics update interval configurable #1151: cid:link_9[13] perf(router): cache parsed prompt to avoid redundant ParsePrompt call #1123: cid:link_10[14] fix: parallelize pod metrics scraping loop with bounded concurrency #1255: cid:link_11[15] Control the number of unavailable Role replicas in RoleRollingUpdate #1188: cid:link_3[16] Role rollingupdate support maxUnavailable settings #1239: cid:link_12[17] feat: honor HTTPRoute hostnames and matched rule selection #1174: cid:link_13[18] Fix HTTPRoute PathPrefix matching #1119: cid:link_14[19] fix(router): respect Gateway allowedRoutes #1263: cid:link_15[20] feat: add STATUS and READY columns to kthena get output #978: cid:link_18[21] feat: add CLI support for ModelRoute and ModelServer resources #981: cid:link_19[22] feat: support /v1/models endpoint #996: cid:link_20 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入“Kthena” 技术交流群