腾讯方睿：详解Kubernetes资源拓扑感知调度

正文

请到「今天看啥」查看全文

在吵闹的邻居问题下，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能从外部系统采集节点扩展信息（可选）。

请到「今天看啥」查看全文