宿主机应用QoS管理

简介

在实际生产环境中，除了已经运行在K8s上的应用，往往还会存在一些非容器化的带外引用，以裸进程的方式直接部署在在宿住机上。Koordinator目前已经支持了 节点资源预留 机制，使得koord-scheduler在调度过程中可以将这部分资源考虑进来。事实上，除了资源调度方面的约束，这些应用同样有不同的QoS属性，例如LS或BE。 因此，在单机QoS管理方面，koordlet也需要支持为这些宿主机d带外应用设置不同的QoS参数。例如对于一个时延敏感型的带外应用，koordlet需要将其标记为 高优先级并采取同类型的QoS策略，以避免BE类型的应用对其产生干扰。

由于大多数的QoS策略都是基于cgroup机制来实施的，因此在使用该功能前，koordlet要求这部分带外应用的进程必须已经由相应的cgroup分组进行了托管。

Koordinator目前已经支持了一系列QoS等级和管理策略，其中针对宿主机带外应用的支持情况如下：

• LS (Latency Sensitive)
  • CPU QoS(Group Identity): 应用进程必须已经运行在cgroup的cpu子系统中，koordlet根据CPU QoS的配置resource-qos-config为其设置Group Identity参数。
  • CPUSet Allocation: : 应用进程必须已经运行在cgroup的cpu子系统中，koordlet将为其设置cpu share pool中的所有CPU核心。
• BE (Best-effort)
  • CPU QoS(Group Identity): 应用进程必须已经运行在cgroup的cpu子系统中，koordlet根据CPU QoS的配置为其设置Group Identity参数。

使用限制

请确保Koordinator已正确安装在你的集群中。若未安装，请参考安装文档。

带外应用的进程必须已经运行在对应的cgroup分组内，请参考内核文档使用cgroup来管理应用进程。

操作步骤

1. 以nginx应用为例，将其以带外应用的形式在宿主机启动，并将进程加入到cgroup子系统cpu和cpuset分组 host-latency-sensitive/nginx/ 中。 需要注意的是，cpuset子系统中的cpuset.cpus and cpuset.mems 参数必须先完成初始化，可使用cgroup根组中的内容完成配置，示例如下：

1. # init cgroup dir on cgroup v1
2. $ mkdir -p /sys/fs/cgroup/cpuset/host-latency-sensitive/nginx/
3. $ mkdir -p /sys/fs/cgroup/cpu/host-latency-sensitive/nginx/
4. $ cat /sys/fs/cgroup/cpuset/cpuset.cpus > /sys/fs/cgroup/cpuset/host-latency-sensitive/cpuset.cpus
5. $ cat /sys/fs/cgroup/cpuset/cpuset.cpus > /sys/fs/cgroup/cpuset/host-latency-sensitive/nginx/cpuset.cpus
6. $ cat /sys/fs/cgroup/cpuset/cpuset.mems > /sys/fs/cgroup/cpuset/host-latency-sensitive/cpuset.mems
7. $ cat /sys/fs/cgroup/cpuset/cpuset.mems > /sys/fs/cgroup/cpuset/host-latency-sensitive/nginx/cpuset.mems

9. # bind application to corresponding cgroups
10. $ echo PID > /sys/fs/cgroup/cpuset/host-latency-sensitive/nginx/tasks
11. $ echo PID > /sys/fs/cgroup/cpu/host-latency-sensitive/nginx/tasks

1. 使用以下ConfigMap，创建configmap.yaml文件。

1. apiVersion: v1
2. data:
3. host-application-config: |
4. {
5. "applications": [
6. {
7. "name": "nginx",
8. "qos": "LS",
9. "cgroupPath": {
10. "base": "CgroupRoot",
11. "parentDir": "host-latency-sensitive/",
12. "relativePath": "nginx/"
13. }
14. }
15. ]
16. }
17. resource-qos-config: |
18. {
19. "clusterStrategy": {
20. "lsClass": {
21. "cpuQOS": {
22. "enable": true,
23. "groupIdentity": 2
24. }
25. },
26. "beClass": {
27. "cpuQOS": {
28. "enable": true,
29. "groupIdentity": -1
30. }
31. }
32. }
33. }
34. kind: ConfigMap
35. metadata:
36. name: slo-controller-config
37. namespace: koordinator-system

1. 查看安装的命名空间下是否存在ConfigMap，以命名空间koordinator-system和ConfigMap名字slo-controller-config为例，具体以实际安装配置为准。

   • 若存在ConfigMap slo-controller-config，请使用PATCH方式进行更新，避免干扰ConfigMap中其他配置项。

     1. kubectl patch cm -n koordinator-system slo-controller-config --patch-file configmap.yaml
     

   • 若不存在ConfigMap slo-controller-config，请执行以下命令进行创建ConfigMap。

     1. kubectl apply -f configmap.yaml
     

2. 检查带外应用nginx对应的cgroup配置，其中CPU QoS策略的cgroup配置文件cpu.bvt_warp_ns应与QoS等级LS的配置一致，cpuset核心应与节点的share pool一致， 示例如下：

1. $ cat /sys/fs/cgroup/cpu/host-latency-sensitive/nginx/cpu.bvt_warps_ns
2. $ 2

4. $ cat /sys/fs/cgroup/cpuset/host-latency-sensitive/nginx/cpuset.cpus
5. $ 1-5,8-23,32-47,50-51,53,56-71,80-103

7. $ kubectl get noderesourcetopology ${your-node-id} -o yaml | grep node.koordinator.sh/cpu-shared-pools
8. node.koordinator.sh/cpu-shared-pools: '[{"socket":0,"node":0,"cpuset":"1-5,8-23,53,56-71"},{"socket":1,"node":1,"cpuset":"32-47,50-51,80-103"}]'