Docker对CPU使用及在Kubernetes中的应用

167次阅读

共计 3184 个字符，预计需要花费 8 分钟才能阅读完成。

Docker 对 CPU 的使用

docker 对于 CPU 的可配置的主要几个参数如下：

  --cpu-shares                    CPU shares (relative weight)
  --cpu-period                    Limit CPU CFS (Completely Fair Scheduler) period
  --cpu-quota                     Limit CPU CFS (Completely Fair Scheduler) quota
  --cpuset-cpus                   CPUs in which to allow execution (0-3, 0,1)

这些参数主要是通过配置在容器对应 cgroup 中，由 cgroup 进行实际的 CPU 管控。其对应的路径可以从 cgroup 中查看到

cpuset-cpus

[root@node-156 ~]# cat /sys/fs/cgroup/cpuset/docker/12c35c978d926902c3e5f1235b89a07e69d484402ff8890f06d0944cc17f8a71/cpuset.cpus
0-31

cpuset主要用于指定容器运行的 CPU 编号，也就是我们所谓的绑核。

cpushare

[root@node-156 ~]# cat /sys/fs/cgroup/cpu/docker/12c35c978d926902c3e5f1235b89a07e69d484402ff8890f06d0944cc17f8a71/cpu.shares
1024

cpushare主要用于 cfs 中调度的权重。一般来说，在条件相同的情况下，cpushare 值越高的，将会分得更多的时间片。

两个容器的 CPU 时间片比重并不是严格权重的比值，因为两个容器可能对 CPU 时间片的需求不同。

cpu-period 和 cpu-quota

[root@node-156 ~]# cat /sys/fs/cgroup/cpu/docker/12c35c978d926902c3e5f1235b89a07e69d484402ff8890f06d0944cc17f8a71/cpu.cfs_quota_us 
-1

[root@node-156 ~]# cat /sys/fs/cgroup/cpu/docker/12c35c978d926902c3e5f1235b89a07e69d484402ff8890f06d0944cc17f8a71/cpu.cfs_period_us 
100000

cfs_quota_us和 cfs_period_us 两个值是联合使用的，两者的比值，即 cfs_quota_us/cfs_period_us 代表了该容器实际可用的做多的 CPU 核数。

比如cfs_quota_us=50000，cfs_period_us=100000，那么二者的比值是 0.5，也就是说该容器可以使用 0.5 个 cpu。这样的管控粒度更细，在 cgroup 使用 systemd 时最低可以到 0.01 核。

cfs_quota_us如果为-1，则表示容器使用 CPU 不受限制。

绑核方式的益处和弊端

我们先前主要使用的是cpuset，也就是通过绑核的方式。这一方式严格的保证了容器可以使用的 CPU 的真正的核数。并通过调度使得其他容器不绑定这几个 CPU，使得容器可以独享这些 cpu。这也就意味着容器的最多使用的 CPU 个数和最小消耗的 CPU 的数目都是这些核数。

这样的方式安全性高，保证容器的效率，但是弊端也很多：

不够灵活
资源利用率低，因为容器可能声明使用了多个 CPU，但是实际利用率很低
在 NUMA 架构下，未考虑 CPU 亲和性的话，可能会导致性能下降

kubernetes 中的 CPU 使用

kubernetes 对容器可以设置两个值：

spec.containers[].resources.limits.cpu
spec.containers[].resources.requests.cpu

limits 主要用以声明使用的最大的 CPU 核数。通过设置 cfs_quota_us 和cfs_period_us。比如 limits.cpu=3，则cfs_quota_us=300000。

cfs_period_us值一般都使用默认的 100000

request 则主要用以声明最小的 CPU 核数。一方面则体现在设置 cpushare 上。比如 request.cpu=3，则cpushare=1024*3=3072。

另一方面是提供调度时候使用。

当创建一个 Pod 时，Kubernetes 调度程序将为 Pod 选择一个节点。每个节点具有每种资源类型的最大容量：可为 Pods 提供的 CPU 和内存量。调度程序确保对于每种资源类型，调度的容器的资源请求的总和小于节点的容量。尽管节点上的实际内存或 CPU 资源使用量非常低，但如果容量检查失败，则调度程序仍然拒绝在节点上放置 Pod。

而计算节点 CPU 的已经分配的量就是通过计算所有容器的 request 的和得到的。

可以参考 Managing Compute Resources for Containers

kubernetes 对 CPU 使用的益处

更加灵活，更细粒度的控制。CPU 的限制不仅仅在 CPU 核这个级别，甚至可以到 0.01 核。
CPU 复用。绑核之后容器既无法使用其他的 CPU，容器自己本身绑定的 CPU 也无法被其他容器使用。最小最大资源使用量都是这几个核。而 kubernetes 的方式可以实现所有的 CPU 成为一个 CPU 池，提供给 CPU 使用。
可控和可靠的“超卖”
best-effort 任务支持。可以充分利用闲置的 CPU 资源，使得 best-effort 任务得到最大限度的资源支持。同时当资源紧张时，又可以优先杀死 best-effort，保证 Guaranteed 的容器的资源使用。可以参考 Resource Quality of Service in Kubernetes。