CPU Throttle 问题详解
受内核调度控制周期（cfs_period）影响，容器的 CPU 利用率往往具有一定的欺骗性，下图展示了某容器一段时间的 CPU 使用情况（单位为0.01核），可以看到在 1s 级别的粒度下（图中紫色折线），容器的 CPU 用量较为稳定，平均在 2.5 核左右。根据经验，管理员会将 CPU Limit设置为 4 核。本以为这已经保留了充足的弹性空间，然而若我们将观察粒度放大到 100ms 级别（图中绿色折线），容器的 CPU 用量呈现出了严重的毛刺现象，峰值达到 4 核以上。此时容器会产生频繁的 CPU Throttle，进而导致应用性能下降、RT 抖动，但我们从常用的 CPU 利用率指标中竟然完全无法发现！
毛刺产生的原因通常是由于应用突发性的 CPU 资源需求（如代码逻辑热点、流量突增等），下面我们用一个具体的例子来描述 CPU Throttle 导致应用性能下降的过程。图中展示了一个CPU Limit = 2 的 Web 服务类容器，在收到请求后（req）各线程（Thread）的 CPU 资源分配情况。假设每个请求的处理时间均为 60 ms，可以看到，即使容器在最近整体的 CPU 利用率较低，由于在 100 ms～200 ms 区间内连续处理了4 个请求，将该内核调度周期内的时间片预算（200ms）全部消耗，Thread 2 需要等待下一个周期才能继续将 req 2 处理完成，该请求的响应时延（RT）就会变长。这种情况在应用负载上升时将更容易发生，导致其 RT 的长尾情况将会变得更为严重。
为了避免 CPU Throttle 的问题，我们只能将容器的 CPU Limit 值调大。然而，若想彻底解决 CPU Throttle，通常需要将 CPU Limit 调大两三倍，有时甚至五到十倍，问题才会得到明显缓解。而为了降低 CPU Limit 超卖过多的风险，还需降低容器的部署密度，进而导致整体资源成本上升。
调研 CPU Burst 方案
什么是 CPU Burst：CPU Burst（CPU 突发）是指在计算机处理器空闲时，允许进程或线程在一段短时间内使用超过其平均 CPU 使用量的额外 CPU 时间。在 CPU 突发期间，进程可以使用比其在限定时间段内被允许的平均 CPU 使用量更多的 CPU 资源，以提高应用程序的响应速度和性能。
方案对比
| koordinator + cpuBurstOnly | koordinator + cfsQuotaBurstOnly | 二开 koordlet 组件 + cfsQuotaBurstOnly | |
|---|---|---|---|
| 依赖 | 操作系统内核 >= 5.14 | ||
| 策略控制 | CRD/configmap/annotation | CRD/configmap/annotation | configmap/annotation |
| 功能&复杂度 | 功能强大且复杂 Koord-Scheduler/Koord-Descheduler/Koord-Manager/Koordlet/Koord-RuntimeProxy | 功能强大且复杂 Koord-Scheduler/Koord-Descheduler/Koord-Manager/Koordlet/Koord-RuntimeProxy | 功能单一简单，支持基于全局 cm 指定哪些 Pod 需要执行策略 Koordlet |
本项目的由来：二开 koordlet 组件 + cfsQuotaBurstOnly 优化 K8s CPU Throttle 问题
项目架构
StatesInformer
Node Informer：提供本节点 corev1.Node Pod Informer：提供本节点所有 PodMeta 信息， PodMeta 包括 corev1.Pod 和 CgroupDir PLEG：监听 Pod 变化，触发同步 Kubelet：获取 GetAllPods CM Informer：提供全局 CM 指定哪些 Pod ，可以动态调节 cpu.cfs_quota_us
Metric Cache：Prometheus tsdb 存在收集到的指标
MetricCollectors
Node Info：收集 Node CPU 核数等 Node Resource：收集 Node CPU 、MEM 使用情况 Pod Throttled：收集 Pod Throttled 信息，从 cpu.stat 收集
CPU Burst Plugin：发现 Pod Throttled， 动态调整 cpu.cfs_quota_us
快速开始
# 创建 ns
kubectl apply -f manifests/setup/
# 创建 rbac、cm、ds
kubectl apply -f manifests/
默认的 cm 内容如下：
其中 app：apache-demo 是用于匹配 Pod 的 label 的，匹配成功，则 Pod 应用 策略
cpu-burst-config 是默认的策略文件
apiVersion: v1
data:
app: apache-demo
cpu-burst-config: '{"policy": "cfsQuotaBurstOnly", "cpuBurstPercent": 100, "cfsQuotaBurstPercent":
300, "cfsQuotaBurstPeriodSeconds": -1}'
kind: ConfigMap
metadata:
name: cfs-quota-burst-cm
namespace: koordinator-system
创建 demo 测试
apiVersion: v1
kind: Pod
metadata:
name: apache-demo
labels:
app: apache-demo # use label enable or disable CPU Burst.
spec:
containers:
- command:
- httpd
- -D
- FOREGROUND
image: koordinatorsh/apache-2-4-51-for-slo-test:v0.1
imagePullPolicy: Always
name: apache
resources:
limits:
cpu: "4"
memory: 10Gi
requests:
cpu: "4"
memory: 10Gi
nodeName: # $nodeName Set the value to the name of the node that you use.
hostNetwork: False
restartPolicy: Never
schedulerName: default-scheduler
通过 wrk2 进行压力测试
./wrk -H "Accept-Encoding: deflate, gzip" -t 2 -c 12 -d 120 --latency --timeout 2s -R 24 http://$target_ip_address:8010/static/file.1m.test
将 demo 中 label 去掉，再进行测试
apiVersion: v1
kind: Pod
metadata:
name: apache-demo
spec:
containers:
- command:
- httpd
- -D
- FOREGROUND
image: koordinatorsh/apache-2-4-51-for-slo-test:v0.1
imagePullPolicy: Always
name: apache
resources:
limits:
cpu: "4"
memory: 10Gi
requests:
cpu: "4"
memory: 10Gi
nodeName: # $nodeName Set the value to the name of the node that you use.
hostNetwork: False
restartPolicy: Never
schedulerName: default-scheduler
kubectl delete pod apache-demo
kubectl apply -f apache-demo.yaml
测试结果如下：
| 默认 | 开启 cfsQuotaBurstOnly | |
|---|---|---|
| apache RT-p99 | 231.93ms | 99.52ms |
Show me Code
源码地址：https://github.com/clay-wangzhi/cfs-quota-burst
参考链接：
如何合理使用 CPU 管理策略，提升容器性能？：https://developer.aliyun.com/article/872282
Koordinator cpuBurst：https://koordinator.sh/zh-Hans/docs/user-manuals/cpu-burst
我是 Clay，下期见 👋
欢迎订阅我的公众号「SRE运维进阶之路」或关注我的 Github https://github.com/clay-wangzhi/SreGuide 查看最新文章
欢迎加我微信
sre-k8s-ai，与我讨论云原生、稳定性相关内容
