1. 程式人生 > >深入理解Kubernetes資源限制:CPU

深入理解Kubernetes資源限制:CPU

運行時 man 們的 資源 RoCE 技術 pod 帶寬控制 調度

寫在前面
在上一篇關於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 472abbce32a5 --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和一些公司註意到了這個可能存在的問題。進而合並了一個更加強大的秒級響應的系統: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