鲲鹏Kubernetes平台如何使用CPU Manager + Topology Manager达成最佳绑核实例

引言：在集群上使用Kubernetes容器编排引擎部署业务时，我们常用Request & Limits来对Pods或者Namespaces的CPU/内存资源进行限制。
对于特定的有时延敏感、CPU独占、高性能等需求的业务来说，单纯的资源限制还不能达成目标，需要进行资源独占的分配编排及隔离，Kubernetes平台针对独占隔离模式（Exclusive）推出了CPU Manager（v1.12 beta）进行Pod级别的绑核及隔离自动编排；
在鲲鹏处理器的多NUMA架构上来说，不带约束的单纯绑核极有可能会带来跨NUMA的CPU资源分配，在访存模型上是不友好的，Kubernetes平台针对CPU隔离、内存及设备局部性的优化诉求推出了Topology Manager（v1.16 alpha)。
本文针对鲲鹏Kubernetes平台，结合处理器特点介绍如何达成最佳绑核实例。

技术点介绍

简单介绍一下CPU Manager与Topology Manager。

CPU Manager

集群中一个计算节点可以运行很多个Pods，其中一些Pods可能会运行高CPU负载的业务。在这样的情况下，这些Pods很可能会在当前节点上竞争CPU资源，当一个Pod原先所在的CPU资源被占用时，工作负载将会自动切换到另外的空闲CPU上去。
这样的调度策略对于那些上下文切换敏感的负载来说，会带来一些性能的损失。
CPU Manager的设计目的就是为了针对这部分的工作负载进行CPU资源独占隔离，提供更好的性能，理论上来说具备以下几种特点的工作负载都可以使用：

1. 对CPU节流影响敏感；

2. 对上下文切换敏感；

3. 对处理器Cache Miss敏感；

4. 最好能独享一个处理器的微架构资源（I-Cache & D-Cache）；

5. 对跨Socket内存访问敏感；

6. 对同一个物理核的超线程敏感或有特定需求。

Topology Manager

在并行计算等场景，有CPU和硬件加速器的组合的使用场景，也存在多NUMA处理器架构的特点；为了获得最佳性能，需要进行CPU隔离、内存和设备局部性优化。Topology Manager提供了一个Hint Provider的接口，以发送和接收拓扑信息。
理论上来说，可以通过Topology Manager来进行CPU与设备管理器之间的任何资源分配决策，不仅仅局限于NUMA级绑核隔离，还包含了硬件加速器（GPU/NPU/网卡等）设备的资源亲和性决策。

最佳绑核实践

1. 确认Kubernetes版本和实际绑核需求
   建议Kubernetes Version >= 1.16，CPU/Topology Manager均可用；Kubernetes Version >= 1.12，仅能使用CPU Manager；
   另外绑核将会进行CPU独占，请事先确定是否一定需要进行独占。

2. 修改Kubelet配置文件（集群计算节点均需要修改配置）

   $ vim /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf
   # Note: This dropin only works with kubeadm and kubelet v1.11+
   [Service]
   Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
   Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
   # This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
   EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
   # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
   # the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
   EnvironmentFile=-/etc/sysconfig/kubelet
   ### 修改点一：添加如下两行
   ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpuset/system.slice/kubelet.service
   ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/hugetlb/system.slice/kubelet.service
   ### 修改点一结束
   ExecStart=
   ### 修改点二：修改如下这行，添加CPU Manager和Topology Manager的配置开关
   ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
   ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS --kube-reserved=cpu=2,memory=250Mi --cpu-manager-policy=static --feature-gates=CPUManager=true --topology-manager-policy=single-numa-node
   ### 修改点二结束

3. 加载配置项，重启kubelet服务

   $ systemctl daemon-reload && systemctl restart kubelet

4. 编写业务Yaml文件，显式标注资源诉求，并配置为Guaranteed Pod

   apiVersion: v1
   kind: Pod
   metadata:
   name: static-ip
   namespace: ls1
   annotations:
    ovn.kubernetes.io/ip_address: 10.16.0.35
    ovn.kubernetes.io/mac_address: 00:00:00:53:6B:B6
   spec:
   containers:
   - name: static-ip
    image: nginx:alpine
    # Resource资源这边注意要同时配置CPU和Memory
    resources:
      requests:
        cpu: 2
        memory: "256M"
      limits:
        cpu: 2
        memory: "256M"

绑核效果：（左侧为有拓扑管理，右侧为无拓扑管理，关注是否有跨NUMA）

后记

当然CPU Manager与Topology Manager还有其他许多配置组合和使用方法，本文仅以static & single-numa-node模式达成不跨NUMA的CPU绑定效果，达成在鲲鹏集群上的最优绑核模式，其他的模式如用户感兴趣的话，可以阅读参考资料中的链接进行进一步了解。

参考资料：
[1] Kubernetes拓扑管理策略
[2] Kubernetes CPU管理策略