彻底搞懂 Kubernetes 中的 Cgroup

❝

本文转自田飞雨的博客，原文：https://www.jianshu.com/p/dd7b6b6fe1a0，版权归原作者所有。欢迎投稿，投稿请添加微信好友：cloud-native-yang

cgroups 简介

❝

cgroups（是 control groups 的简写）是 Linux 内核的一个功能，用来限制、控制与分离一个进程组的资源（如 CPU、内存、磁盘输入输出等）。

这个项目最早是由 Google 的工程师（主要是 Paul Menage 和 Rohit Seth）在 2006 年发起，最早的名称为进程容器（process containers）。在 2007 年时，因为在 Linux 内核中，容器（container）这个名词有许多不同的意义，为避免混乱，被重命名为 cgroup，并且被合并到 2.6.24 版的内核中去。自那以后，又添加了很多功能。

设计目标

cgroups 的一个设计目标是为不同的应用情况提供统一的接口，从控制单一进程到操作系统层虚拟化（像 OpenVZ，Linux-VServer，LXC）。cgroups 提供：

• 资源限制： 组可以被设置不超过设定的内存限制；这也包括虚拟内存。
• 优先级： 一些组可能会得到大量的 CPU 或磁盘 IO 吞吐量。
• 结算： 用来度量系统实际用了多少资源。
• 控制： 冻结组或检查点和重启动。

术语

cgroups 子系统

每个 cgroup 子系统代表一种资源，如针对某个 cgroup 的处理器时间或者 pid^[1] 的数量，也叫进程数。Linux 内核提供对以下 12 种 cgroup 子系统的支持：

• cpuset - 为 cgroup 内的任务分配独立的处理器和内存节点；
• cpu - 使用调度程序对 cgroup 内的任务提供 CPU 资源的访问；
• cpuacct - 生成 cgroup 中所有任务的处理器使用情况报告；
• io - 限制对 块设备^[2] 的读写操作 ;
• memory - 限制 cgroup 中的一组任务的内存使用 ;
• devices - 限制 cgroup 中的一组任务访问设备；
• freezer- 允许 cgroup 中的一组任务挂起 / 恢复；
• net_cls - 允许对 cgroup 中的任务产生的网络数据包进行标记；
• net_prio - 针对 cgroup 中的每个网络接口提供一种动态修改网络流量优先级的方法；
• perf_event - 支持访问 cgroup 中的 性能事件^[3];
• hugetlb - 为 cgroup 开启对 大页内存^[4] 的支持 ;
• pid - 限制 cgroup 中的进程数量。

这里面每一个子系统都需要与内核的其他模块配合来完成资源的控制，比如对 cpu 资源的限制是通过进程调度模块根据 cpu 子系统的配置来完成的；对内存资源的限制则是内存模块根据 memory 子系统的配置来完成的，而对网络数据包的控制则需要 Traffic Control 子系统来配合完成。

本文不会讨论内核是如何使用每一个子系统来实现资源的限制，而是重点放在内核是如何把 cgroups 对资源进行限制的配置有效的组织起来的，和内核如何把 cgroups 配置和进程进行关联的，以及内核是如何通过 cgroups 文件系统把 cgroups 的功能暴露给用户态的。

cpu 子系统

cpu 子系统用于控制 cgroup 中所有进程可以使用的 cpu 时间片。

cpu 子系统主要涉及 5 个参数：cpu.cfs_period_us，cpu.cfs_quota_us，cpu.shares，cpu.rt_period_us，cpu.rt_runtime_us。cfs 表示 Completely Fair Scheduler 完全公平调度器，是 Linux 内核的一部分，负责进程调度。

cpu.cfs_quota_us/cpu.cfs_period_us决定cpu控制组中所有进程所能使用CPU资源的最大值，而cpu.shares决定了cpu控制组间可用CPU的相对比例，这个比例只有当主机上的CPU完全被打满时才会起作用。

cpuacct 子系统

cpuacct 子系统（CPU accounting）会自动生成报告来显示 cgroup 中任务所使用的 CPU 资源。报告有两大类：cpuacct.stat 和 cpuacct.usage。

cpuset 子系统

cpuset 主要是为了 numa 使用的，numa 技术将 CPU 划分成不同的 node，每个 node 由多个 CPU 组成，并且有独立的本地内存、I/O 等资源 (硬件上保证)。可以使用 numactl 查看当前系统的 node 信息。

memory 子系统

memory 子系统^[5]自动生成 cgroup 任务使用内存资源的报告，并限定这些任务所用内存的大小。

容器可以通过设置 memory.swappiness 参数来决定是否使用 swap 空间。

cgroups 文件系统

Linux 通过文件的方式，将 cgroups 的功能和配置暴露给用户，这得益于 Linux 的虚拟文件系统（VFS）。VFS 将具体文件系统的细节隐藏起来，给用户态提供一个统一的文件系统 API 接口，cgroups 和 VFS 之间的链接部分，称之为 cgroups 文件系统。

比如挂在 cpu、cpuset、memory 三个子系统到 /cgroups/cpu_mem 目录下：

$ mount -t cgroup -o cpu,cpuset,memory cpu_mem /cgroups/cpu_mem

其中-t 选项指定文件系统类型为 cgroup 类型，-o 指定本次创建的 cgroup 实例与 cpu 和 momory 子系统（或资源）关联，cpu_momory 指定了当前 cgroup 实例在整个 cgroup 树中所处的层级名称，最后的路径为文件系统挂载点。

cgroups 驱动

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 驱动。

配置 cgroups 驱动

由于 kubeadm 把 kubelet 视为一个系统服务来管理，所以对基于 kubeadm 的安装， 我们推荐使用 systemd 驱动，不推荐 cgroupfs 驱动。

配置 cgroup 驱动^[6]

cgroups 在 K8s 中的应用

kubelet 作为 kubernetes 中的 node agent，所有 cgroup 的操作都由其内部的 containerManager 模块实现，containerManager 会通过 cgroup 将资源使用层层限制：container-> pod-> qos -> node。每一层都抽象出一种资源管理模型，通过这种方式提供了一种稳定的运行环境。如下图所示：

Conainer level cgroups

kubernetes 对于容器级别的隔离其实是交由底层的 runtime 来负责的，例如 docker, 当我们指定运行容器所需要资源的 request 和 limit 时，docker 会为容器设置进程所运行 cgroup 的 cpu.share, cpu.quota, cpu.period, mem.limit 等指标来。

CPU

首先是 CPU 资源，我们先看一下 CPU request。CPU request 是通过 cgroup 中 CPU 子系统中的 cpu.shares 配置来实现的。当你指定了某个容器的 CPU request 值为 x millicores 时，kubernetes 会为这个 container 所在的 cgroup 的 cpu.shares 的值指定为 x * 1024 / 1000。即：

cpu.shares = (cpu in millicores * 1024) / 1000

举个例子，当你的 container 的 CPU request 的值为 1 时，它相当于 1000 millicores，所以此时这个 container 所在的 cgroup 组的 cpu.shares 的值为 1024。

这样做希望达到的最终效果就是：即便在极端情况下，即所有在这个物理机上面的 pod 都是 CPU 繁忙型的作业的时候（分配多少 CPU 就会使用多少 CPU），仍旧能够保证这个 container 的能够被分配到 1 个核的 CPU 计算量。其实就是保证这个 container 的对 CPU 资源的最低需求。

而针对 CPU limit，Kubernetes 是通过 CPU cgroup 控制模块中的 cpu.cfs_period_us，cpu.cfs_quota_us 两个配置来实现的。kubernetes 会为这个 container cgroup 配置两条信息：

cpu.cfs_period_us = 100000 (i.e. 100ms)
cpu.cfs_quota_us = quota = (cpu in millicores * 100000) / 1000

在 cgroup 的 CPU 子系统中，可以通过这两个配置，严格控制这个 cgroup 中的进程对 CPU 的使用量，保证使用的 CPU 资源不会超过 cfs_quota_us/cfs_period_us，也正好就是我们一开始申请的 limit 值。

对于 cpu 来说，如果没有指定 limit 的话，那么 cfs_quota_us 将会被设置为 -1，即没有限制。而如果 limit 和 request 都没有指定的话，cpu.shares 将会被指定为 2，这个是 cpu.shares 允许指定的最小数值了。可见针对这种 pod，kubernetes 只会给他分配最少的 CPU 资源。

Memory

针对内存资源，其实 memory request 信息并不会在 container level cgroup 中有体现。kubernetes 最终只会根据 memory limit 的值来配置 cgroup 的。

在这里 kubernetes 使用的 memory cgroup 子系统中的 memory.limit_in_bytes 配置来实现的。配置方式如下：

memory.limit_in_bytes = memory limit bytes

memory 子系统中的 memory.limit_in_bytes 配置，可以限制一个 cgroup 中的所有进程可以申请使用的内存的最大量，如果超过这个值，那么根据 kubernetes 的默认配置，这个容器会被 OOM killed，容器实例就会发生重启。

对于内存来说，如果没有 limit 的指定的话，memory.limit_in_bytes 将会被指定为一个非常大的值，一般是 2^64 ，可见含义就是不对内存做出限制。

Pod level cgroups

一个 pod 中往往有一个或者有多个容器，但是如果我们将这些容器的资源使用进行简单的加和并不能准确的反应出整个 pod 的资源使用，因为每个 pod 都会有一些 overhead 的资源，例如 sandbox 容器使用的资源，docker 的 containerd-shim 使用的资源，此外如果指定 memory 类型的 volume 时，这部分内存资源也是属于该 pod 占用的。

因为这些资源并不属于某一个特定的容器，我们无法仅仅通过容器的资源使用量简单累加获取到整个 pod 的资源，为了方便统计一个 pod 所使用的资源 (resource accounting)，并且合理的将所有使用到的资源都纳入管辖范围内，kubernetes 引入了 pod level Cgroup，会为每个 pod 创建一个 cgroup。

该特性通过指定--cgroups-per-qos=true 开启 , 在 1.6+版本中是默认开启。kubelet 会为每个 pod 创建一个 pod<pod.UID> 的 cgroup，该 cgroup 的资源限制取决于 pod 中容器的资源 request，limit 值。

• 如果为所有容器都指定了 request 和 limit 值，则 pod cgroups 资源值设置为所有容器的加和，即：

pod<UID>/cpu.shares = sum(pod.spec.containers.resources.requests[cpu])
pod<UID>/cpu.cfs_quota_us = sum(pod.spec.containers.resources.limits[cpu])
pod<UID>/memory.limit_in_bytes = sum(pod.spec.containers.resources.limits[memory])

• 如果其中某个容器只指定了 request 没有指定 limit 则并不会设置 pod cgroup 的 limit 值， 只设置其 cpu.share 值：

pod<UID>/cpu.shares = sum(pod.spec.containers.resources.requests[cpu])

• 如果所有容器没有指定 request 和 limit 值，则只设置 pod cgroup 的 cpu.share， 该 pod 在资源空闲的时候可以使用完 node 所有的资源，但是当资源紧张的时候无法获取到任何资源来执行，这也符合低优先级任务的定位：

pod<UID>/cpu.shares = sum(pod.spec.containers.resources.requests[cpu])

其实上面三种设置方式对应的就是三种 QoS pod。这样设置 pod level cgourp 可以确保在合理指定容器资源时能够防止资源的超量使用，如果未指定则可以使用到足够多的可用资源。每次启动 pod 时 kubelet 就会同步对应的 pod level cgroup。

QoS level cgroup

kubernetes 中会将所有的 pod 按照资源 request, limit 设置分为不同的 QoS classes， 从而拥有不同的优先级。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

如果指定了 --cgroups-per-qos 也会为每个 QoS 也会对应一个 cgroup，该功能默认开启，这样就可以利用 cgroup 来做一些 QoS 级别的资源统计，必要时也可以通过该 cgroup 限制某个 QoS 级别的 pod 能使用的资源总和。此时每个 QoS cgroup 相当于一个资源 pool， 内部的 pod 可以共用 pool 中的资源，但是对于整个 pool 会进行一些资源的限制，避免在资源紧张时低优先级的 pod 抢占高优先级的 pod 的资源。

对于 guaranteed 级别的 pod，因为 pod 本身已经指定了 request 和 limit，拥有了足够的限制，无需再增加 cgroup 来约束。但是对于 Burstable 和 BestEffort 类型的 pod，因为有的 pod 和容器没有指定资源限制，在极端条件下会无限制的占用资源，所以我们需要分别设置 Burstable 和 BestEffort cgroup， 然后将对应的 pod 都创建在该 cgroup 下。

kubelet 希望尽可能提高资源利用率，让 Burstable 和 BestEffort 类型的 pod 在需要的时候能够使用足够多的空闲资源，所以默认并不会为该 QoS 设置资源的 limit。但是也需要保证当高优先级的 pod 需要使用资源时，低优先级的 pod 能够及时将资源释放出来：对于可压缩的资源例如 CPU， kubelet 会通过 cpu.shares 来控制，当 CPU 资源紧张时通过 cpu.shares 来将资源按照比例分配给各个 QoS pod，保证每个 pod 都能够得到其所申请的资源。

具体来说， 对于 cpu 的设置，besteffort 和 burstable 的资源使用限制如下：

ROOT/besteffort/cpu.shares = 2
ROOT/burstable/cpu.shares = max(sum(Burstable pods cpu requests, 2)

对于不可压缩资源内存，要满足“高优先级 pod 使用资源时及时释放低优先级的 pod 占用的资源”就比较困难了，kubelet 只能通过资源预留的机制，为高优先级的 pod 预留一定的资源，该特性默认关闭，用户可以通过开启 QOSReserved 特征门控（默认关闭），并设置 --qos-reserved 参数来预留的资源比例，例如 --qos-reserved=memory=50% 表示预留 50% 高优先级 request 的资源值，当前只支持 memory， 此时 qos cgroups 的限制如下：

ROOT/burstable/memory.limit_in_bytes = 
    Node.Allocatable - {(summation of memory requests of `Guaranteed` pods)*(reservePercent / 100)}
ROOT/besteffort/memory.limit_in_bytes = 
   Node.Allocatable - {(summation of memory requests of all `Guaranteed` and `Burstable` pods)*(reservePercent / 100)}

同时根据 cpu.shares 的背后实现原理，位于不同层级下面的 cgroup，他们看待同样数量的 cpu.shares 配置可能最终获得不同的资源量。比如在 Guaranteed 级别的 pod cgroup 里面指定的 cpu.shares=1024，和 burstable 下面的某个 pod cgroup 指定 cpu.shares=1024 可能最终获取的 cpu 资源并不完全相同。所以每次创建、删除 pod 都需要根据上述公式动态计算 cgroup 值并进行调整。

此时 kubelet 先会尽力去更新低优先级的 pod，给高优先级的 QoS 预留足够的资源。因为 memory 是不可压缩资源，可能当 pod 启动时，低优先级的 pod 使用的资源已经超过限制了，如果此时直接设置期望的值会导致失败，此时 kubelet 会尽力去设置一个能够设置的最小值（即当前 cgroup 使用的资源值），避免资源使用进一步增加。

通过设置 qos 资源预留能够保障高优先级的资源可用性，但是对低优先级的任务可能不太友好，官方默认是关闭该策略，可以根据不同的任务类型合理取舍。

Node level cgroups

对于 node 层面的资源，kubernetes 会将一个 node 上面的资源按照使用对象分为三部分：

1. 业务进程使用的资源， 即 pods 使用的资源；
2. kubernetes 组件使用的资源，例如 kubelet, docker；
3. 系统组件使用的资源，例如 logind, journald 等进程。

通常情况下，我们为提高集群资源利用率，会进行适当超配资源，如果控制不当，业务进程可能会占用完整个 node 的资源，从而使的第二，三部分核心的程序所使用的资源受到压制，从而影响到系统稳定性，为避免这样的情况发生，我们需要合理限制 pods 的资源使用，从而为系统组件等核心程序预留足够的资源，保证即使在极端条件下有充足的资源来使用。

kubelet 会将所有的 pod 都创建一个 kubepods 的 cgroup 下，通过该 cgroup 来限制 node 上运行的 pod 最大可以使用的资源。该 cgroup 的资源限制取值为 :

${Node Capacity} - ${kube-reserved} - ${system-reserved}

其中 kube-reserved 是为 kubernetes 组件提供的资源预留，system-reserved 是为系统组件预留的资源，分别通过--kube-reserved，--system-reserved 来指定，例如--kube-reserved=cpu=100m,memory=100Mi。

除了指定预留给系统运行的资源外，如果要限制系统运行的资源，可以通过 --enforce-node-allocatable 来设置，该 flag 指定需要执行限制的资源类型，默认值为 pods，即通过上述 kubepods 来限制 pods 的使用资源，此外还支持限制的资源类型有：

• system-reserved：限制 kubernetes 组件的资源使用，如果开启该限制，则需要同时设置--kube-reserved-cgroup 参数指定所作用的 cgroup
• kube-reserved：限制系统组件的资源使用，如果开启该限制则需要同时设置--system-reserved-cgroup
• none：不进行任何资源限制

如果需要指定多种类型，通过逗号分割枚举即可，注意如果开启了 system-reserved 和 kube-reserved 的限制，则意味着将限制这些核心组件的资源使用，以上述--kube-reserved=cpu=100m,memory=100Mi 为例，所有的 kubernetes 组件最多可以使用 cpu: 100m,memory: 100Mi。

❝

除非已经很了解自己的资源使用属性，否则并不建议对这两种资源进行限制，避免核心组件 CPU 饥饿或者内存 OOM。

默认情况下该--enforce-node-allocatable 的值为 pods，即只限制容器使用的资源，但不限制系统进程和 kubernetes 进程的资源使用量。

kubelet 会在资源紧张的时候主动驱逐低优先级的 pod，可以指定 hard-eviction-threshold 来设置阈值，这样一个 node 真正可以为 pod 使用的资源量为：

 ${Allocatable} = ${Node Capacity} - ${kube-Reserved} - ${system-Reserved} - ${hard-eviction-threshold}

这也是调度器进行调度时所使用的资源值。

核心组件的 Cgroup

除了上述提到的 cgroup 设置外，kubelet 中还有一些对于单个组件的 cgroup 设置，　例如 :

• --runtime-cgroups：用来指定 docker 等 runtime 运行的 Cgroup。目前 docker-CRI 的实现 dockershim 会管理该 cgroup 和 oom score， 确保 dockerd 和 docker-containerd 进程是运行在该 cgroup 之内，这里会对内存进行限制，使其最大使用宿主机 70% 的内存，主要是为了防止 docker 之前内存泄露的 bug。kubelet 在此处只是不断获取该 cgroup 信息供 kuelet SummarProvider 进行获取统计信息，从而通过 summary api 暴露出去。
• --system-cgroups：将所有系统进程都移动到该 cgroup 下，会进行统计资源使用。如果不指定该参数则不运行在容器中，对应的 summary stat 数据也不会统计。此处系统进程不包括内核进程， 因为我们并不想限制内核进程的使用。
• --kubelet-cgroups：如果指定改参数，则 containerManager 会确保 kubelet 在该 cgroup 内运行，同样也会做资源统计，也会调整 OOM score 值。summaryProvider 会定期同步信息，来获取 stat 信息。如果不指定该参数，则 kubelet 会自动地找到 kubelet 所在的 cgroup， 并进行资源的统计。
• --cgroup-root：kubelet 中所有的 cgroup 层级都会在该 root 路径下，默认是 /，root cgroup 可以通过 $ mount | grep cgroup 看到。如果开启--cgroups-per-qos=true，则在 kubelet containerManager 中会调整为 /kubepods。

以上 runtime-cgroups，system-cgroups，kubelet-cgoups 的设置都是可选的，如果不进行指定也可以正常运行。但是如果显式指定后就需要与前面提到的--kube-reserved-cgroup 和--system-reserved-cgroup 搭配使用，如果配置不当难以达到预期效果：

如果在--enforce-node-allocatable 参数中指定了 kube-reserved 来限制 kubernetes 组件的资源限制后，kube-reserved-cgroup 的应该是：runtime-cgroups, kubelet-cgoups 的父 cgroup。

只有对应的进程都应该运行该 cgroup 之下，才能进行限制，kubelet 会设置 kube-reserved-cgroup 的资源限制但并不会将这些进程加入到该 cgroup 中，我们要想让该配置生效，就必须让通过制定--runtime-cgroups，--kubelet-cgoups 来将这些进程加入到该 cgroup 中。

同理如果上述--enforce-node-allocatable 参数中指定了 system-reserved 来限制系统进程的资源，则--system-reserved-cgroup 的参数应该与--system-cgroups 参数相同，这样系统进程才会运行到 system-reserved-cgroup 中起到资源限制的作用。

cgroup hierarchy

最后整个整个 cgroup hierarchy 如下：

root
 | 
 +- kube-reserved
 |   |
 |   +- kubelet (kubelet process)
 |   | 
 |   +- runtime (docker-engine, containerd...)
 |
 +- system-reserved (systemd process: logind...)
 |
 +- kubepods
 |    |
 |    +- Pod1
 |    |   |
 |    |   +- Container11 (limit: cpu: 10m, memory: 1Gi)
 |    |   |     |
 |    |   |     +- cpu.quota: 10m
 |    |   |     +- cpu.share: 10m
 |    |   |     +- mem.limit: 1Gi
 |    |   |
 |    |   +- Container12 (limit: cpu: 100m, memory: 2Gi)
 |    |   |     |
 |    |   |     +- cpu.quota: 10m
 |    |   |     +- cpu.share: 10m
 |    |   |     +- mem.limit: 2Gi
 |    |   |
 |    |   +- cpu.quota: 110m  
 |    |   +- cpu.share: 110m
 |    |   +- mem.limit: 3Gi
 |    |
 |    +- Pod2
 |    |   +- Container21 (limit: cpu: 20m, memory: 2Gi)
 |    |   |     |
 |    |   |     +- cpu.quota: 20m
 |    |   |     +- cpu.share: 20m
 |    |   |     +- mem.limit: 2Gi
 |    |   |
 |    |   +- cpu.quota: 20m  
 |    |   +- cpu.share: 20m
 |    |   +- mem.limit: 2Gi
 |    |
 |    +- burstable
 |    |   |
 |    |   +- Pod3
 |    |   |   |
 |    |   |   +- Container31 (limit: cpu: 50m, memory: 2Gi; request: cpu: 20m, memory: 1Gi )
 |    |   |   |     |
 |    |   |   |     +- cpu.quota: 50m
 |    |   |   |     +- cpu.share: 20m
 |    |   |   |     +- mem.limit: 2Gi
 |    |   |   |
 |    |   |   +- Container32 (limit: cpu: 100m, memory: 1Gi)
 |    |   |   |     |
 |    |   |   |     +- cpu.quota: 100m
 |    |   |   |     +- cpu.share: 100m
 |    |   |   |     +- mem.limit: 1Gi
 |    |   |   |
 |    |   |   +- cpu.quota: 150m  
 |    |   |   +- cpu.share: 120m
 |    |   |   +- mem.limit: 3Gi
 |    |   |
 |    |   +- Pod4
 |    |   |   +- Container41 (limit: cpu: 20m, memory: 2Gi; request: cpu: 10m, memory: 1Gi )
 |    |   |   |     |
 |    |   |   |     +- cpu.quota: 20m
 |    |   |   |     +- cpu.share: 10m
 |    |   |   |     +- mem.limit: 2Gi
 |    |   |   |
 |    |   |   +- cpu.quota: 20m  
 |    |   |   +- cpu.share: 10m
 |    |   |   +- mem.limit: 2Gi
 |    |   |
 |    |   +- cpu.share: 130m
 |    |   +- mem.limit: $(Allocatable - 5Gi)
 |    |
 |    +- besteffort
 |    |   |
 |    |   +- Pod5
 |    |   |   |
 |    |   |   +- Container6 
 |    |   |   +- Container7
 |    |   |
 |    |   +- cpu.share: 2
 |    |   +- mem.limit: $(Allocatable - 7Gi)

上述所有的操作在 kubelet 中是通过 containerManager 来实现的， containerManager 启动的时候首先会 setupNode 初始化各种 cgroup，具体包括：

• 通过 enforceNodeAllocatableCgroups 来设置 kubepods，kube-reserved，system-reserved 三个 cgroup 的资源使用
• 启动 qosContainerManager 来定期同步各个 QoS class 的资源使用，会在后台不断同步 kubelet，docker，system cgroup。
• 在每个 pod 启动 / 退出时候会调用 podContainerManager 来创建 / 删除 pod 级别的 cgroup 并调用 UpdateQoSCgroups 来更新 QoS 级别的 cgroup。

上述所有更新 cgroup 的操作都会利用一个 cgroupManager 来实现。

不同 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. cgroups 的配置不同，kubelet 为会三种 Qos 分别创建对应的 QoS level cgroups。
• Guaranteed Pod Qos 的 cgroup level 会直接创建在 RootCgroup/kubepods 下
• Burstable Pod Qos 的创建在 RootCgroup/kubepods/burstable 下
• BestEffort Pod Qos 的创建在 RootCgroup/kubepods/BestEffort 下

参考文档

• Linux 资源管理之 cgroups 简介^[7]
• kubernetes 中 Qos 的设计与实现^[8]
• Cgroup 中的 CPU 资源控制^[9]
• 重学容器 29: 容器资源限制之限制容器的 CPU^[10]
• 深入解析 kubernetes 资源管理^[11]

引用链接

你可能还喜欢

点击下方图片即可阅读

Kubernetes 单机侧的驱逐策略总结

2022-07-18

让你的 Nginx 支持分布式追踪 OpenTracing

2022-07-15

K8s 选 cgroupfs 还是 systemd？这是一个问题

2022-07-13

Kubernetes 中 CPU 调度管理的现状与限制

2022-07-12

云原生是一种信仰 🤘

关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！