容器运行时性能退化：containerd-shim CPU时间加速增长问题

概述

在长期运行（例如14天以上）的 Kubernetes 节点上，即使容器化工作负载保持完全静态且稳定，containerd-shim-runc-v2 进程也可能出现 CPU 时间的持续消耗。更关键的是，这种消耗并非恒定，而是呈现出加速增长的趋势，即每天新增的 CPU 时间比前一天更多。此问题对 SRE 的核心实践——保障系统长期稳定性和资源效率——构成了直接挑战，尤其是在对延迟和资源使用敏感的生产环境中。若不干预，可能导致节点 CPU 资源在数周内被逐渐耗尽，最终引发服务性能降级或调度失败。

核心概念

containerd-shim-runc-v2

在 containerd 容器运行时架构中，shim 是一个轻量级进程，作为 containerd 守护进程与实际容器进程（如通过 runc 启动的容器）之间的中介。每个容器都有一个对应的 shim 进程。它的主要职责包括：保持容器的标准输入/输出流、报告容器的退出状态，以及在 containerd 重启时恢复容器管理。runc-v2 指定了 shim 的具体实现。

CPU TIME+ 指标

在 Linux 系统中，CPU TIME+ 或 utime + stime 是一个衡量进程消耗 CPU 资源的累计指标，以“滴答数”或秒为单位。它表示进程在用户态和内核态下实际执行指令所花费的时间。此指标的持续增长本身是正常的，但增长速率（导数） 的变化则能揭示异常。在本案例中，增长速率本身在增加，表明进程的 CPU 效率在随时间恶化。

资源泄漏

传统上，资源泄漏常指内存泄漏（参见 process-resource-leak）。本案例揭示了一种“CPU 时间泄漏”模式：并非内存等物理资源的直接丢失，而是执行单元的低效化。这可能由多种原因引起，例如内部数据结构（如用于跟踪容器状态的映射表）随时间无限膨胀、轮询频率或逻辑路径因某种条件而变得越来越低效，或是如用户推测的，由 goroutine 等并发任务的累积导致。

实践

问题识别与监控

SRE 团队应将 containerd-shim 进程的 CPU 时间增长趋势纳入节点健康监控。基础监控可包括：

周期性采样：使用 top -b -n1、pidstat 或 cAdvisor 等工具，以固定的间隔（如每小时）记录所有 containerd-shim-runc-v2 进程的 CPU 时间。
趋势分析：将采集的数据绘制成图表。正常的稳定工作负载应呈现近乎水平的每日增量线。出现正向加速度（曲线向上弯曲）即为预警信号。
关联分析：同时监控同一进程的内存（RSS）使用趋势，以判断是否存在复合型泄漏（如本案例中同时观察到内存增长）。但需注意，CPU 与内存问题可能具有独立的根因。

问题复现与确认

确认问题是否在您的环境中存在，可以遵循以下步骤（基于原始报告简化）：

选择一个节点，确认其运行的 containerd 版本（例如 v1.7.27 或 v2.0.7）。
确保该节点运行着一批稳定的、长期不重启的 Pod。
在连续 2-3 周内，每日采集所有 shim 进程的 CPU TIME+ 值。
计算每日增量。如果增量序列（如：2.00, 2.04, 2.09…）呈现明确的递增趋势，则问题得到确认。

缓解与规避

在上游修复发布前，有效的缓解措施是有计划地重启节点或容器：

重启节点：这会彻底终止所有 shim 进程并重置其状态。原始报告指出重启后模式会重新开始增长，但至少能将资源消耗拉回基线。可以结合滚动更新或节点健康检查，在 CPU 使用率接近阈值（如 95%）时触发。
重启容器：对于关键服务，可以单独重启对应的 Pod。这同样会重建对应的 shim 进程。

需要注意的是，这种规避措施治标不治本，且会引入额外的运维开销。

SRE 要点

可靠性关联

此问题直接影响 SLO 中的性能指标，特别是请求延迟和吞吐量。当宿主机的 CPU 被“寄生”进程大量占用时，业务容器可获得的 CPU 资源减少，可能导致性能下降或 OOM 事件。它也降低了资源利用率的可预测性，增加了容量规划的难度。

最佳实践与反模式

最佳实践：对长生命周期的集群节点实施“预定重启”或“节点漂移”策略，作为资源退化的主动预防措施。建立容器运行时组件的详细可观测性（参见 node-observability），不仅关注其“是否运行”，更关注其“运行效率是否衰减”。
常见反模式：忽略基础设施进程（如 shim）的 CPU/内存消耗趋势，仅监控业务容器。在长时间运行的节点上完全避免任何形式的重启，认为这会破坏稳定性。本案例恰恰说明，绝对的“不重启”可能引发更隐蔽、更严重的资源退化问题。