共计 3904 个字符，预计需要花费 10 分钟才能阅读完成。
作者：张佐玮（佑祎）
前言
在云原生时代下，利用工作负载都是以容器的模式部署在宿主机，共享各类物理资源。随着宿主机硬件性能的加强，单节点的容器部署密度进一步晋升，由此带来的过程间 CPU 争用，跨 NUMA 访存等问题也更加重大，影响了利用性能体现。如何调配和治理宿主机的 CPU 资源，保障利用能够取得最优的服务质量，是掂量容器服务技术能力的关键因素。
节点侧容器 CPU 资源管理
Kubelet 的 CPU 调配策略
Kubernetes 为容器资源管理提供了 request（申请）和 limit（束缚）的语义形容，当容器指定了 request 时，调度器会利用该信息决定 Pod 应该被调配到哪个节点上；当容器指定了 limit 时，Kubelet 会确保容器在运行时不会超用。
CPU 是一种典型的分时复用型资源，内核调度器会将 CPU 分为多个工夫片，轮流为各过程调配肯定的运行工夫。Kubelet 默认的 CPU 管理策略会通过 Linux 内核的 CFS 带宽控制器（CFS Bandwidth Controller）来管制容器 CPU 资源的应用下限。在多核节点下，过程在运行过程中常常会被迁徙到其不同的外围，思考到有些利用的性能对 CPU 上下文切换比拟敏感，Kubelet 还提供了 static 策略，容许 Guaranteed 类型 Pod 独占 CPU 外围。
内核 CPU 资源调度
内核 CFS 调度是通过 cfs_period 和 cfs_quota 两个参数来治理容器 CPU 工夫片耗费的，cfs_period 个别为固定值 100 ms，cfs_quota 对应容器的 CPU Limit。例如对于一个 CPU Limit = 2 的容器，其 cfs_quota 会被设置为 200ms，示意该容器在每 100ms 的工夫周期内最多应用 200ms 的 CPU 工夫片，即 2 个 CPU 外围。当其 CPU 使用量超出预设的 limit 值时，容器中的过程会受内核调度束缚而被限流。仔细的利用管理员往往会在集群 Pod 监控中的 CPU Throttle Rate 指标察看到这一特色。
容器 CPU 性能问题现状
让利用管理员经常感到纳闷的是，为什么容器的资源利用率并不高，但却频繁呈现利用性能降落的问题？从 CPU 资源的角度来剖析，问题通常来自于以下两方面：一是内核在依据 CPU Limit 限度容器资源耗费时产生的 CPU Throttle 问题；二是受 CPU 拓扑构造的影响，局部利用对过程在 CPU 间的上下文切换比拟敏感，尤其是在产生跨 NUMA 拜访时的状况。
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 拓扑构造的影响
在 NUMA 架构下，节点中的 CPU 和内存会被切分成了两局部甚至更多（例如图中 Socket0，Socket1），CPU 被容许以不同的速度拜访内存的不同局部，当 CPU 跨 Socket 拜访另一端内存时，其访存时延绝对更高。自觉地在节点为容器调配物理资源可能会升高提早敏感利用的性能，因而咱们须要防止将 CPU 扩散绑定到多个 Socket 上，晋升内存拜访时的本地性。如下图所示，同样是为两个容器调配 CPU、内存资源，显然场景 B 中的调配策略更为正当。
Kubelet 提供的 CPU 管理策略“static policy”、以及拓扑管理策略“single-numa-node”，会将容器与 CPU 绑定，能够晋升利用负载与 CPU Cache，以及 NUMA 之间的亲和性，但这是否肯定可能解决所有因 CPU 带来的性能问题呢，咱们能够看上面的例子。
某 CPU Limit = 2 的容器，其利用在 100ms 工夫点收到了 4 个申请须要解决，在 Kubelet 提供的 static 模式下，容器会被固定在 CPU0 和 CPU1 两个外围，各线程只能排队运行，而在 Default 模式下，容器取得了更多的 CPU 弹性，收到申请后各线程能够立刻解决。能够看出，绑核策略并不是“银弹”，Default 模式也有适宜本人的利用场景。
事实上，CPU 绑核解决的是过程在不同 Core，特地是不同 NUMA 间上下文切换带来的性能问题，但解决的同时也损失了资源弹性。在这种状况下线程会在各 CPU 排队运行，尽管 CPU Throttle 指标可能有所升高，但利用本身的性能问题并没有齐全解决。
应用 CPU Burst 机制晋升容器性能
往期文章咱们介绍了阿里云奉献的 CPU Burst 内核个性，能够无效解决 CPU Throttle 的问题，当容器实在 CPU 资源应用小于 cfs_quota 时，内核会将多余的 CPU 工夫“存入”到 cfs_burst 中；当容器有突发的 CPU 资源需要，须要应用超出 cfs_quota 的资源时，内核的 CFS 带宽控制器（CFS Bandwidth Controller，简称 BWC）会容许其生产其之前存到 cfs_burst 的工夫片。
CPU Burst 机制能够无效解决提早敏感性利用的 RT 长尾问题，晋升容器性能体现，目前阿里云容器服务 ACK 曾经实现了对 CPU Burst 机制的全面反对。对于尚未反对 CPU Burst 策略的内核版本，ACK 也会通过相似的原理，监测容器 CPU Throttle 状态，并动静调节容器的 CPU Limit，实现与内核 CPU Burst 策略相似的成果。
咱们应用 Apache HTTP Server 作为提早敏感型在线利用，通过模仿申请流量，评估 CPU Burst 能力对响应工夫（RT）的晋升成果。以下数据别离展现了 CPU Burst 策略开启前后的体现状况：
比照以上数据可得悉：
- 在开启 CPU Burst 能力后，利用的 RT 指标的 p99 分位值得到了显著的优化。
- 比照 CPU Throttled 及利用率指标，能够看到开启 CPU Burst 能力后，CPU Throttled 状况失去了打消，同时 Pod 整体利用率根本放弃不变。
应用拓扑感知调度晋升容器性能
尽管 Kubelet 提供了单机的资源管理策略（static policy，single-numa-node），能够局部解决利用性能体现受 CPU 缓存、NUMA 亲和性影响的问题，但该策略尚有以下不足之处：
- static policy 只反对 QoS 为 Guaranteed 的 Pod，其余 QoS 类型的 Pod 无奈应用
- 策略对节点内所有 Pod 全副失效，而咱们通过后面的剖析晓得，CPU 绑核并不是”银弹“
- 核心调度并不感知节点理论的 CPU 分配情况，无奈在集群范畴内抉择到最优组合
阿里云容器服务 ACK 基于 Scheduling framework 实现了拓扑感知调度以及灵便的绑核策略，针对 CPU 敏感型的工作负载能够提供更好的性能。ACK 拓扑感知调度能够适配所有 QoS 类型，并反对在 Pod 维度按需开启，同时能够在全集群范畴内抉择节点和 CPU 拓扑的最优组合。
通过对 Nginx 服务进行的评测，咱们发现在 Intel（104 核）、AMD（256 核）的物理机上，应用 CPU 拓扑感知调度可能将利用性能晋升 22%~43%。
总结
CPU Burst、拓扑感知调度是阿里云容器服务 ACK 晋升利用性能的两大利器，它们解决了不同场景下的 CPU 资源管理，能够独特应用。
CPU Burst 解决了内核 BWC 调度时针对 CPU Limit 的限流问题，能够无效晋升延时敏感型工作的性能体现。但 CPU Burst 实质并不是将资源无中生有地变进去，若容器 CPU 利用率曾经很高（例如大于 50%），CPU Burst 能起到的优化成果将会受限，此时应该通过 HPA 或 VPA 等伎俩对利用进行扩容。
拓扑感知调度升高了工作负载 CPU 上下文切换的开销，特地是在 NUMA 架构下，能够晋升 CPU 密集型，访存密集型利用的服务质量。不过正如前文中提到的，CPU 绑核并不是“银弹”，实际效果取决于利用类型。此外，若同一节点内大量 Burstable 类型 Pod 同时开启了拓扑感知调度，CPU 绑核可能会产生重叠，在个别场景下反而会加剧利用间的烦扰。因而，拓扑感知调度更适宜针对性的开启。
点击此处，即可查看阿里云 ACK 反对 CPU Burst、拓扑感知调度的具体介绍！
