Koordinator 最佳实践系列：精细化 CPU 编排

介绍

在云原生环境中，集群提供者常常将不同类型的工作负载部署在同一个集群中，利用不同业务的不同峰值效果，实现资源分时复用，避免资源浪费。然而，不同类型负载之间混合部署常常会导致资源竞争和相互干扰。最为典型的场景便是在线和离线负载的混合部署。当离线较多的占用计算资源时，在线负载的响应时间就会受到影响；当在线长时间较多的占用计算资源时，离线负载的任务完成时间不能得到保证。这种现象属于 Noisy Neighbor 问题。

根据混合部署的程度、资源类型的不同，解决该问题有许多不同的思路。Quota 管理可从整个集群维度限制负载的资源使用量，Koordinator 在这方面提供了多层次弹性 Quota 管理功能[1]。单机维度上看，CPU、内存、磁盘 IO，网络资源都有可能被不同负载共享。Koordinator 在 CPU、内存上已经提供了一些资源隔离和保障的能力，磁盘 IO 和网络资源方面的相关能力正在建设中。

本文主要介绍当不同类型工作负载混合部署在同一个节点上时，Koordinator 如何帮助负载之间（在线和在线、在线和离线）协同地共享 CPU 资源。

问题描述

CPU 资源 Noisy Neighbor 的本质是不同的负载之间无协同地共享 CPU 资源。

1. Kubernetes 默认的资源模型利用 cgroup（cfs quota） 从 CPU 时间使用量上来限制不同负载对于 CPU 资源的访问。这种情况下，一些负载就可能会被操作系统调度器切换所在的 CPU 核。由于不同 CPU 核对不同物理位置的内存访问时间不同，切换大概率会导致更长的内存访问时间，从而影响负载性能。
2. 在 NUMA 架构中，SMT 线程（逻辑核）共享物理核的执行单元和 L2 缓存。当同一个物理核中有多种工作负载时，不同工作负载间就会产生资源争抢，导致负载性能下降。

Kubernetes 在单机侧提供了拓扑管理器和 CPU 管理器来尝试解决上述问题。然而，该功能只有在 Pod 已经调度到机器上之后才会尝试生效。这样就有可能导致 Pod 会被调度到 CPU 资源满足但是 CPU 拓扑不满足负载要求的情况。

解决方案

面向应用的 CPU 编排 QoS 语义

针对上述问题和不足，Koordinator 设计了面向应用的 QoS 语义和 CPU 编排协议，如下图所示。

LS（Latency Sensitive）应用于典型的微服务负载，Koordinator 将其与其它的延迟敏感型负载隔离保障其性能。LSR（Latency Sensitive Reserved）类似于 Kubernetes 的 Guaranteed，在 LS 的基础上增加了应用要求预留绑核的语义。LSE（Latency Sensitive Exclusive）则常见于中间件等对 CPU 特别敏感的应用，Koordinator 除了满足其类似于 LSR 要求绑核的语义外，还确保其所被分配的 CPU 不与任何其它负载共享。

另外，为提高资源利用率，BE 负载可与 LSR 和 LS 共享CPU。为了确保与 BE 共享的延迟敏感型应用不受其干扰，Koordinator 提供了如干扰检测、BE 压制等策略。本文重点不在此，读者可关注后续文章。

丰富的 CPU 编排策略