Kubernetes CPU 限流：响应时间的隐形杀手

如今，大多数在 Kubernetes 上运行任务关键型应用的企业组织都在多租户环境中运行。这类环境通过设置资源限额来调控租户工作负载的消耗，或用于成本分摊。一些开发人员会选择为其应用基准测试设置 CPU 或 GPU 限制。

这种设计的意外后果是 CPU 限流，即无意中降低了物理 CPU 内核上的任务调度速度，通常会导致应用响应时间意外延长。通过示例说明：

上图中，某容器的 CPU 使用率仅为 25%，这使其成为自然的缩容候选对象：

但当我们实施缩容后（容器 CPU 使用率升至 50%，仍属合理范围），响应时间却增至四倍。

这到底是怎么回事？当您对容器设置 CPU 限制时，就会发生 CPU 限流，这可能会反过来减慢应用响应时间，并引发限流问题。即使底层节点资源充足，配置不当仍会导致容器工作负载被限流。此外，限流对性能的影响会因底层物理处理器（Intel、AMD 和 NVIDIA）的不同而有所差异。高响应时间与高 CPU 限流周期直接相关，而这正是 Kubernetes 的设计特性。

具体而言，假设设置 200ms CPU 限额，该限制在底层 Linux 系统中转换为组配额。由于默认强制执行周期仅为 100ms，容器单次仅能使用 20ms 的 CPU（称为 CPU 时间片)。如果任务执行时间超过 20ms，则会触发限流，导致任务完成时间延长四倍。

根据这种行为，应用性能将因限流导致的响应时间增加而受到影响，迫使运维人员展开故障排查。

如果运行的是小型部署，则可以手动排查限流问题。

首先，您可以使用 kubectl 等工具定位受影响的 Pod。接下来，检查 Pod 的资源请求和限制，确保设置得当。检查容器内正在运行的任何可能导致限流的资源密集型进程，并分析 CPU 利用率和限制。

如果 CPU 限流问题持续存在，请考虑水平 Pod 自动扩缩容，将工作负载分配到更多的 Pod，或调整集群节点资源。需持续监控并优化资源参数，以提升性能并预防限流复发。

对于大规模部署，随着 Pod 数量增加，这种方法不太可能扩展或持久。

由于响应时间与 CPU 限流存在直接关联，该指标已成为核心应用性能度量维度。这对企业来说是个好消息，因为您可以直接从 Kubernetes 和 OpenShift 获取这些指标。

要维持低响应时间、避免 CPU 限流并保持高性能，需首先明确，当发生 CPU 限流时，不能仅依赖 CPU 核心利用率判断。您必须综合考量所有影响应用性能的分析指标与资源依赖关系。IBM Turbonomic 已将这些因素纳入其分析平台。

在确定容器调整规模策略时，Turbonomic 会持续分析以下四个维度：

1. CPU 限制
2. CPU 请求
3. 内存限制
4. 内存请求

Turbonomic 可以确定 CPU 限制，从而降低限流风险，并使应用能够不受阻碍地运行。这一切的实现，都得益于平台将 CPU 限流纳入调控维度，从而能够分析并权衡由此产生的各种利弊。引入 CPU 限流维度可确保持续维持低应用响应时间。

此外，Turbonomic 还能生成 Pod 迁移与集群扩缩容策略——众所周知，这是全栈层面的挑战。客户可以查看关键绩效指标 (KPI)，并查询“哪些服务正遭遇限流？”它还可以帮助用户了解每项服务的 CPU 限流历史记录，并洞悉每项服务与应用响应时间的直接关联性，从而获得系统性能的宝贵信息。

在 Kubernetes 环境中，Turbonomic 的主要优点之一是能够快速识别和修复平台策略带来的意外后果，无需用户重新设计多租户平台架构。Turbonomic 不仅可以监控 CPU 限流指标，还可以自动调整 CPU 限制，将限流控制在可管理水平。

IBM Turbonomic 助力实现云支出与性能同步优化。您可以在无需人工干预的情况下，实时不断地自动执行优化操作，以最高效的方式主动为堆栈每一层的应用程序使用计算、内存、存储和网络资源。