让容器跑得更快：CPU Burst 技术实践

简介：让人讨厌的 CPU 限流影响容器运行，有时人们不得不牺牲容器部署密度来避免 CPU 限流出现。我们设计的 CPU Burst 技术既能保证容器运行服务质量，又不降低容器部署密度。CPU Burst 特性已合入 Linux 5.14，Anolis OS 8.2、Alibaba Cloud Linux2、Alibaba Cloud Linux3 也都支持 CPU Burst 特性。

作者：常怀鑫、丁天琛

让人讨厌的 CPU 限流影响容器运行，有时人们不得不牺牲容器部署密度来避免 CPU 限流出现。我们设计的 CPU Burst 技术既能保证容器运行服务质量，又不降低容器部署密度。CPU Burst 特性已合入 Linux 5.14，Anolis OS 8.2、Alibaba Cloud Linux2、Alibaba Cloud Linux3 也都支持 CPU Burst 特性。

在 K8s 容器调度中，容器的 CPU 资源上限是由 CPU limits 参数指定。设置 CPU 资源上限可以限制个别容器消耗过多的 CPU 运行时间，并确保其他容器拿到足够的 CPU 资源。CPU limits 限制在 Linux 内核中是用 CPU Bandwidth Controller 实现的，它通过 CPU 限流限制 cgroup 的资源消耗。所以当一个容器中的进程使用了超过 CPU limits 的资源的时候，这些进程就会被 CPU 限流，他们使用的 CPU 时间就会受到限制，进程中一些关键的延迟指标就会变差。

面对这种情况，我们应该怎么办呢？一般情况下，我们会结合这个容器日常峰值的 CPU 利用率并乘以一个相对安全的系数来设置这个容器的 CPU limits ，这样我们既可以避免容器因为限流而导致的服务质量变差，同时也可以兼顾 CPU 资源的利用。举个简单的例子，我们有一个容器，他日常峰值的 CPU 使用率在 250% 左右，那么我们就把容器 CPU limits 设置到 400% 来保证容器服务质量，此时容器的 CPU 利用率是 62.5%（250%/400%）。

然而生活真的那么美好吗？显然不是！CPU 限流的出现比预期频繁了很多。怎么办？似乎看上去我们只能继续调大 CPU limits 来解决这个问题。很多时候，当容器的 CPU limits 被放大 5~10 倍的时候，这个容器的服务质量才得到了比较好的保障，相应的这时容器的总 CPU 利用率只有 10%~20%。所以为了应对可能的容器 CPU 使用高峰，容器的部署密度必须大大降低。

历史上人们在 CPU Bandwidth Controller 中修复了一些 BUG 导致的 CPU 限流问题，我们发现当前非预期限流是由于 100ms 级别 CPU 突发使用引起，并且提出 CPU Burst 技术允许一定的 CPU 突发使用，避免平均 CPU 利用率低于限制时的 CPU 限流。在云计算场景中，CPU Burst 技术的价值有：

1. 不提高 CPU 配置的前提下改善 CPU 资源服务质量；
2. 允许资源所有者不牺牲资源服务质量降低 CPU 资源配置，提升 CPU 资源利用率；
3. 降低资源成本（TCO，Total Cost of Ownership）。

你看到的 CPU 利用率不是全部真相

秒级 CPU 利用率不能反映 Bandwidth Controller 工作的 100ms 级别 CPU 使用情况，是导致非预期 CPU 限流出现的原因。

Bandwidth Controller 适用于 CFS 任务，用 period 和 quota 管理 cgroup 的 CPU 时间消耗。若 cgroup 的 period 是 100ms quota 是 50ms，cgroup 的进程每 100ms 周期内最多使用 50ms CPU 时间。当 100ms 周期的 CPU 使用超过 50ms 时进程会被限流，cgroup 的 CPU 使用被限制到 50%。

CPU 利用率是一段时间内 CPU 使用的平均，以较粗的粒度统计 CPU 的使用需求，CPU 利用率趋向稳定；当观察的粒度变细，CPU 使用的突发特征更明显。以 1s 粒度和 100ms 粒度同时观测容器负载运行，当观测粒度是 1s 时