99热在线精品一区二区三区_国产伦精品一区二区三区女破破_亚洲一区二区三区无码_精品国产欧美日韩另类一区

寫(xiě)在前面
在上一篇關(guān)于Kubernetes資源限制的文章我們討論了如何通過(guò)ResourceRequirements設(shè)置Pod中容器內(nèi)存限制，以及容器運(yùn)行時(shí)是如何利用Linux Cgroups實(shí)現(xiàn)這些限制的。也分析了requests是用來(lái)通知調(diào)度器Pod所需資源需求和limits是在宿主機(jī)遇到內(nèi)存壓力時(shí)幫助內(nèi)核限制資源二者的區(qū)別。

成都創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)公司，提供成都網(wǎng)站建設(shè)、做網(wǎng)站，網(wǎng)頁(yè)設(shè)計(jì)，建網(wǎng)站，PHP網(wǎng)站建設(shè)等專(zhuān)業(yè)做網(wǎng)站服務(wù);可快速的進(jìn)行網(wǎng)站開(kāi)發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展；專(zhuān)業(yè)做搜索引擎喜愛(ài)的網(wǎng)站，是專(zhuān)業(yè)的做網(wǎng)站團(tuán)隊(duì)，希望更多企業(yè)前來(lái)合作!

在本文中，我會(huì)繼續(xù)深入探討CPU時(shí)間的requests和limits。你是否閱讀過(guò)第一篇文章并不會(huì)影響本文的學(xué)習(xí)，但是我建議你兩篇文章都讀一讀，從而得到工程師或者集群管理員視角的集群控制全景。

CPU時(shí)間
正如我在第一篇文章中指出，限制CPU時(shí)間要比限制內(nèi)存限制更加復(fù)雜，好消息是限制CPU也是根據(jù)我們前面所了解到的cgroups機(jī)制控制的，與限制內(nèi)存的原理是通用的，我們只需要關(guān)注一些細(xì)節(jié)即可。我們從向前文的例子里添加CPU時(shí)間限制開(kāi)始：
resources:
requests:
memory: 50Mi
cpu: 50m
limits:
memory: 100Mi
cpu: 100m

單位后綴m表示“千分之一個(gè)核心”，所以這個(gè)資源對(duì)象定義了容器進(jìn)程需要50/1000的核心（5%），并且最多使用100/1000的核心（10%）。類(lèi)似的，2000m表示2顆完整的核心，當(dāng)然也可以用2或者2.0來(lái)表示。讓我們創(chuàng)建一個(gè)只擁有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 “l(fā)imit-test” created

我們能夠看到Kubernetes已經(jīng)配置了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都把一個(gè)核心劃分為1024份，而Kubernetes則劃分為1000份。那么Docker如何把它應(yīng)用到容器進(jìn)程上？設(shè)置內(nèi)存限制會(huì)讓Docker來(lái)配置進(jìn)程的memory cgroup，同樣設(shè)置CPU限制會(huì)讓它配置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

你可能會(huì)驚奇地發(fā)現(xiàn)設(shè)置一個(gè)CPU請(qǐng)求會(huì)把這個(gè)值發(fā)送到cgroup去，而上篇文章中設(shè)置內(nèi)存卻并非如此。下面這行內(nèi)核對(duì)內(nèi)存軟限制的行為對(duì)Kubernetes來(lái)說(shuō)沒(méi)什么用處，而設(shè)置了cpu.shares則是有用的。我等會(huì)會(huì)對(duì)此做出解釋。那么當(dāng)我們?cè)O(shè)置cpu限制時(shí)發(fā)生了什么？讓我們一起找找看：

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

deployment.apps “l(fā)imit-test” created

現(xiàn)在我們回過(guò)頭來(lái)看看Kubernetes Pod資源對(duì)象的限制：

$ 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

正如我們所見(jiàn)，CPU請(qǐng)求存放在HostConfig.CpuShares屬性里。CPU限制，盡管不是那么明顯，它由HostConfig.CpuPeriod和HostConfig.CpuQuota兩個(gè)值表示，這些Docker容器配置映射為進(jìn)程的cpu, cpuacct cgroup的兩個(gè)屬性：cpu.cfs_period_us和cpu.cfs_quota_us。讓我們仔細(xì)看看：

$ 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

如我們所料這兩個(gè)配置會(huì)同樣配置到Docker容器配置里。但是這些值是怎么從Pod的100m CPU限制里轉(zhuǎn)換過(guò)來(lái)，并且是怎么實(shí)現(xiàn)的呢？原來(lái)CPU requests和CPU limits是由兩套不同的cgroup分別進(jìn)行控制的。Requests使用CPU分片系統(tǒng)，是二者中出現(xiàn)較早的一個(gè)。Cpu分片是將每個(gè)核心劃分為1024份，并且保證每個(gè)進(jìn)程會(huì)接收到一定比例的CPU分片。如果只有1024片而這兩個(gè)進(jìn)程都設(shè)置cpu.shares為512，那么這兩個(gè)進(jìn)程會(huì)各自得到一半的CPU時(shí)間。CPU分片系統(tǒng)并不能指定上界，也就是說(shuō)如果一個(gè)進(jìn)程沒(méi)有使用它的這一份，其它進(jìn)程是可以使用的。

在2010年左右Google和一些公司注意到了這個(gè)可能存在的問(wèn)題。進(jìn)而合并了一個(gè)更加強(qiáng)大的秒級(jí)響應(yīng)的系統(tǒng)：CPU帶寬控制。帶寬控制系統(tǒng)定義了一個(gè)通常是1/10秒的周期，或者100000微秒，以及一個(gè)表示周期里一個(gè)進(jìn)程可以使用的大分片數(shù)配額。在這個(gè)例子里，我們?yōu)槲覀兊腜od申請(qǐng)了100mCPU，它等價(jià)于100/1000的核心，或者10000/100000毫秒的CPU時(shí)間。所以我們的CPU requests被翻譯為設(shè)置這個(gè)進(jìn)程的cpu,cpuacct的配置為cpu.cfs_period_us=100000并且cpu.cfs_quota_us=10000。cfs表示完全公平調(diào)度，它是Linux默認(rèn)的CPU調(diào)度器。同時(shí)還有一個(gè)響應(yīng)quota值的實(shí)時(shí)調(diào)度器 。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線(xiàn)，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性?xún)r(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專(zhuān)為企業(yè)上云打造定制，能夠滿(mǎn)足用戶(hù)豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)站題目：深入理解Kubernetes資源限制：CPU-創(chuàng)新互聯(lián)
文章來(lái)源：http://www.ef60e0e.cn/article/djosgh.html