协会地址：上海市长宁区古北路620号图书馆楼309-313室
Kubernetes v1.36：PSI指标在Kubernetes中毕业成为GA
来源: Kubernetes 博客
原文链接:https://kubernetes.io/blog/2026/05/12/kubernetes-v1-36-psi-metrics-ga/
自2018年在Linux内核中首次实现以来，压力失速信息（Pressure Stall Information，PSI）为用户提供了高保真信号，能够在资源饱和演变为故障之前识别出问题。与传统的利用率指标不同，PSI以精心打包的CPU、内存和I/O时间百分比形式，讲述了任务停滞和耗时损失的情况。
随着Kubernetes v1.36的近期发布，整个生态系统的用户拥有了一个稳定、可靠的接口，用于在节点、Pod和容器级别观察资源争用。在本文中，我们将深入探讨证明其生产就绪性的改进和性能测试。
超越利用率：为什么需要PSI？
仅监控CPU或内存使用率可能会产生误导。一个节点可能报告XX%（低于100%）的CPU利用率，而某些任务却因调度延迟而经历严重延迟。PSI通过提供以下内容填补了这一空白：
- 累计总数：处于停滞状态的绝对时间。
- 移动平均值：10秒、60秒和300秒的时间窗口，使运维人员能够区分瞬时峰值和持续的资源紧张。
证明稳定性：大规模性能测试
在遥测特性毕业时，一个常见的担忧是收集和提供指标所需的资源开销。为了解决这个问题，SIG Node在各种机器类型上对高密度工作负载（80+个Pod）进行了广泛的性能验证。
我们的测试主要针对两个场景，以分别隔离Kubelet和内核级别收集的影响：
- 内核PSI开启 / Kubelet特性关闭 vs 内核PSI开启 / Kubelet特性开启（Kubelet开销）
- 内核PSI关闭 / Kubelet特性开启 vs 内核PSI开启 / Kubelet特性开启（内核开销）
场景1：Kubelet开销
首先，我们查看了4核机器上的Kubelet使用情况（场景1）。对于这些机器，Linux内核默认已在两个集群上跟踪压力（psi=1），但我们切换了KubeletPSI特性门控，以观察Kubelet主动查询和暴露这些指标是否会影响资源使用。图中看到的同步突发在幅度和频率上几乎完全相同，这证实了Kubelet的收集逻辑非常轻量，并能无缝融入标准的维护周期。该特性不会影响已有的资源使用，保持在正常的0.1核或节点总容量的2.5% 以内，因此对于生产级部署是安全的。
(Case 1) Kubelet CPU 使用率对比
图 2：Kubelet CPU 使用率对比。
接下来，我们在同一运行中评估了系统开销。如下图所示，系统 CPU 使用率曲线中，启用了 PSI 的 Kubelet（红色）与未启用 PSI 的 Kubelet（蓝色）集群遵循相同的模式，仅比基线略有预期增加。这表明，一旦操作系统开始追踪 PSI（压力失速信息），在约 2.5 个核心 时，Kubernetes 读取这些 cgroup（控制组）指标的操作对性能的影响可以忽略不计。
(Case 1) 系统 CPU 使用率对比
图 1：节点系统 CPU 使用率对比。
场景 2：内核开销
换个角度，我们在同一台 4 核机器上评估了在 Linux 内核中启用 PSI（Pressure Stall Information，压力停滞信息）所带来的底层开销。通过对比以 psi=1（COS 默认值）启动的集群与以 psi=0 启动的集群，我们分离出了操作系统级记账的精确成本。即使在 80 个 Pod 密度的高 I/O 和 CPU 负载下，启用内核与禁用内核的集群之间的系统 CPU 差异始终稳定在 0.037 核 到 0.125 核 之间，即节点总容量的 0.925% – 3.125%。曾有一次峰值达到 0.225 核（即 5.6%），但在几秒内便回落。这证实了内部内核跟踪在负载下具有极高的效率。
(Case 2) 节点系统 CPU 使用率对比
图 3：节点系统 CPU 使用率对比。
图 4 放大了 kubelet 进程本身，它是这些指标的主要收集器。结果显示，即使 kubelet 执行周期性的 扫描 以从 cgroup 层次结构中聚合数据，其 CPU 使用率仍然非常低，只有交替出现的尖峰，且没有任何峰值在超过一秒的时间内超过 0.25 核 或 6.25% 的总容量。
（案例2）Kubelet CPU 使用率对比
图4：Kubelet CPU 使用率对比。
Beta 版（1.34）与稳定版（1.36）之间的改进
- 面向 GA 的更智能指标发送： 我们改进了 Kubelet 处理底层操作系统对 PSI（压力停滞信息，Pressure Stall Information）支持的方式。此前，如果该特性在 Kubernetes 中启用，但底层 Linux 内核不支持 PSI（
psi=0），Kubelet 会发出误导性的零值指标。这些指标在被当作真实指标而非缺失值读取时，可能触发误报。在 v1.36 中，Kubelet 现在会在报告前通过 cgroup 配置检测操作系统级别的 PSI 支持。这确保了压力指标仅在节点实际支持时才会被收集和发送，为监控和告警系统提供更干净的数据。
入门指南
要在你的 Kubernetes 集群中使用 PSI 指标，节点必须满足以下要求：
- 确保节点运行 Linux 内核版本 4.20 或更高版本，并使用 cgroup v2。
- 确保在操作系统层面启用了 PSI（你的内核必须使用
CONFIG_PSI=y编译，且不能使用psi=0参数启动）。
从 v1.36 开始，Kubelet PSI 指标已正式可用（GA），你无需选择加入任何特性门控。
一旦满足操作系统前提条件，你就可以开始使用兼容 Prometheus 的监控方案抓取 /metrics/cadvisor 端点，或查询 Summary API 来收集和可视化新的 PSI 指标。请注意，PSI 是 Linux 内核特性，因此这些指标在 Windows 节点上不可用。你的集群可以同时包含 Linux 和 Windows 节点，在 Windows 节点上，kubelet 将直接省略 PSI 指标。
如果你的集群运行着足够新版本的 Kubernetes，并且你是有特权的节点管理员，你还可以通过控制平面的 API 服务器代理到 kubelet 的 HTTP API，以查看来自 Summary API 的实时压力数据。
注意： 代理到 kubelet 是一项特权操作。授予访问权限存在安全风险，因此请确保在执行这些命令之前拥有适当的管理权限。
CONTAINER_NAME="example-container"
kubectl get --raw "/api/v1/nodes/$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')/proxy/stats/summary" | jq '.pods[].containers[] | select(.name=="'"$CONTAINER_NAME"'") | {name, cpu: .cpu.psi, memory: .memory.psi, io: .io.psi}'
延伸阅读
如果你想深入了解这些指标的计算和暴露方式，请查阅以下资源：
- 官方内核文档
- Kubernetes 文档中的理解 PSI
- cAdvisor 指标实现
致谢
对 PSI 指标的支持是通过 SIG Node 的协作努力而开发的。特别感谢所有贡献者，他们帮助设计、实现、测试、审查和记录了这个功能，从 v1.33 的 alpha 阶段，到 v1.34 的 beta 阶段，再到 v1.36 的 GA（正式发布）阶段。
要提供关于此功能的反馈，请加入 Kubernetes Node 特别兴趣小组，参与公共 Slack 频道（#sig-node）的讨论，或在 GitHub 上提交 issue。
反馈
如果你有反馈并希望分享使用此功能的经验，请加入讨论：
- SIG Node 社区页面
- Kubernetes Slack 的 #sig-node 频道
- SIG Node 邮件列表
SIG Node 非常希望听到你在生产环境中使用此功能的经验！
