深入理解Kubernetes资源限制：CPU

写在前面

在上一篇关于Kubernetes资源限制的文章我们讨论了如何通过ResourceRequirements设置Pod中容器内存限制，以及容器运行时是如何利用Linux Cgroups实现这些限制的。也分析了requests是用来通知调度器Pod所需资源需求和limits是在宿主机遇到内存压力时帮助内核限制资源二者的区别。

在本文中，我会继续深入探讨CPU时间的requests和limits。你是否阅读过第一篇文章并不会影响本文的学习，但是我建议你两篇文章都读一读，从而得到工程师或者集群管理员视角的集群控制全景。

CPU时间

正如我在第一篇文章中指出，限制CPU时间要比限制内存限制更加复杂，好消息是限制CPU也是根据我们前面所了解到的cgroups机制控制的，与限制内存的原理是通用的，我们只需要关注一些细节即可。我们从向前文的例子里添加CPU时间限制开始：
resources:
requests:
memory: 50Mi
cpu: 50m
limits:
memory: 100Mi
cpu: 100m

单位后缀m表示“千分之一个核心”，所以这个资源对象定义了容器进程需要50/1000的核心（5%），并且最多使用100/1000的核心（10%）。类似的，2000m表示2颗完整的核心，当然也可以用2或者2.0来表示。让我们创建一个只拥有CPU requests的Pod，然后看看Docker是如何配置cgroups的：

$ kubectl run limit-test --image=busybox --requests “cpu=50m” --command – /bin/sh -c “while true; do sleep 2; done”

deployment.apps “limit-test” created

我们能够看到Kubernetes已经配置了50m的CPU requests：

$ kubectl get pods limit-test-5b4c495556-p2xkr -o=jsonpath=’{.spec.containers[0].resources}’

[cpu:50m]]

我们也可以看到Docker配置了同样的limits:

$ docker ps | grep busy | cut -d’ ’ -f1

f2321226620e

$ docker inspect f2321226620e --format ‘{ {.HostConfig.CpuShares}}’

51

为什么是51而不是50？CPU cgroup和Docker都把一个核心划分为1024份，而Kubernetes则划分为1000份。那么Docker如何把它应用到容器进程上？设置内存限制会让Docker来配置进程的memory cgroup，同样设置CPU限制会让它