Kubernetes v1.36：Kubernetes 的 PSI 指标晋升为 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 和内核级收集的影响：

1. 内核 PSI 开启 / Kubelet 功能关闭，对比 内核 PSI 开启 / Kubelet 功能开启（Kubelet 开销）
2. 内核 PSI 关闭 / Kubelet 功能开启，对比 内核 PSI 开启 / Kubelet 功能开启（内核开销）

场景 1：Kubelet 开销

首先，我们查看了 4 核机器上的 kubelet 使用情况（案例 1）。对于这些机器，Linux 内核默认已在两个集群上跟踪压力（psi=1），但我们切换 KubeletPSI 功能门控，以观察 Kubelet 主动查询并暴露这些指标是否会影响资源使用。图中同步出现的突发在幅度和频率上几乎完全一致，确认 Kubelet 的收集逻辑非常轻量，并可无缝融入标准 housekeeping 周期。该功能不会影响既有资源使用，保持在通常的 0.1 核或节点总容量 2.5% 范围内，因此适合生产规模部署。

接下来，我们在同一次运行中评估了系统开销。如下图所示，启用 Kubelet PSI 的集群（红色）的 System CPU 使用率曲线与禁用 Kubelet PSI 的集群（蓝色）遵循相同模式，仅相对基线出现轻微的预期增长。这表明，一旦操作系统开始跟踪 PSI，在约 2.5 核的水平下，Kubernetes 读取这些 cgroup 指标这一行为对性能的影响可以忽略不计。

场景 2：内核开销

转换视角后，我们同样在 4 核机器上评估了在 Linux 内核中启用 PSI 的底层开销。通过比较以 psi=1（COS 默认）启动的集群和以 psi=0 启动的集群，我们隔离出操作系统级记录工作的确切成本。即便在 80 个 Pod 密度下承受重 I/O 和 CPU 负载，启用内核与禁用内核的集群之间 System CPU 差值仍持续保持在 0.037 核到 0.125 核之间，即节点总容量的 0.925% 到 3.125%。曾出现一次升至 0.225 核、即 5.6% 的峰值，但在数秒内回落。这确认了内核内部跟踪在负载下具有很高效率。

图 4 放大展示了 kubelet 进程本身，它是这些指标的主要收集器。结果显示，即使 kubelet 执行周期性扫描以从 cgroup 层级聚合数据，其 CPU 使用率仍然非常低，峰值可互换出现，且没有任何峰值超过 0.25 核或总容量 6.25% 并持续超过 1 秒。

从 beta（1.34）到 stable（1.36）的改进

• 面向 GA 的更智能指标输出：我们改进了 Kubelet 处理底层操作系统 PSI 支持的方式。此前，如果 Kubernetes 中启用了该功能，但底层 Linux 内核不支持 PSI（psi=0），Kubelet 会输出具有误导性的零值指标。这些指标若被当作真实指标而非缺失值读取，可能触发误报。在 v1.36 中，Kubelet 现在会在报告前通过 cgroup 配置检测操作系统级 PSI 支持。这确保压力指标只在节点实际支持时才会被收集和输出，从而为监控和告警系统提供更干净的数据。

开始使用

要在你的 Kubernetes 集群中使用 PSI 指标，你的节点必须满足以下要求：

1. 确保你的节点运行 Linux 内核 4.20 或更高版本，并使用 cgroup v2。
2. 确保 PSI 已在操作系统层面启用（你的内核必须以 CONFIG_PSI=y 编译，且启动时不得带有 psi=0 参数）。

自 v1.36 起，Kubelet PSI 指标已正式普遍可用，你无需选择加入任何功能门控。

一旦满足操作系统前置条件，你就可以使用与 Prometheus 兼容的监控方案开始抓取 /metrics/cadvisor 端点，或查询 Summary API，以收集并可视化新的 PSI 指标。请注意，PSI 是 Linux 内核功能，因此这些指标在 Windows 节点上不可用。你的集群可以同时包含 Linux 和 Windows 节点；在 Windows 节点上，kubelet 会直接省略 PSI 指标。

如果你的集群运行的 Kubernetes 版本足够新，并且你是具有特权的节点管理员，也可以通过控制平面的 API server 代理到 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}'

延伸阅读

如果你想更深入了解这些指标如何计算和暴露，请查看以下资源：

1. 官方 Kernel 文档
2. Kubernetes 文档中的 PSI 解读
3. cAdvisor 指标实现

致谢

PSI 指标支持由 SIG Node 协作开发完成。特别感谢所有贡献者，他们在该功能从 v1.33 的 alpha、v1.34 的 beta 到 v1.36 的 GA 过程中，参与了设计、实现、测试、审查和文档编写。

如需对该功能提供反馈，请加入 Kubernetes Node Special Interest Group，参与公共 Slack 频道（#sig-node）中的讨论，或在 GitHub 上提交 issue。

反馈

如果你有反馈并希望分享使用该功能的经验，请加入讨论：

• SIG Node 社区页面
• Kubernetes Slack 的 #sig-node 频道
• SIG Node 邮件列表

SIG Node 非常希望听到你在生产环境中使用该功能的经验！

• ← 上一篇