fusioncompute中cpu可以设置的qos参数有哪些?_kubernetes 中 Qos 的设计与实现

kubernetes 中的 Qos

QoS(Quality of Service) 即服务质量，QoS 是一种控制机制，它提供了针对不同用户或者不同数据流采用相应不同的优先级，或者是根据应用程序的要求，保证数据流的性能达到一定的水准。kubernetes 中有三种 Qos，分别为：

• 1、Guaranteed：pod 的 requests 与 limits 设定的值相等；
• 2、Burstable：pod requests 小于 limits 的值且不为 0；
• 3、BestEffort：pod 的 requests 与 limits 均为 0；

三者的优先级如下所示，依次递增：

BestEffort -> Burstable -> Guaranteed

不同 Qos 的本质区别

三种 Qos 在调度和底层表现上都不一样：

• 1、在调度时调度器只会根据 request 值进行调度；
• 2、二是当系统 OOM上时对于处理不同 OOMScore 的进程表现不同，OOMScore 是针对 memory 的，当宿主上 memory 不足时系统会优先 kill 掉 OOMScore 值高的进程，可以使用 $ cat /proc/$PID/oom_score 查看进程的 OOMScore。OOMScore 的取值范围为 [-1000, 1000]，Guaranteed pod 的默认值为 -998，Burstable pod 的值为 2~999，BestEffort pod 的值为 1000，也就是说当系统 OOM 时，首先会 kill 掉 BestEffort pod 的进程，若系统依然处于 OOM 状态，然后才会 kill 掉 Burstable pod，最后是 Guaranteed pod；
• 3、三是 cgroup 的配置不同，kubelet 为会三种 Qos 分别创建对应的 QoS level cgroups，Guaranteed Pod Qos 的 cgroup level 会直接创建在 RootCgroup/kubepods 下，Burstable Pod Qos 的创建在 RootCgroup/kubepods/burstable 下，BestEffort Pod Qos 的创建在 RootCgroup/kubepods/BestEffort 下，上文已经说了 root cgroup 可以通过 $ mount | grep cgroup看到，在 cgroup 的每个子系统下都会创建 Qos level cgroups， 此外在对应的 QoS level cgroups 还会为 pod 创建 Pod level cgroups；

启用 Qos 和 Pod level cgroup

在 kubernetes 中为了限制容器资源的使用，避免容器之间争抢资源或者容器影响所在的宿主机，kubelet 组件需要使用 cgroup 限制容器资源的使用量，cgroup 目前支持对进程多种资源的限制，而 kubelet 只支持限制 cpu、memory、pids、hugetlb 几种资源，与此资源有关的几个参数如下所示： --cgroups-per-qos：启用后会为每个 pod 以及 pod 对应的 Qos 创建 cgroups 层级树，默认启用； --cgroup-root：指定 root cgroup，如果不指定默认为“”，若为默认值则直接使用 root cgroup dir，在 node 上执行 $ mount | grep cgroup 可以看到 cgroup 所有子系统的挂载点，这些挂载点就是 root cgroup； --cpu-manager-policy：默认为 "none"，即默认不开启 ,支持使用 "static"，开启后可以支持对 Guaranteed Pod 进行绑核操作，绑核的主要目的是为了高效使用 cpu cache 以及内存节点； --kube-reserved：为 kubernetes 系统组件设置预留资源值，可以设置 cpu、memory、ephemeral-storage； --kube-reserved-cgroup：指定 kube-reserved 的 cgroup dir name，默认为 “/kube-reserved”； --system-reserved：为非 kubernetes 组件设置预留资源值，可以设置 cpu、memory、ephemeral-storage； --system-reserved-cgroup：设置 system-reserved 的 cgroup dir name，默认为 “/system-reserved”； --qos-reserved：Alpha feature，可以通过此参数为高优先级 pod 设置预留资源比例，目前只支持预留 memory，使用前需要开启 QOSReserved feature gate；

当启用了 --cgroups-per-qos 后，kubelet 会为不同 Qos 创建对应的 level cgroups，在 Qos level cgroups 下也会为 pod 创建对应的 pod level cgroups，在 pod level cgroups 下最终会为 container 创建对应的 level cgroups，从 Qos --> pod --> container，层层限制每个 level cgroups 的资源使用量。

配置 cgroup driver

runtime 有两种 cgroup 驱动：一种是 systemd，另外一种是 cgroupfs：

• cgroupfs 比较好理解，比如说要限制内存是多少、要用 CPU share 为多少，其实直接把 pid 写入到对应cgroup task 文件中，然后把对应需要限制的资源也写入相应的 memory cgroup 文件和 CPU 的 cgroup 文件就可以了；
• 另外一个是 systemd 的 cgroup 驱动，这个驱动是因为 systemd 本身可以提供一个 cgroup 管理方式。所以如果用 systemd 做 cgroup 驱动的话，所有的写 cgroup 操作都必须通过 systemd 的接口来完成，不能手动更改 cgroup 的文件；

kubernetes 中默认 kubelet 的 cgroup 驱动就是 cgroupfs，若要使用 systemd，则必须将 kubelet 以及 runtime 都需要配置为 systemd 驱动。

关于 cgroupfs 与 systemd driver 的区别可以参考 k8s 官方文档：container-runtimes/#cgroup-drivers，或者 runc 中的实现 github.com/opencontainers/runc/libcontainer/cgroups。

kubernetes 中的 cgroup level

kubelet 启动后会在 root cgroup 下面创建一个叫做 kubepods 子 cgroup，kubelet 会把本机的 allocatable 资源写入到 kubepods 下对应的 cgroup 文件中，比如 kubepods/cpu.share，而这个 cgroup 下面也会存放节点上面所有 pod 的 cgroup，以此来达到限制节点上所有 pod 资源的目的。在 kubepods cgroup 下面，kubernetes 会进一步再分别创建两个 QoS level cgroup，名字分别叫做 burstable 和 besteffort，这两个 QoS level 的 cgroup 是作为各自 QoS 级别的所有 Pod 的父 cgroup 来存在的，在为 pod 创建 cgroup 时，首先在对应的 Qos cgroup 下创建 pod level cgroup，然后在 pod level cgroup 继续创建对应的 container level cgroup，对于 Guaranteed Qos 对应的 pod 会直接在 kubepods 同级的 cgroup 中创建 pod cgroup。

目前 kubernetes 仅支持 cpu、memory、pids 、hugetlb 四个 cgroup 子系统。

当 kubernetes 在收到一个 pod 的资源申请信息后通过 kubelet 为 pod 分配资源，kubelet 基于 pod 申请的资源以及 pod 对应的 QoS 级别来通过 cgroup 机制最终为这个 pod 分配资源的，针对每一种资源，它会做以下几件事情：

• 首先判断 pod 属于哪种 Qos，在对应的 Qos level cgroup 下对 pod 中的每一个容器在 cgroup 所有子系统下都创建一个 pod level cgroup 以及 container level cgroup，并且 pod level cgroup 是 container level cgroup 的父 cgroup，Qos level cgroup 在 kubelet 初始化时已经创建完成了；
• 然后根据 pod 的资源信息更新 QoS level cgroup 中的值；
• 最后会更新 kubepods level cgroup 中的值；

对于每一个 pod 设定的 requests 和 limits，kubernetes 都会转换为 cgroup 中的计算方式，CPU 的转换方式如下所示：

• cpu.shares = (cpu in millicores * 1024) / 1000
• cpu.cfs_period_us = 100000 (i.e. 100ms)
• cpu.cfs_quota_us = quota = (cpu in millicores * 100000) / 1000
• memory.limit_in_bytes

CPU 最终都会转换为以微秒为单位，memory 会转换为以 bytes 为单位。

以下是 kubernetes 中的 cgroup level 的一个示例，此处仅展示 cpu、memory 对应的子 cgroup：

.
|-- blkio
|-- cpu -> cpu,cpuacct
|-- cpu,cpuacct
|   |-- init.scope
|   |-- kubepods
|   |   |-- besteffort
|   |   |-- burstable
|   |   `-- podd15c4b83-c250-4f1e-94ff-8a4bf31c6f25
|   |-- system.slice
|   `-- user.slice
|-- cpuacct -> cpu,cpuacct
|-- cpuset
|   |-- kubepods
|   |   |-- besteffort
|   |   |-- burstable
|   |   `-- podd15c4b83-c250-4f1e-94ff-8a4bf31c6f25
|-- devices
|-- hugetlb
|-- memory
|   |-- init.scope
|   |-- kubepo