容器服务
容器服务
容器服务
文档指南
请输入
容器服务 VKE
产品动态
Kubernetes 版本发布记录
组件发布记录
监控组件
DNS 组件
GPU 组件
Sandbox 组件
安全公告
产品公告
历史公告
用户指南
集群
节点池
授权
网络
容器网络
服务（Service）
路由（Ingress）
APIG Ingress
ALB Ingress
自定义转发规则配置示例
CLB Ingress
Nginx Ingress
Gateway API
工作负载
存储
数据管理中心（DMC）
对象存储（TOS）
FSX 访问方式
文件存储（NAS）
FSX 访问方式
弹性文件存储（EFS）
文件存储（vePFS）
FSX 访问方式
vePFS Client 访问方式
NFS 访问方式
大数据文件存储（CloudFS）
弹性伸缩
工作负载弹性伸缩
事件驱动伸缩（KEDA）
组件管理
网络组件
监控组件
DNS 组件
GPU 组件
Sandbox 组件
异构计算
调度管理
可观测性
基础观测
诊断与巡检
最佳实践
网络
可观测性
安全合规
API 参考
集群管理
节点池管理
组件管理
机型镜像管理
云原生观测
巡检诊断
弹性容器实例
附录
开发指南
常见问题
通用 FAQ
集群 FAQ
集群管理
集群升级
节点与节点池 FAQ
授权 FAQ
工作负载 FAQ
服务与路由 FAQ
存储 FAQ
弹性伸缩 FAQ
可观测性 FAQ
配额 FAQ
组件 FAQ
容器镜像 FAQ
AI 云原生
推理套件
Helm 模板 AI 应用
Deepseek 实践
Qwen 实践
最佳实践
MiniMax 模型部署
Qwen 模型部署
弹性容器实例 VCI
最新动态
用户指南
虚拟节点
VKE 集群使用虚拟节点
自建/跨云集群使用虚拟节点
创建 VCI 实例
VCI Agent Sandbox
安全合规
- 文档首页
容器服务容器服务 VKE常见问题调度 FAQCPU QoS 调度常见问题
复制全文
下载 pdfCPU QoS 调度常见问题
文档反馈
问问助手本文主要介绍使用 CPU QoS 能力时的常见问题及其解决方法。
*CPU QoS 和 Kubernetes 原生 QoS 是什么关系？
*Kubernetes 原生 QoS 主要根据 Pod 的 Request 和 Limit 对资源保障等级进行分类。CPU QoS 是对运行时（Runtime）CPU 的资源管理能力，用于进一步管理资源池、CPU Burst 和压力驱逐。CPU QoS 和 Kubernetes 原生 QoS 两者可以配合使用，但不等价。原生 QoS 相关信息，请参见 Kubernetes 文档。
CPU QoS 和 Kubernetes 原生 QoS 是什么关系？
Kubernetes 原生 QoS 主要根据 Pod 的 Request 和 Limit 对资源保障等级进行分类。CPU QoS 是对运行时（Runtime）CPU 的资源管理能力，用于进一步管理资源池、CPU Burst 和压力驱逐。CPU QoS 和 Kubernetes 原生 QoS 两者可以配合使用，但不等价。原生 QoS 相关信息，请参见 Kubernetes 文档。
*CPU QoS 和 Pod CPU Burst 是什么关系？
*CPU QoS 负责业务分层与 CPU 服务质量保障，Pod CPU Burst 负责在节点有空闲算力时提供短时 CPU 弹性。两者可以同时开启。
CPU QoS 和 Pod CPU Burst 是什么关系？
CPU QoS 负责业务分层与 CPU 服务质量保障，Pod CPU Burst 负责在节点有空闲算力时提供短时 CPU 弹性。两者可以同时开启。
*shared_cores 和 reclaimed_cores 应如何选择？
*shared_cores 适用于常规在线业务或延迟敏感型业务。reclaimed_cores 适用于离线、批处理、可重试或可中断任务。
shared_cores 和 reclaimed_cores 应如何选择？
shared_cores 适用于常规在线业务或延迟敏感型业务。reclaimed_cores 适用于离线、批处理、可重试或可中断任务。
*开启 CPU QoS 是否需要修改业务代码？
*不需要。CPU QoS 在节点侧生效，通常只需要为工作负载中增加 Annotation，并按需配置集群级策略。
开启 CPU QoS 是否需要修改业务代码？
不需要。CPU QoS 在节点侧生效，通常只需要为工作负载中增加 Annotation，并按需配置集群级策略。
*开启 CPU QoS 后是否一定能降低延迟？
*CPU QoS 可以降低低优先级业务因争抢 CPU 从而对高优业务造成的影响，但实际效果仍取决于业务负载模型、节点资源使用率、Burst 配置以及驱逐策略。建议结合业务指标和平台观测结果综合评估。
开启 CPU QoS 后是否一定能降低延迟？
CPU QoS 可以降低低优先级业务因争抢 CPU 从而对高优业务造成的影响，但实际效果仍取决于业务负载模型、节点资源使用率、Burst 配置以及驱逐策略。建议结合业务指标和平台观测结果综合评估。
*reclaimed_cores Pod 一定会被驱逐吗？
*不会。是否被驱逐取决于驱逐开关（enableSuppressionEviction）是否已开启、节点压力是否持续超阈值，以及该 Pod 是否被纳入驱逐范围。
reclaimed_cores Pod 一定会被驱逐吗？
不会。是否被驱逐取决于驱逐开关（enableSuppressionEviction）是否已开启、节点压力是否持续超阈值，以及该 Pod 是否被纳入驱逐范围。
*为什么未配置 QoS 的 Pod 也会进入共享池？
*当前默认行为是：未设置katalyst.kubewharf.io/qos_level的 Pod 按 shared_cores 处理。为了获得更明确的资源治理效果，建议显式为关键业务和离线任务声明 QoS 类型。
为什么未配置 QoS 的 Pod 也会进入共享池？
当前默认行为是：未设置katalyst.kubewharf.io/qos_level的 Pod 按 shared_cores 处理。为了获得更明确的资源治理效果，建议显式为关键业务和离线任务声明 QoS 类型。
*开启 Overlap 对内核有什么要求？
*Overlap 依赖 CPU Idle，需要节点内核支持cpu.idle参数。建议使用 veLinux 2.0（5.15 / 6.6 内核）等支持该特性的镜像；velinux1 5.10、ubuntu 20.04 等不支持cpu.idle参数的内核无法启用。节点镜像相关说明，请参见 操作系统镜像概述。
*可通过如下操作，查看节点是否支持 CPU Idle：
*登录 Pod 所在节点，登录方法，请参见 ECS Terminal。
*执行以下命令查看节点是否支持 CPU Idle。不同的 cgroup 请执行对应的命令。
*
*
开启 Overlap 对内核有什么要求？
Overlap 依赖 CPU Idle，需要节点内核支持cpu.idle参数。建议使用 veLinux 2.0（5.15 / 6.6 内核）等支持该特性的镜像；velinux1 5.10、ubuntu 20.04 等不支持cpu.idle参数的内核无法启用。节点镜像相关说明，请参见 操作系统镜像概述。
可通过如下操作，查看节点是否支持 CPU Idle：
- 登录 Pod 所在节点，登录方法，请参见 ECS Terminal。
- 执行以下命令查看节点是否支持 CPU Idle。不同的 cgroup 请执行对应的命令。
- #cgroup v1cat /sys/fs/cgroup/cpu/kubepods/cpu.idle#cgroup v2cat /sys/fs/cgroup/kubepods.slice/cpu.idle
*开启 Overlap 后离线任务会影响在线业务吗？
*Overlap 通过 CPU Idle 保障在线业务优先，katalyst-agent 会将 reclaimed_cores Pod 的cpu.idle 设置为 1，表示降低此类 Pod 的调度优先级：
*当 shared_cores Pod 需要 CPU 时，reclaimed_cores Pod 会在毫秒级延迟内让出 CPU 资源。
*当 shared_cores Pod 空闲时，reclaimed_cores Pod 复用这部分 CPU 资源，同时仍可配合压力驱逐策略进一步保护在线业务。
开启 Overlap 后离线任务会影响在线业务吗？
Overlap 通过 CPU Idle 保障在线业务优先，katalyst-agent 会将 reclaimed_cores Pod 的cpu.idle 设置为 1，表示降低此类 Pod 的调度优先级：
- 当 shared_cores Pod 需要 CPU 时，reclaimed_cores Pod 会在毫秒级延迟内让出 CPU 资源。
- 当 shared_cores Pod 空闲时，reclaimed_cores Pod 复用这部分 CPU 资源，同时仍可配合压力驱逐策略进一步保护在线业务。
*开启 CPU Idle 后能否使用 Pod 原地更新（In-Place Pod Resize）能力？
*不建议同时使用，原因如下：
*kubelet 的 cgroupDriver 为 cgroupfs 时，In-Place Pod Resize 更新 Pod 的cpu.weight/cpu.shares会失败。
*kubelet 的 cgroupDriver 为 systemd 且 systemd 版本小于 252 时，In-Place Pod Resize 更新 Pod 的cpu.weight/cpu.shares会失败。
*kubelet 的 cgroupDriver 为 systemd 且 systemd 版本大于等于 252 时，In-Place Pod Resize 更新 Pod 的cpu.weight/cpu.shares会导致 Pod 的 CPU Idle 短暂失效，影响在线应用调度优先级。
开启 CPU Idle 后能否使用 Pod 原地更新（In-Place Pod Resize）能力？
不建议同时使用，原因如下：
- kubelet 的 cgroupDriver 为 cgroupfs 时，In-Place Pod Resize 更新 Pod 的cpu.weight/cpu.shares会失败。
- kubelet 的 cgroupDriver 为 systemd 且 systemd 版本小于 252 时，In-Place Pod Resize 更新 Pod 的cpu.weight/cpu.shares会失败。
- kubelet 的 cgroupDriver 为 systemd 且 systemd 版本大于等于 252 时，In-Place Pod Resize 更新 Pod 的cpu.weight/cpu.shares会导致 Pod 的 CPU Idle 短暂失效，影响在线应用调度优先级。
最近更新时间：2026.10.19 11:29:11
这个页面对您有帮助吗？
有用
有用
无用
无用