CCE 集群里给 Deployment 配了 HPA，目标 CPU 60%，压测时 kubectl get hpa 一直是 TARGETS: <unknown>/60%，Pod 数量完全不动。NAME REFERENCE TARGETS MINPODS MAXPODS REPLICASmyapp Deployment/myapp <unknown>/60% 2 10 2已经确认：kubectl top pod -n prod 有数据，说明 metrics-server 是活的；Deployment 的 Pod 模板里写了 limits.cpu，但 没写 requests.cpu；HPA 用的是 autoscaling/v2，只配了 CPU 一个指标。想确认两件事：没写 requests 是不是就会导致 unknown？补上 requests 之后需要重建 Pod 才生效吗？另外 HPA 扩缩容有没有冷却期，会不会我压测时间太短看不出来？

集群里有几个节点跑的是 WebSocket 长连接服务（每台大概 3 万个连接）。现在要做节点池的 Kubernetes 版本升级，担心的是排空（drain）时 Pod 被重建，长连接会成批断开，客户端重连风暴把新 Pod 压垮。 目前的做法：1. 给 Deployment 配了 PodDisruptionBudget，minAvailable 设成 80%；2. 容器里加了 preStop，sleep 30 秒后主动关闭监听并等待已有连接自然结束；3. 用节点池的「分批升级」，一次只升 1 台。 想确认几点：1. CCE 节点池升级时的 drain 是否会遵守 PodDisruptionBudget？还是按节点粒度直接驱逐？2. preStop 的执行时长有没有上限？gracePeriodSeconds 设成 120 秒够不够？3. 有没有官方推荐的「先摘流量再排空」做法，比如配合 ELB 的健康检查下线延迟？ 如果大家有类似长连接业务在 CCE 上升级的经验，欢迎指点一下具体参数怎么配。

在使用 CCE 集群时遇到节点 NotReady 后 Pod 被驱逐的情况，想了解驱逐（eviction）的触发阈值和最佳实践。比如节点内存/磁盘压力达到多少比例会触发 kubelet 驱逐，驱逐顺序是怎么排的（先驱逐个 Pod 还是按 QoS），以及有没有办法只驱逐特定命名空间的 Pod？另外对于 DaemonSet 类型的 Pod，默认是不是不会被驱逐，需要额外配置 toleration 吗？

排查线上问题时想确认几台机器的网卡 MTU 是否一致，但逐台登录执行 ip link 看太慢。请问在 CCE 集群里有没有推荐的批量方式获取所有节点的 MTU、IP、网卡名等信息？ 另外如果容器内访问外部服务的路径 MTU 不通（比如能 ping 通但 TCP 握手超时），除了调 MTU 还有哪些常见的排查方向？是否有对应的 CloudEye 指标或者日志可以参考？

测试内容B测试内容C

CCE 集群扩容新加了一台节点，创建成功了但节点状态一直是 NotReady，kubectl get nodes 里旧节点都正常。安全组是和旧节点复用同一套的。想问下除了 CNI 网络插件，还有哪些常见原因，怎么一步步定位。

为什么我的内网电脑不能连接成功ELB，有虚拟网管关，有配置好的物理云专线，是需要开通我的电脑ip到华为云之间的安全组或ACL吗

内网中CCE容器为什么连接不上GsussDB，提示我连接超时，GaussDB数据库绑定的安全组是默认的安全组，入方向都是ANY

最好的产品，诞生于用户的每一次点击与反馈。华为云云容器引擎 CCE 近期围绕大家反馈的远程登录、日志体验等方向进行了专项优化，欢迎体验：cid:link_1  

华为云容器引擎 CCE 近期推出多项核心能力新增和升级，从 AI 容器、备份中心、Gateway API、集群自动升配、负载感知调度等全面进化您的云原生体验，助力业务高效、稳定、安全地运行。即刻访问体验：cid:link_1 

导读：将一张昇腾 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/关注魔方公众号，获取更多前沿资讯

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

开发者专属免费考证福利来了！【云学堂·云原生技术实战营】活动正式开营！集齐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个自然日后将发放证书，可前往我的学堂- 我的证书查看证书编号和下载电子证书。 不管是入门新手、在校同学还是职场开发者，都可以一站式学练考！

在云原生时代，Kubernetes集群的运维复杂度正在以指数级增长。Pod频繁重启、节点异常、告警风暴、容量风险……每一类问题背后，都涉及Pod、节点、事件、日志等多层资源的交叉关联，人工定位链路长，判断成本极高。华为云云原生Skills的诞生，正是为了解决这一困境——将专业知识、操作流程和最佳实践转化为可复用的能力单元，让AI Agent具备专业的云原生运维能力。 什么是云原生Skills？Skill是将专业知识、操作流程和最佳实践转化为可复用能力单元的开放范式。在AI Agent体系中，Skill使Agent能够按照预定义的流程和规则，自动执行特定领域的复杂任务。华为云云原生Skills承接该范式，将专家经验沉淀为Agent可调用的能力模块，为企业的云原生运维提供了一条从传统人工排障向 Agentic Ops 演进的新路径，既支持在现有运维体系中嵌入AI提效，也支持为关键业务构建Agent原生的诊断与恢复模式：全栈可观测覆盖：云原生Skills整合CCE、AOM、LTS、ELB、ECS、HSS等云服务的运维能力，可自动汇聚告警、日志、K8s事件、Pod/Node指标形成诊断上下文，覆盖故障诊断、可观测分析、巡检治理、自动恢复等场景。意图驱动的智能诊断：Agent通过读取Skill的description自动理解触发时机，用户只需用自然语言描述故障现象，无需显式指定Skill。Agent即可完成从现象识别、证据采集、根因分析到恢复方案的全流程诊断。场景化编排与闭环：单个Skill内部串联多个操作步骤，自动完成上下文收集、分析和结论输出，一站式闭环。多个Skill可按工作流组合使用，Agent根据任务需要自动选择和调用合适的Skill组合。Agent友好与安全可控：Skill以独立目录提供，可在Web、CLI、API等不同Agent平台上运行，无需为每个平台单独适配。内置风险分级机制与安全护栏，所有删除、扩缩容、drain等变更类操作必须先预览、再经用户确认后方可执行。 从故障诊断到主动治理：典型应用场景全覆盖华为云云原生Skills覆盖了云原生运维的全链路场景：故障诊断：Pod CrashLoopBackOff、节点NotReady、Ingress 502、PVC Pending等常见故障分析。可观测分析：汇聚AOM告警、LTS日志、K8s事件、Pod/Node指标形成诊断上下文。巡检治理：每日集群健康检查、容量趋势预测、成本优化建议、可用性风险扫描。自动恢复：扩缩容、cordon/drain节点、重启ECS、HSS漏洞修复等受控变更。交付方案：容器迁移规划、资源盘点、依赖矩阵分析。集群管理：CCE集群升级规划、工作负载管理、UCS集群纳管与策略治理。 让智能运维落地有声：最佳实践华为云提供了丰富的最佳实践，帮助用户快速上手： ▍实践一：使用AI CLI对CCE工作负载进行故障诊断与恢复  基于用户描述的故障现象（如Pod长时间未就绪、容器频繁重启、镜像拉取失败等），AI Agent自动完成上下文识别、证据采集、根因分析、恢复方案预览、用户确认、恢复执行和结果验证的全流程。 ▍实践二：配置、查询和治理CCE AOM告警 用户用自然语言完成CCE AOM告警规则配置、查询、聚合分析和严重告警根因追查。 AI CLI会自动归并同类告警，帮助用户快速判断“哪些告警最紧急、影响哪些资源、下一步应该查什么”。 ▍实践三：集群定期巡检 通过OpenClaw Agent用自然语言配置周期性巡检任务，自动完成集群健康检查、告警聚合、异常分析、风险分级、报告生成和通知推送。巡检过程只执行只读查询，不会自动执行任何变更动作。 ▍实践四：配置CCE集群秒级弹性至CCI 2.0通过提示词即可自动完成集群预检、插件安装及网络配置，采用预览确认机制，用户确认后执行，支持短时高负载场景下的秒级弹性伸缩。 ▍实践五：ChatOps智能运维 基于Hermes构建生产环境智能运维Agent ，定时扫描现网告警，自动归并分析，生成恢复方案，在手机端确认后执行恢复动作。将“告警发现→归并→上下文采集→根因分析→恢复预览→用户确认→执行恢复→效果验证→结果归档”沉淀为可复用的ChatOps值班能力。 让运维经验可传承、可进化华为云云原生Skill当前已上线云容器引擎CCE服务官网，用户可在各类Agent客户端中安装调用。它将华为云在云原生领域积累的诊断经验与运维最佳实践，封装为开放的能力单元，让企业无需从零构建，即可获得开箱即用的智能运维能力——从诊断到恢复，对话即完成。让AI读懂云原生，让运维回归创造性工作——这正是华为云云原生Skills的使命所在。 立即体验：cid:link_1  

配置信息如下： 弹出信息如下：