编者按：让人讨厌的 CPU 限流影响容器运行，有时人们不得不牺牲容器部署密度来避免 CPU 限流出现。本文介绍的 CPU Burst 技术可以帮助您既能保证容器运行服务质量，又不降低容器部署密度。文章分为上下两篇，该文为上篇，下篇将剖析使用 CPU Burst 和其他避免限流手段的区别，以及如何配置 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 技术的价值有：
- 不提高 CPU 配置的前提下改善 CPU 资源服务质量；
- 允许资源所有者不牺牲资源服务质量降低CPU资源配置，提升CPU资源利用率；
- 降低资源成本（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 时 CPU 利用率的秒级平均在 250% 左右，而在 Bandwidth Controller 工作的 100ms 级别观测 CPU 利用率的峰值已经突破 400% 。
根据秒级观察到的 CPU 利用率 250% 设置容器 quota 和 period 分别为 400ms 和 100ms ，容器进程的细粒度突发被 Bandwidth Controller 限流，容器进程的 CPU 使用受到影响。
如何改善
我们用 CPU Burst 技术来满足这种细粒度 CPU 突发需求，在传统的 CPU Bandwidth Controller quota 和 period 基础上引入 burst 的概念。当容器的 CPU 使用低于 quota 时，可用于突发的 burst 资源累积下来；当容器的 CPU 使用超过 quota，允许使用累积的 burst 资源。最终达到的效果是将容器更长时间的平均 CPU 消耗限制在 quota 范围内，允许短时间内的 CPU 使用超过其 quota。
如果用 Bandwidth Controller 算法来管理休假，假期管理的周期（period）是一年，一年里假期的额度是 quota ，有了 CPU Burst 技术之后今年修不完的假期可以放到以后来休了。
使用 CPU Burst 之后
在容器场景中使用 CPU Burst 之后，测试容器的服务质量显著提升。观察到 RT 均值下降 68%（从 30+ms 下降到 9.6ms ）；99% RT 下降 94.5%（从 500+ms 下降到 27.37ms ）。
如果容器运行负载是延迟敏感类型，又有配置 quota 引起的 CPU 限流，不妨试试使用 CPU Burst 技术对延迟进行优化。CPU Burst 修改已合入 Linux 5.14，Alibaba Cloud Linux 也已经支持 CPU Burst 技术。
关于作者
常怀鑫（一斋），阿里云内核组工程师，擅长CPU调度领域。
加入龙蜥社群
加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】拉你入群；加入钉钉群：可扫码或搜钉钉群号（33311793）。欢迎开发者/用户加入龙蜥OpenAnolis社区交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！
龙蜥社区_小龙 钉钉群二维码
关于龙蜥社区
龙蜥社区是由企事业单位、高等院校、科研单位、非营利性组织、个人等按照自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于2020年9月，旨在构建一个开源、中立、开放的Linux上游发行版社区及创新平台。
短期目标是开发Anolis OS作为CentOS替代版，重新构建一个兼容国际Linux主流厂商发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。
加入我们，一起打造面向未来的开源操作系统！
