docker對cpu使用及在kubernetes中的應用

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。

可能的問題

linux對NUMA下的CPU調度是有一些優化的。可以參考Linux 的 NUMA 技術。

numa架構下，可能還會一些其他問題需要關注，比如NUMA架構的CPU中提的，可能會有些影響。