简介：让人讨厌的CPU限流影响容器运行|cpuburst技术可以避免cpu限流出现的密度

简介：让人讨厌的CPU限流影响容器运行，有时人们不得不牺牲容器部署密度来避免CPU限流出现。本文介绍的CPUBurst技术可以帮助您既能保证容器运行服务质量，又不降低容器部署密度。文章分为上下两篇，该文为上篇，下篇将剖析使用CPUBurst和其他避免限流手段的区别，以及如何配置CPUBurst功能以达到最佳效果。

在K8S容器调度中，容器的CPU资源上限是由CPUlimits参数指定。设置CPU资源上限可以限制个别容器消耗过多的CPU运行时间，并确保其他容器拿到足够的CPU资源。 CPUlimits限制在Linux内核中是用CPUBandwidthController实现的，它通过CPU限流限制cgroup的资源消耗。所以当一个容器中的进程使用了超过CPUlimits的资源的时候，这些进程就会被CPU限流，他们使用的CPU时间就会受到限制，进程中一些关键的延迟指标就会变差。
面对这种情况，我们应该怎么办呢？一般情况下，我们会结合这个容器日常峰值的CPU利用率并乘以一个相对安全的系数来设置这个容器的CPUlimits ，这样我们既可以避免容器因为限流而导致的服务质量变差，同时也可以兼顾CPU资源的利用。举个简单的例子，我们有一个容器，他日常峰值的CPU使用率在250%左右，那么我们就把容器CPUlimits设置到400%来保证容器服务质量，此时容器的CPU利用率是62.5%（250%/400%）。
然而生活真的那么美好么？显然不是！CPU限流的出现比预期频繁了很多。怎么办？似乎看上去我们只能继续调大CPUlimits来解决这个问题。很多时候，当容器的CPUlimits被放大5~10倍的时候，这个容器的服务质量才得到了比较好的保障，相应的这时容器的总CPU利用率只有10%~20% 。所以为了应对可能的容器CPU使用高峰，容器的部署密度必须大大降低。
历史上人们在CPUBandwidthController中修复了一些BUG导致的CPU限流问题，我们发现当前非预期限流是由于100ms级别CPU突发使用引起，并且提出CPUBurst技术允许一定的CPU突发使用，避免平均CPU利用率低于限制时的CPU限流。在云计算场景中， CPUBurst技术的价值有：不提高CPU配置的前提下改善CPU资源服务质量；允许资源所有者不牺牲资源服务质量降低CPU资源配置，提升CPU资源利用率；降低资源成本（TCO,TotalCostofOwnership）。你看到的CPU利用率不是全部真相
秒级CPU利用率不能反映BandwidthController工作的100ms级别CPU使用情况，是导致非预期CPU限流出现的原因。
【简介：让人讨厌的CPU限流影响容器运行|cpuburst技术可以避免cpu限流出现的密度】BandwidthController适用于CFS任务，用period和quota管理cgroup的CPU时间消耗。若cgroup的period是100msquota是50ms ， cgroup的进程每100ms周期内最多使用50msCPU时间。当100ms周期的CPU使用超过50ms时进程会被限流， cgroup的CPU使用被限制到50% 。
CPU利用率是一段时间内CPU使用的平均，以较粗的粒度统计CPU的使用需求， CPU利用率趋向稳定；当观察的粒度变细， CPU使用的突发特征更明显。以1s粒度和100ms粒度同时观测容器负载运行，当观测粒度是1s时CPU利用率的秒级平均在250%左右，而在BandwidthController工作的100ms级别观测CPU利用率的峰值已经突破400% 。

根据秒级观察到的CPU利用率250%设置容器quota和period分别为400ms和100ms ，容器进程的细粒度突发被BandwidthController限流，容器进程的CPU使用受到影响。如何改善
我们用CPUBurst技术来满足这种细粒度CPU突发需求，在传统的CPUBandwidthControllerquota和period基础上引入burst的概念。当容器的CPU使用低于quota时，可用于突发的burst资源累积下来；当容器的CPU使用超过quota ，允许使用累积的burst资源。最终达到的效果是将容器更长时间的平均CPU消耗限制在quota范围内，允许短时间内的CPU使用超过其quota 。