Kubernetes是如何解决资源拓扑感知调度的呢

资源竞争与资源感知问题

从CPU的体系结构上来看，现代CPU多采用NUMA架构和方式。

NUMA架构是非对称的，每个NUMA node上会有自己的物理CPU内核，以及每个NUMA node之间也共享L3 Cache。同时，内存也分布在每个NUMA node上的。某些开启了超线程的CPU，一个物理CPU内核在操作系统上会呈现两个逻辑的核。

实际上，CPU内核是分布在NUMA node上，NUMA node内本身就有一些亲和性的元素。

右图中，CPU开始的访问速度是不一样的。

如果程序都跑在同一个NUMA node上，可以更好地去共享一些L3 Cache，L3 Cache的访问速度会很快。如果L3 Cache没有命中，可以到内存中读取数据，访存速度会大大降低。

因此，从CPU体系结构中可以看到，如果采用一些错误的CPU分配方式，可能会导致进程访存速度急剧下降，严重影响应用程序的性能。

在这样的体系结构下，存在云计算中常见的吵闹的邻居问题。当多个容器在节点上共同运行时，由于资源分配的不合理，会对CPU本身的性能造成影响。

从理想的使用方式来看，如果每个进程都使用各自的CPU内核，并且不会跨NUMA node访问，相互之间不会有太多争抢。

从糟糕的使用方式来看，如果两个进程的CPU内核在分配时，可能会没有遵循NUMA的亲和性，会带来很大的性能问题，体现在三个方面：

CPU争抢带来频繁的上下文切换时间；

频繁的进程切换导致CPU高速缓存失败；

跨NUMA访存会带来更严重的性能瓶颈。

Kubernetes中有CPU Manager的功能，CPU Manager可以做一些CPU核心的分配工作。上图是Kubernetes的一些数据呈现。

在Guaranteed和Burstable两种Pod混部测试下，将CPU Manager执行时间做基准，如果是原生Kubernetes的方式在不同测试下，性能有较大波动，最差可能会达到1.8倍左右。

在Stand-Alone Workloads的情况下，做CPU的绑定和完全不做CPU绑定，执行时间差别很大。因为剧烈的CPU争抢以及频繁的上下文切换，会导致约1倍的性能差距。

在吵闹的邻居问题下，Kubernetes是如何解决的呢？

CPU Manager是其中的一个解决方法，它被放在Kubelet中，CPUSet将会被CPU Manager分在Default和Exclusive两个池子中。

Default主要在两种情况下使用。一种是系统守护进程：kube-reserved、system-reserved，另一种是特殊类型的Pod：Burstable、BestEffort、请求非整数CPU的Guaranteed。

Exclusive是完全排他的CPU池，主要在两种情况下使用。一种是Pod：请求整数CPU的Guaranteed，另一种是Topology Manager：满足拓扑管理器定义的要求。

但原生Kubernetes也存在局限性。

调度器不感知节点资源拓扑。

Kubernetes中调度器只负责为Pod选择节点，并不感知节点NUMA拓扑结构，Pod的CPU分配交给Kubelet完成。当节点单NUMA node上没有足够的CPU时，Pod启动失败，控制器重建Pod后会陷入死循环。

CPUSet分配策略过于单一。

Kubernetes中CPU Manager默认为请求整数CPU的Guaranteed Pod分配独占的CPUSet，但实际上Pod想定制自己的CPU分配策略，可能只是想分配到一个NUMA node内，或是固定CPU甚至是不做绑核。

在混部场景下，也存在离线算力感知问题。

当在线与离线任务混部在同一台主机上，在线闲时，离线任务可以充分使用资源，提升主机利用率；在线忙时，离线任务会被在线抢占，等待资源释放。

当离线可用算力受在线干扰动态变化时，调度器仅感知节点静态资源（Kubelet采集）。

如果忙时调度过多的离线任务，会导致剧烈的资源争抢，并且每个离线Pod的性能都会下降。 因此，调度器在调度时，需要动态感知离线实时算力。驱逐器也应当在线严重干扰离线时，驱逐离线Pod，保证节点的算力稳定。

Kuberbnetes精细化调度

在原生Kubernetes不能很好地解决资源竞争与资源感知问题时，亟需对资源进行更加精细化的调度。

如上图，是精细化调度系统的结构。

Cassini-Worker能从节点采集资源拓扑信息并创建NRT对象。

Cassini-Master能从外部系统采集节点扩展信息（可选）。

Scheduler-Plugins能扩展调度器，为Pod进行资源拓扑分配。

扩展调度器是通过Scheduler-Plugins来实现的，可以在几个插入点做一些插件，保证实现标库资源头部感知调度的功能。

在Fitter的插件内，可以过滤节点拓扑资源和选择Zone并分配资源。

在Score的插件内，可以根据Zone个数降序打分。

在Reserver的插件内，可以为待绑定节点预留拓扑资源避免数据不一致。

在PreBind的插件内，可以将拓扑调度结果附加到Pod Annotations中。

在调度算法上，可以从性能和负载均衡两个方面做出考虑，以便更好地选择节点和拓扑。

在性能方面，优先选择Pod能绑定在单NUMA node内的节点。如果找不到该节点，可以优先选择在同一个NUMA Socket内的NUMA node

在负载均衡方面，优先选择空闲资源更多的NUMA node。

容器CPUSet管理

Kubernetes的精细化调度做出一些拓扑感知，而实际落到节点上，为了更好地实现资源分配，我们设计了一个资源分配系统。

首先，节点Kubelet会监听到Pod并准备启动Pod。

随后，节点Kubelet调用容器运行时接口启动容器。

与此同时，节点Cassini-Worker通过List Kubelet的10250端口获得节点上的所有Pod，再从Pod Annotations中获取调度器的拓扑调度结果。

节点Cassini-Worker调用容器运行时接口来更改容器的绑核结果。

关于容器多级资源QoS分配策略，在CPUSet的策略上，可以划分为四种：

Exclusive：它可以独占CPU内核心，其他Pod不可使用，一般是高利用率的容器会采取该策略；

None：不做CPU绑核的策略，可以使用节点的Default CPU共享池；

NUMA：让CPUSet固定到NUMA node上的共享池内；

Immovable：将CPU内核心固定，让其他Pod也可共享。

在CPU内核心选择策略上：

首先，按照调度结果获取NUMA node上需分配的核心数；

随后，从共享池中选择可分配的CPU内核心；

同时，还希望一个Pod尽量不使用在同一个物理核上的逻辑核。

在离线混部场景下的实践

由于离线混部场景中，离线会受到在线的影响，算力是波动的。因此，在离线混部场景下，还会做一些差异化重调度：

当在线负载上升时，离线的算力会被压制。因此，离线的Pod需要及时驱逐，以便刚好满足节点离线算力的要求；

通过改造Descheduler组件，建立通用的可配置的平台通用驱逐框架，支持Metrics驱逐，以及支持动态调整/配置驱逐策略；

建立算力平台通用Metrics；

支持业务自定义Metrics驱逐。

在不同混部场景下，容器CPUSet策略也是不同的。

离线CVM混部的场景中，一台物理机的各个NUMA node上都生产了许多在线的CVM，当在线利用率很低时，需要更好地利用资源。

此时需要采取Exclusive策略：

离线CVM通过内核VMF调度器获取低优的CPU时间片；

离线Pod通过独占CPU内核心的方式，保证互不干扰；

内核VMF调度器保证离线Pod在忙时，可实现核心漂移，充分利用CPU资源。

在容器混部的场景中，在线Pod和离线Pod同时部署在同一台物理机上。

此时需要采取NUMA策略：

离线Pod通过限制Cgroups，获取低优的CPU时间片；

离线Pod绑定整个NUMA node，防止某几个CPU内核心被压制；

离线Pod共享整个NUMA node，充分利用CPU资源。

总结

本文围绕Kubernetes的资源拓扑感知调度的主题展开。从CPU体系结构和吵闹的邻居问题切人，随后阐述了原生Kubernetes的不足和混部场景下的算力感知的局限，最后从采集节点拓扑资源、扩展Kubernetes调度器、多级资源QoS分配策略几个方面给出了相应的解决方案。在策略的优化后，资源得到更合理地利用。

未来，Kubernetes精细化调度将会覆盖更多的场景，例如碎片GPU、网络拓扑架构、电力调度。

审核编辑：刘清