深刻理解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限制会让它配置cpu, cpuacct cgroup。  

$ ps ax | grep /bin/sh

   60554 ? Ss 0:00 /bin/sh -c while true; do sleep 2; done

$ sudo cat /proc/60554/cgroup

...

4:cpu,cpuacct:/kubepods/burstable/pode12b33b1-db07-11e8-b1e1-42010a800070/3be263e7a8372b12d2f8f8f9b4251f110b79c2a3bb9e6857b2f1473e640e8e75

ls -l /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pode12b33b1-db07-11e8-b1e1-42010a800070/3be263e7a8372b12d2f8f8f9b4251f110b79c2a3bb9e6857b2f1473e640e8e75

total 0 

drwxr-xr-x 2 root root 0 Oct 28 23:19 . 

drwxr-xr-x 4 root root 0 Oct 28 23:19 .. 

... 

-rw-r--r-- 1 root root 0 Oct 28 23:19 cpu.shares

Docker的HostConfig.CpuShares容器属性映射到了cgroup的cpu.shares上，因此让咱们看看： 

$ sudo cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/podb5c03ddf-db10-11e8-b1e1-42010a800070/64b5f1b636dafe6635ddd321c5b36854a8add51931c7117025a694281fb11444/cpu.shares

51 

你可能会惊奇地发现设置一个CPU请求会把这个值发送到cgroup去，而上篇文章中设置内存却并不是如此。下面这行内核对内存软限制的行为对Kubernetes来讲没什么用处，而设置了cpu.shares则是有用的。我等会会对此作出解释。那么当咱们设置cpu限制时发生了什么？让咱们一块儿找找看： 

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

deployment.apps "limit-test" created

如今咱们回过头来看看Kubernetes Pod资源对象的限制： 

$ kubectl get pods limit-test-5b4fb64549-qpd4n -o=jsonpath='{.spec.containers[0].resources}'

map[limits:map[cpu:100m] requests:map[cpu:50m]]

在Docker容器配置里： 

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

f2321226620e

$ docker inspect 472a**e32a5 --format '{{.HostConfig.CpuShares}} {{.HostConfig.CpuQuota}} {{.HostConfig.CpuPeriod}}'

51 10000 100000

正如咱们所见，CPU请求存放在HostConfig.CpuShares属性里。CPU限制，尽管不是那么明显，它由HostConfig.CpuPeriod和HostConfig.CpuQuota两个值表示，这些Docker容器配置映射为进程的cpu, cpuacct cgroup的两个属性：cpu.cfs_period_us和cpu.cfs_quota_us。让咱们仔细看看： 

$ sudo cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod2f1b50b6-db13-11e8-b1e1-42010a800070/f0845c65c3073e0b7b0b95ce0c1eb27f69d12b1fe2382b50096c4b59e78cdf71/cpu.cfs_period_us

100000

$ sudo cat /sys/fs/cgroup/cpu,cpuacct/kubepods/burstable/pod2f1b50b6-db13-11e8-b1e1-42010a800070/f0845c65c3073e0b7b0b95ce0c1eb27f69d12b1fe2382b50096c4b59e78cdf71/cpu.cfs_quota_us

10000

如咱们所料这两个配置会一样配置到Docker容器配置里。可是这些值是怎么从Pod的100m CPU限制里转换过来，而且是怎么实现的呢？原来CPU requests和CPU limits是由两套不一样的cgroup分别进行控制的。Requests使用CPU分片系统，是两者中出现较早的一个。Cpu分片是将每一个核心划分为1024份，而且保证每一个进程会接收到必定比例的CPU分片。若是只有1024片而这两个进程都设置cpu.shares为512，那么这两个进程会各自获得一半的CPU时间。CPU分片系统并不能指定上界，也就是说若是一个进程没有使用它的这一份，其它进程是可使用的。

在2010年左右Google和一些公司注意到了这个可能存在的问题（https://ai.google/research/pubs/pub36669）。进而合并了一个更增强大的秒级响应的系统：CPU带宽控制。带宽控制系统定义了一个一般是1/10秒的周期，或者100000微秒，以及一个表示周期里一个进程可使用的最大分片数配额。在这个例子里，咱们为咱们的Pod申请了100mCPU，它等价于100/1000的核心，或者10000/100000毫秒的CPU时间。因此咱们的CPU requests被翻译为设置这个进程的cpu,cpuacct的配置为cpu.cfs_period_us=100000而且cpu.cfs_quota_us=10000。cfs表示彻底公平调度，它是Linux默认的CPU调度器。同时还有一个响应quota值的实时调度器 。

咱们为Kubernetes设置CPU requests其实是设置了cpu.shares cgroup属性，设置CPU limits配置了另外一个子系统的cpu.cfs_period_us和cpu.cfs_quota_us属性。就像内存requests对调度器的意义同样，CPU requests会让调度器选择至少拥有那么多可用CPU分片的节点。不一样于内存requests，设置CPU requests也会给cgroup设置相应的属性，帮助内核实际给进程分配同样数量的CPU核心分片。Limits的处理也与内存不同。超出内存limits会让你的容器进程成为oom-kill的选项，可是你的进程基本上不可能超出设置的cpu配额，而且永远不会由于试着使用更多CPU而被驱逐。系统在调度器那里增强了配额的使用，因此进程在到达limits后只会被限流。 

若是你并未为你的容器设置这些属性，或者给他们设置了不许确的值会怎么样？做为内存，若是你设置了limits但并未指定requests，Kubernetes会默认让request指向limit。若是你对你的应用须要多少CPU时间很清楚的话这没问题。那么若是设置requests而不设置limits呢？在这个场景里Kubernetes仍然能够精确地调度你的Pod，内核也会保证它能获得须要的最少资源配额。可是不会限制你的进程只能使用requested数量的资源，它可能会偷取别的进程的分片。不设置requests和limits是最坏的状况，调度器不知道容器须要多少资源，进程的CPU分片也是无限的，这也许会对节点带来不利的影响。这引出了我想要说的最后一件事情：为每一个namespace设置默认的的资源限制。 

默认限制

在了解到不为Pod配置资源限制会有一些负面效应后，你可能会想到给它们设置默认值，因此每一个提交到集群的Pod都会有一个默认设置。Kubernetes容许咱们这么作：基于Namespace，使用v1版本的LimitRange API对象实现。你能够经过在你想限制的Namespace里建立LimitRange对象来创建默认资源限制。示例以下： 

apiVersion: v1 

kind: LimitRange 

metadata: 

    name: default-limit 

spec: 

    limits: 

    - default: 

        memory: 100Mi 

        cpu: 100m 

      defaultRequest: 

        memory: 50Mi 

        cpu: 50m 

    - max: 

        memory: 512Mi 

        cpu: 500m 

    - min: 

        memory: 50Mi  

        cpu: 50m 

      type: Container

这里的命名可能会有些迷惑，让咱们把它拆分开看看。limits下的default键表明了每种资源的默认limits。在这个场景里，指定Namespace里的任何没有配置内存限制的Pod都会被设置一个默认100Mi的limits，任何没有CPU限制的Pod会被设置一个默认100m的limits。defaultRequest键表示资源requests。若是建立了一个Pod没有指定内存requests的Pod，它会被自动分配默认50Mi的内存，以及若是没有指定CPU requests的话，会被默认分配默认50m的CPU。max和min键则有些不一样：基本上若是一个Pod的requests或limits超过了这两种规定的上下界，这个Pod就没法提交经过建立。我目前尚未找到这种用法的场景，可是你可能会用到，因此若是有的话请你留言告诉咱们你用它解决了什么问题。

默认的LimitRange设置经过LimitRange插件应用到Pod上，这个插件存在于Kubernetes Admission Controller里。Admission Controller是可能会在对象被API接收以后，实际建立以前修改它定义的插件集合。在LimitRange场景里，它会检查每一个Pod，若是它没有指明requests和limits，而且Namespace设置里设置了默认值，它就会把这个默认值应用到Pod上。你会发现LimitRanger经过检查Pod metadata的annotations里来设置默认值。