CPU|让容器跑得更快：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 技术的价值有：