“这 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” 技术交流群

Kubernetes 默认调度器主要根据 Pod 的资源申请量来选择节点。但在真实集群中，资源申请量不一定等于实际使用量。当用户批量下发 Pod、滚动升级或扩缩容时，这种判断偏差会被放大，容易造成节点热点甚至 OOM。华为云云容器引擎 CCE （下简称 CCE ) Volcano 调度器提供的负载感知调度能力，将节点真实 CPU、内存负载纳入调度决策，让新负载更合理地分布到集群中。 ▍为什么需要负载感知调度1. Pod Request 值与真实资源使用错配业务的资源申请量和实际使用量经常不一致。比如 Java 类业务在启动阶段可能瞬时占用大量 CPU，但稳定运行后资源消耗下降；有些任务内存申请得比较保守，实际使用量远低于 Request；更有甚者， BestEffort Pod 没有 Request 和 Limit，调度器无法从资源声明中判断它们会消耗多少资源。2. 监控数据更新和调度决策之间存在时间差短时间批量创建 Pod 时，调度器可能已经连续把多个 Pod 分配到同一个节点，但这些新 Pod 的资源消耗还没有进入监控曲线。此时节点看起来仍然很空，后续 Pod 可能继续被调度到这个节点。等负载真正跑起来后，节点已经变成热点。3. 批量下发和滚动升级会放大偏差单个 Pod 调度不准，影响可能有限。但 Deployment 批量创建、滚动升级、扩缩容会在短时间内触发多次调度决策。如果每次都基于错配的集群状态，就容易把一批新负载集中放到少数节点上。在真实客户的 CCE 生产集群中，目前业务的内存 Request 和 Limit 通常相差 2G，典型业务可能配置 Request = 12G，Limit = 14G。滚动变更时，如果某个节点因旧 Pod 删除导致真实内存水位短暂下降，例如从 60% 降到 40%，调度器在多个节点的可分配资源都满足的情况下，容易连续选择这个瞬时低水位节点。这会导致新 Pod 集中调度，等业务真正启动并接近实际内存使用后，该节点又迅速变成热点，最终造成节点间负载不均和发布过程中的稳定性风险。▍CCE 负载感知调度架构核心方案在 CCE 生产集群中，华为云在 Volcano 负载感知调度插件（Usage）中率先集成了云原生监控插件与影子负载机制。它不仅能够实时拉取节点的真实 CPU 与内存利用率，还引入了影子负载缓存与 Pod 资源预估模型，将静态指标与动态感知有机结合，保障集群高效平稳运行。▲ CCE Volcano 负载感知调度架构1. 引入真实负载CCE Volcano 负载感知调度插件可以从 CCE 云原生监控插件中获取节点当前 CPU、内存使用率，让调度器知道节点现在的真实资源利用率。2. 引入影子负载对于已经被调度、但还没有被监控系统采集到的 Pod，CCE Volcano 会在调度器内部维护一份 Shadow Load Cache，提前把这些 Pod 对节点造成的压力计入调度决策。3. 引入 Pod 资源预估对于即将调度的新 Pod，CCE Volcano 会根据 Request、Limit、Burst、BestEffort 默认值以及风险系数，估算它可能带来的 CPU 和内存压力。4. 把这些信息接入调度流程在调度时，节点判断不再只依赖静态资源声明，而是综合考虑：节点综合负载 = 真实监控负载 + 影子负载 + 新 Pod 预估压力CCE Volcano 调度框架的两个关键阶段会分别使用上述信息：Predicate 阶段：Usage 插件根据真实负载阈值过滤高压节点；NodeOrder 阶段：综合负载参与节点打分，综合负载越低得分越高，综合负载越高得分越低▍关键实现要点1. 影子负载缓存解决监控滞后问题影子负载缓存记录当前调度 Session 中已经调度、正在绑定、刚 Running 但尚未进入监控窗口的 Pod。这样即使监控指标还没刷新，调度器也能知道某个节点已经被分配了新的负载，避免后续 Pod 继续集中落到同一个节点上。2. Pod 资源预估公式对于有 Request 和 Limit 的 Pod，CCE Volcano 通过下面的方式估算资源压力： Pod Estimate= (request × request_ratio + (limit - request） × burst_ratio)× applied_risk_factor变量含义request/ limitPod 声明的 Request / Limit 值request_ratioRequest 部分的权重，默认 0.7burst_ratio突发量（limit − request）部分的权重，默认 0applied_risk_factor动态风险系数：当节点综合水位 < risk_threshold 时取 1；≥ risk_threshold 时取 risk_factor（默认 1.2）3. 高水位风险保护让调度更保守当节点综合水位超过 risk_threshold 后，后续考虑调度到该节点的 Pod 预估值会乘以 risk_factor。这意味着节点越热，调度器越保守，从而降低继续堆叠负载的概率。变量含义risk_threshold触发风险系数的节点综合水位线，默认60%。risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数，默认1.2。4. 预估值回滚一致性CCE Volcano 会在 Pod 加入影子负载时保存快照，记录它当时估算了多少 CPU、多少内存、落在哪个节点。发生回滚时，直接按快照扣回，而不是重新计算。这样即使节点水位或风险系数在中间发生变化，也能保证加减一致。5. 支持业务化调优Usage 插件的默认预估值为：Burstable / Guaranteed Pod 取 CPU 0.7 * request、内存 0.7 * request；BestEffort Pod 取 CPU 250m、内存 200Mi。但实际生产环境中，不同业务对资源的使用方式差异很大，每批下发的作业资源属性也不一致。CCE Volcano 提供了从 0 到 Limit 值可配的 Pod 资源预估值配置项，用户可在不同业务场景下灵活配置，实现作业的准确均衡调度。下面是一个配置示例：actions: "enqueue, allocate, backfill"tiers: - plugins: - name: usage enablePredicate: false arguments: usage.weight: 5 cpu.weight: 1 memory.weight: 1 thresholds: cpu: 80 mem: 80 estimator: request_ratio: 0.7 burst_ratio: 0 risk_threshold: 0.6 risk_factor: 1.2 be_cpu: 250m be_mem: 200Mimetrics: type: prometheus address: http://prometheus:9090 interval: 30s参数说明参数含义默认值enablePredicate真实负载阈值生效方式。true（默认）= 硬约束，达阈值后该节点不再调度新任务；false = 软约束，达阈值后新任务优先调度到未达阈值节点，但该节点仍允许调度。本示例设为 false 以演示软约束下的打分效果。trueusage.weightUsage 插件在 NodeOrder 阶段对节点打分的权重。1cpu.weight / memory.weight增大对应资源种类的均衡权重。1 / 1thresholds.cpu/ thresholds.mem节点真实利用率阈值，超过后按 enablePredicate 的约束方式调度新工作负载（已运行工作负载不受影响，需配合 enablePredicate 使用）。80 / 80request_ratioRequest 占 Pod 预估值的权重。0.7burst_ratio突发量（Limit − Request）占 Pod 预估值的权重。0risk_threshold触发风险系数的节点综合水位线。0.6risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数。1.2be_cpu / be_memBestEffort Pod 的默认 CPU / 内存估算值。250m / 200Mi▍效果验证下面将介绍如何在华为云CCE集群上验证这个特性的效果。在华为云 CCE 集群使用 Volcano 负载感知调度能力1. 开启负载感知调度关于监控插件的配置，负载感知调度功能开启等操作请参考 CCE Volcano 负载感知调度官方文档：cid:link_22. 环境准备CCE集群环境信息：2 个 4U16G 节点，四个 4U8G 节点。功能验证所需插件在指定两个 4U16G 节点调度并安装完成之后，把两个 4U16G 节点置为不可调度。3. 验证调度效果环境现状通过下发三个指定节点调度的 Deployment，分别有 10/6/2 个副本。每个副本都为 CPU Request=200m, Limit=250m Memory Request=500Mi, Limit=600Mi 并加压到 Request 值这样可以构造集群上节点1占了60%，节点2占35%，节点3占10%，节点4空的情况。执行操作下发一个含 20 个副本的 Deployment，每个副本 CPU Request=200m、Limit=250m，Memory Request=500Mi、Limit=600Mi；加压方式模拟 Java 业务的真实压力曲线：启动陡增后回落到平稳水位；在 Deployment 稳定运行后，进行两次滚动升级操作。预期结果集群 4 个可调度节点初始压力不均匀。下发 Deployment 时，调度器应在调度每个 Pod 时实时考虑：集群中每个节点的真实压力；同一 Session 中之前已调度的 Pod 对集群产生的压力（影子负载）。这样才能在调度完整批副本后，把负载均分到 4 个节点，使四节点内存与 CPU 水位相近，且运行一段时间后无 OOM。两次滚动升级后，各节点压力也应保持相对平均。实际结果批量下发一批新负载后的结果。第一次滚动升级后的调度结果：第二次滚动升级后的调度结果：可以看到在批量下发和滚动升级之后，调度结果都在四个节点中平均分布，符合打散一批负载在集群中各节点分布的预期。▍演进方向Volcano 负载感知调度特性当前已覆盖 CPU 和内存资源，后续可从三个方向扩展：异构资源扩展：在 AI 训练、推理、视频处理等场景中，GPU/NPU 利用率、显存、设备队列等待时间都会影响调度质量，仅看 CPU 和内存已不够。未来把影子负载与风险估算扩展到这些指标上。节点池粒度负载感知：生产集群常按节点池区分规格、可用区、业务类型或成本模型。只看单节点，可能留下节点池层面的冷热不均，后续可加入节点池级别的负载感知。预估模型自适应：当前 request_ratio / burst_ratio 等参数需用户静态配置，未来可结合历史负载曲线做自适应估计，进一步降低调参成本▍总结负载感知调度解决的是生产环境中经常遇到的问题：Pod 申报的资源和真实消耗不总是一致，监控指标也不总是和调度决策同步，从而导致资源错配。Volcano Usage 插件把真实指标、节点阈值、节点打分、影子负载、资源预估与回滚一致性串接到同一条调度链路中：真实指标：CCE Volcano 从 CCE 云原生监控插件主动拉取节点真实压力；影子负载：覆盖节点上尚未纳入监控范围的 Pod 的预估值；资源预估：使不同 QoS 等级的 Pod 占用都能被合理量化；快照回滚：保证 Deallocate 之后增减一致，不留下错误记录。对用户而言，负载感知调度的价值比较直接：批量新建、滚动升级、扩缩容时，不容易把新负载继续堆到即将变热的节点上；当业务 Request 值不够准确时，也可通过参数调整调度策略，实现更稳健的均衡调度。华为云 CCE 团队结合大规模生产集群的真实打磨，沉淀出这一负载感知调度方案。同时，作为 Volcano 社区的核心贡献者，团队已将相关的代码与特性贡献至 Volcano 开源社区，以推动云原生调度技术的持续演进。 参考资料CCE Volcano 负载感知调度官方文档：cid:link_2Kubernetes 调度框架文档：https://kubernetes.io/docs/concepts/scheduling-eviction/ 关注魔方公众号，获取更多前沿资讯 

Kubernetes 默认调度器主要根据 Pod 的资源申请量来选择节点。但在真实集群中，资源申请量不一定等于实际使用量。当用户批量下发 Pod、滚动升级或扩缩容时，这种判断偏差会被放大，容易造成节点热点甚至 OOM。华为云云容器引擎 CCE （下简称 CCE ) Volcano 调度器提供的负载感知调度能力，将节点真实 CPU、内存负载纳入调度决策，让新负载更合理地分布到集群中。▍为什么需要负载感知调度1. Pod Request 值与真实资源使用错配业务的资源申请量和实际使用量经常不一致。比如 Java 类业务在启动阶段可能瞬时占用大量 CPU，但稳定运行后资源消耗下降；有些任务内存申请得比较保守，实际使用量远低于 Request；更有甚者， BestEffort Pod 没有 Request 和 Limit，调度器无法从资源声明中判断它们会消耗多少资源。2. 监控数据更新和调度决策之间存在时间差短时间批量创建 Pod 时，调度器可能已经连续把多个 Pod 分配到同一个节点，但这些新 Pod 的资源消耗还没有进入监控曲线。此时节点看起来仍然很空，后续 Pod 可能继续被调度到这个节点。等负载真正跑起来后，节点已经变成热点。3. 批量下发和滚动升级会放大偏差单个 Pod 调度不准，影响可能有限。但 Deployment 批量创建、滚动升级、扩缩容会在短时间内触发多次调度决策。如果每次都基于错配的集群状态，就容易把一批新负载集中放到少数节点上。在真实客户的 CCE 生产集群中，目前业务的内存 Request 和 Limit 通常相差 2G，典型业务可能配置 Request = 12G，Limit = 14G。滚动变更时，如果某个节点因旧 Pod 删除导致真实内存水位短暂下降，例如从 60% 降到 40%，调度器在多个节点的可分配资源都满足的情况下，容易连续选择这个瞬时低水位节点。这会导致新 Pod 集中调度，等业务真正启动并接近实际内存使用后，该节点又迅速变成热点，最终造成节点间负载不均和发布过程中的稳定性风险。▍CCE 负载感知调度架构核心方案在 CCE 生产集群中，华为云在 Volcano 负载感知调度插件（Usage）中率先集成了云原生监控插件与影子负载机制。它不仅能够实时拉取节点的真实 CPU 与内存利用率，还引入了影子负载缓存与 Pod 资源预估模型，将静态指标与动态感知有机结合，保障集群高效平稳运行。▲ CCE Volcano 负载感知调度架构1. 引入真实负载CCE Volcano 负载感知调度插件可以从 CCE 云原生监控插件中获取节点当前 CPU、内存使用率，让调度器知道节点现在的真实资源利用率。2. 引入影子负载对于已经被调度、但还没有被监控系统采集到的 Pod，CCE Volcano 会在调度器内部维护一份 Shadow Load Cache，提前把这些 Pod 对节点造成的压力计入调度决策。3. 引入 Pod 资源预估对于即将调度的新 Pod，CCE Volcano 会根据 Request、Limit、Burst、BestEffort 默认值以及风险系数，估算它可能带来的 CPU 和内存压力。4. 把这些信息接入调度流程在调度时，节点判断不再只依赖静态资源声明，而是综合考虑：节点综合负载 = 真实监控负载 + 影子负载 + 新 Pod 预估压力CCE Volcano 调度框架的两个关键阶段会分别使用上述信息：Predicate 阶段：Usage 插件根据真实负载阈值过滤高压节点；NodeOrder 阶段：综合负载参与节点打分，综合负载越低得分越高，综合负载越高得分越低▍关键实现要点1. 影子负载缓存解决监控滞后问题影子负载缓存记录当前调度 Session 中已经调度、正在绑定、刚 Running 但尚未进入监控窗口的 Pod。这样即使监控指标还没刷新，调度器也能知道某个节点已经被分配了新的负载，避免后续 Pod 继续集中落到同一个节点上。2. Pod 资源预估公式对于有 Request 和 Limit 的 Pod，CCE Volcano 通过下面的方式估算资源压力： Pod Estimate= (request × request_ratio + (limit - request × burst_ratio)× applied_risk_factor变量含义request/ limitPod 声明的 Request / Limit 值request_ratioRequest 部分的权重，默认 0.7burst_ratio突发量（limit − request）部分的权重，默认 0applied_risk_factor动态风险系数：当节点综合水位 < risk_threshold 时取 1；≥ risk_threshold 时取 risk_factor（默认 1.2）3. 高水位风险保护让调度更保守当节点综合水位超过 risk_threshold 后，后续考虑调度到该节点的 Pod 预估值会乘以 risk_factor。这意味着节点越热，调度器越保守，从而降低继续堆叠负载的概率。变量含义risk_threshold触发风险系数的节点综合水位线，默认60%。risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数，默认1.2。4. 预估值回滚一致性CCE Volcano 会在 Pod 加入影子负载时保存快照，记录它当时估算了多少 CPU、多少内存、落在哪个节点。发生回滚时，直接按快照扣回，而不是重新计算。这样即使节点水位或风险系数在中间发生变化，也能保证加减一致。5. 支持业务化调优Usage 插件的默认预估值为：Burstable / Guaranteed Pod 取 CPU 0.7 * request、内存 0.7 * request；BestEffort Pod 取 CPU 250m、内存 200Mi。但实际生产环境中，不同业务对资源的使用方式差异很大，每批下发的作业资源属性也不一致。CCE Volcano 提供了从 0 到 Limit 值可配的 Pod 资源预估值配置项，用户可在不同业务场景下灵活配置，实现作业的准确均衡调度。下面是一个配置示例：actions: "enqueue, allocate, backfill"tiers: - plugins: - name: usage enablePredicate: false arguments: usage.weight: 5 cpu.weight: 1 memory.weight: 1 thresholds: cpu: 80 mem: 80 estimator: request_ratio: 0.7 burst_ratio: 0 risk_threshold: 0.6 risk_factor: 1.2 be_cpu: 250m be_mem: 200Mimetrics: type: prometheus address: http://prometheus:9090 interval: 30s参数说明参数含义默认值enablePredicate真实负载阈值生效方式。true（默认）= 硬约束，达阈值后该节点不再调度新任务；false = 软约束，达阈值后新任务优先调度到未达阈值节点，但该节点仍允许调度。本示例设为 false 以演示软约束下的打分效果。trueusage.weightUsage 插件在 NodeOrder 阶段对节点打分的权重。1cpu.weight / memory.weight增大对应资源种类的均衡权重。1 / 1thresholds.cpu/ thresholds.mem节点真实利用率阈值，超过后按 enablePredicate 的约束方式调度新工作负载（已运行工作负载不受影响，需配合 enablePredicate 使用）。80 / 80request_ratioRequest 占 Pod 预估值的权重。0.7burst_ratio突发量（Limit − Request）占 Pod 预估值的权重。0risk_threshold触发风险系数的节点综合水位线。0.6risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数。1.2be_cpu / be_memBestEffort Pod 的默认 CPU / 内存估算值。250m / 200Mi▍效果验证下面将介绍如何在华为云CCE集群上验证这个特性的效果。在华为云 CCE 集群使用 Volcano 负载感知调度能力1. 开启负载感知调度关于监控插件的配置，负载感知调度功能开启等操作请参考 CCE Volcano 负载感知调度官方文档：cid:link_12. 环境准备CCE集群环境信息：2 个 4U16G 节点，四个 4U8G 节点。功能验证所需插件在指定两个 4U16G 节点调度并安装完成之后，把两个 4U16G 节点置为不可调度。3. 验证调度效果环境现状通过下发三个指定节点调度的 Deployment，分别有 10/6/2 个副本。每个副本都为 CPU Request=200m, Limit=250m Memory Request=500Mi, Limit=600Mi 并加压到 Request 值这样可以构造集群上节点1占了60%，节点2占35%，节点3占10%，节点4空的情况。执行操作下发一个含 20 个副本的 Deployment，每个副本 CPU Request=200m、Limit=250m，Memory Request=500Mi、Limit=600Mi；加压方式模拟 Java 业务的真实压力曲线：启动陡增后回落到平稳水位；在 Deployment 稳定运行后，进行两次滚动升级操作。预期结果集群 4 个可调度节点初始压力不均匀。下发 Deployment 时，调度器应在调度每个 Pod 时实时考虑：集群中每个节点的真实压力；同一 Session 中之前已调度的 Pod 对集群产生的压力（影子负载）。这样才能在调度完整批副本后，把负载均分到 4 个节点，使四节点内存与 CPU 水位相近，且运行一段时间后无 OOM。两次滚动升级后，各节点压力也应保持相对平均。实际结果批量下发一批新负载后的结果。第一次滚动升级后的调度结果：第二次滚动升级后的调度结果：可以看到在批量下发和滚动升级之后，调度结果都在四个节点中平均分布，符合打散一批负载在集群中各节点分布的预期。▍演进方向Volcano 负载感知调度特性当前已覆盖 CPU 和内存资源，后续可从三个方向扩展：异构资源扩展：在 AI 训练、推理、视频处理等场景中，GPU/NPU 利用率、显存、设备队列等待时间都会影响调度质量，仅看 CPU 和内存已不够。未来把影子负载与风险估算扩展到这些指标上。节点池粒度负载感知：生产集群常按节点池区分规格、可用区、业务类型或成本模型。只看单节点，可能留下节点池层面的冷热不均，后续可加入节点池级别的负载感知。预估模型自适应：当前 request_ratio / burst_ratio 等参数需用户静态配置，未来可结合历史负载曲线做自适应估计，进一步降低调参成本▍总结负载感知调度解决的是生产环境中经常遇到的问题：Pod 申报的资源和真实消耗不总是一致，监控指标也不总是和调度决策同步，从而导致资源错配。Volcano Usage 插件把真实指标、节点阈值、节点打分、影子负载、资源预估与回滚一致性串接到同一条调度链路中：真实指标：CCE Volcano 从 CCE 云原生监控插件主动拉取节点真实压力；影子负载：覆盖节点上尚未纳入监控范围的 Pod 的预估值；资源预估：使不同 QoS 等级的 Pod 占用都能被合理量化；快照回滚：保证 Deallocate 之后增减一致，不留下错误记录。对用户而言，负载感知调度的价值比较直接：批量新建、滚动升级、扩缩容时，不容易把新负载继续堆到即将变热的节点上；当业务 Request 值不够准确时，也可通过参数调整调度策略，实现更稳健的均衡调度。华为云 CCE 团队结合大规模生产集群的真实打磨，沉淀出这一负载感知调度方案。同时，作为 Volcano 社区的核心贡献者，团队已将相关的代码与特性贡献至 Volcano 开源社区，以推动云原生调度技术的持续演进。 参考资料CCE Volcano 负载感知调度官方文档：cid:link_1Kubernetes 调度框架文档：https://kubernetes.io/docs/concepts/scheduling-eviction/ 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入CCE技术交流群

| 核心变化：从“仅支持并行文件系统”到“同时支持对象桶&并行文件系统”对于许多开发者而言，obsfs 一直是连接本地文件系统与华为云 OBS的关键工具，但在过去，其“不支持挂载对象存储桶”的限制，让不少习惯使用标准对象存储（OBS Bucket）的开发者感到困扰，不得不在数据访问方式上做出妥协。近期，华为云 OBS 服务对 obsfs 工具进行了重大升级，正式支持将标准的对象存储桶挂载至本地文件系统。这一改变，意味着开发者现在可以像访问本地目录一样，直接操作对象存储桶中的海量数据，为 AI 训练、大数据分析等场景提供了全新的存储访问路径。这一变化最直接的影响是：覆盖更广的使用场景：你可以直接对项目中已有的、正在使用的对象桶进行操作，无需为了使用 obsfs 而额外创建或迁移数据到并行文件系统。降低使用门槛：使得更多开发者可以零成本地尝试用本地文件系统的方式管理云上对象存储。| obsfs 对象桶挂载：能解决什么问题？简单来说，obsfs 是一款基于 FUSE 的文件系统工具，它的核心价值在于零代码改造。无论是日志收集脚本、数据处理任务，还是传统的 Web 应用，都无需修改任何文件读写逻辑，就能将数据持久化到 OBS。新能力带来的典型适用场景包括：日志、归档数据的自动上传：将本地日志目录挂载为 OBS 桶，新产生的日志文件自动进入云存储。数据分析与处理的输入输出：在 Spark、Hadoop 等计算任务中，直接将 OBS 作为数据源和结果存储池。遗留系统的存储云化：对于难以改造的老旧应用，通过挂载方式无缝将数据迁移至 OBS。不过需要了解的是，由于对象桶本身的对象语义限制（不支持追加写、随机写），obsfs 通过 FUSE 层模拟了文件操作。任何“修改”在后台实际是“新对象覆盖旧对象”的适配行为。因此，它更适用于顺序读写的场景，而非高并发、小文件频繁读写的数据库类应用。| 实战：三步挂载，体验新能力如何快速体验这个新能力？以下是将一个 OBS 对象桶挂载到本地的具体操作步骤。1. 获取与安装 obsfsobsfs 支持直接下载和编译两种方式。详细步骤参考官网：方式一：下载并安装obsfs方式二：通过编译生成obsfs2. 初始化访问密钥创建一个密钥文件，用于存放你的 OBS 访问密钥（AK/SK），并设置权限为 600 以确保安全。初始化访问密钥3. 执行挂载命令挂载命令格式：./obsfs obs桶名 本地挂载目录 -o url=区域终端节点地址 -o passwd_file=密钥文件路径 -o bucket_type=object -o multipart_size=128 -o 其他挂载参数假设你有一个名为 my-obs-bucket 的 OBS 对象桶，想挂载到本地 /mnt/obs 目录。执行以下命令即可：./obsfs my-obs-bucket /mnt/obs -o url=obs.cn-south-1.myhuaweicloud.com -o passwd_file=/etc/passwd-obsfs -o bucket_type=object注意这里的关键变化：-o bucket_type=object 参数，用于显式声明挂载的是对象桶。这是使用新能力时必须指定的参数，用以区分以往的并行文件系统挂载。挂载成功后，执行 df -h 就能看到你的对象桶已作为一个文件系统挂载在本地。之后，无论是 cp、mv、rm 等常规文件操作，还是你的应用程序通过标准文件接口读写数据，都会直接映射到 OBS 桶中。| 核心设计解析：对象桶挂载的工作原理与注意事项理解 obsfs 对象桶模式的设计逻辑，能帮助你更好地使用它，避免踩坑。1. 回写模式与数据持久性对象桶挂载采用回写模式。数据会先写入本地临时文件（由 tmpdir 或 use_cache 控制）。在默认情况下，只有当应用调用 close() 关闭文件时，才会触发实际上传，close() 返回成功表示数据已持久化到 OBS。因此，进程异常退出（如 kill -9、断电）可能导致未关闭文件的数据永久丢失。针对大文件的优化：对于超大文件上传，可以通过 -o max_dirty_data=1024（单位MB）等参数设置阈值，当本地未上传的脏数据量超过该值时，obsfs 会自动触发流式分段上传，将已写入的数据提前上传，避免 close() 时因全量重传导致长时间阻塞。实践建议：对于关键数据，务必检查 close() 的返回值；对持久性要求极高的场景，可考虑使用 fsync() 定期刷新（需权衡性能）；大文件场景下合理设置 max_dirty_data 和 multipart_size 参数以优化上传效率。2. 缓存机制与性能调优obsfs 提供多个缓存参数，用以提升性能：use_cache：指定本地磁盘缓存目录。启用后，读写的数据会缓存到本地，重复读取时性能显著提升。建议指向高性能的本地 SSD。multipart_size 与 parallel_count：分别控制分段上传的大小和并发线程数，调整这两个参数可以有效利用网络带宽，提升大文件的吞吐量。max_stat_cache_size：控制文件属性（大小、修改时间等）的缓存条目数，减少对 OBS 的 HEAD 请求，提升 ls -l 等操作的响应速度。3. 数据一致性与多挂载点需要注意的是，一个 OBS 桶可以同时挂载到多台服务器上，但各挂载点之间互不感知。obsfs 本身不提供文件锁机制，也无法感知 OBS 的多版本控制。因此，如果多个客户端并发写入同一个文件，可能出现数据覆盖或一致性问题，需要在应用层通过其他方式（如分布式锁）来协调。| 结语从仅支持并行文件系统，到 2026 年 6 月起新增对标准对象桶的挂载支持，obsfs 的这次升级，本质上是将一套统一的本地文件系统访问接口，覆盖到了 OBS 中更广泛、更常用的存储类型上。它为开发者提供了一种零侵入、低成本的云存储接入方式，尤其为那些希望利用云存储但代码改造困难的场景，提供了一条平滑的迁移路径。当然，你也要认识到它在随机写、强一致性场景下的局限，并将其用在合适的地方。关于 obsfs 的完整参数列表和最佳实践，欢迎查阅华为云官方文档。如果你在挂载过程中遇到问题，也欢迎在华为云开发者社区发帖交流，共同探讨。 相关链接：[1] obsfs 开源 GitHub 仓库：cid:link_5[2] obsfs 官方工具指南：cid:link_3[3] 挂载对象存储桶详细指导：cid:link_4

开发者专属免费考证福利来了！【云学堂·云原生技术实战营】活动正式开营！集齐5个微认证兑换云原生入门级开发者认证证书。 一、【活动时间】2026年 06月 15日 - 2026年 09月 30日二、【报名链接】cid:link_1三、【活动福利】1、每通过1门微认证考试→获得对应华为云官方微认证证书2、通过指定5门云原生微认证→免费兑换华为云云原生入门级开发者认证证书3、一键免费领取华为云码道体验版，开启你的编码自动驾驶模式！四、参与流程Step1、AI智能编码辅助工具体验，0 门槛上手，小白也能变大神​！支持 Java/Python/Go 等 7 种主流语言，代码生成、注释、调试、翻译一键搞定！一键免费领取体验版：https://developer.huaweicloud.com/codeartsco.html?source=dmznteducation&sourcead=dmznthd，立即体验，开启你的编码自动驾驶模式！ Step2、集齐5个微认证证书免费兑换云原生入门级开发者认证证书序号认证名称（含免费激活入口）1云原生基础设施之容器入门2云原生基础设施之容器进阶3基于CCE Kubernetes编排实战4CCE网络与存储实战5云容器快速搭建网站通过序号1-5微认证且获得证书后，点此兑换云原生入门级开发者证书（我的认证→我的证书兑换）【考试说明】1、云原生5个微认证无需购买，点击表格中认证名称进入认证详情页，点击“免费激活”按钮即可，如考试未通过可再次点击“免费激活”。2、云原生5个微认证需要理论考试≥70分+实验考试≥60分才算考试通过。3、考试通过后第1个自然日后将发放证书，可前往我的学堂- 我的证书查看证书编号和下载电子证书。 不管是入门新手、在校同学还是职场开发者，都可以一站式学练考！