pod资源限制和QoS探索 (4)

cpu.cfs_period_us和cpu.cfs_quota_us，由这两个文件组成CPU硬限制，在这个例子中，我们设置CPUlimit的值为900m，所以cfs_quota_us/cfs_period_us等于90000/100000，也就是0.9个CPU

# cat cpu.cfs_period_us 100000 # cat cpu.cfs_quota_us 90000

cpu.shares，CPU软限制，在这个例子中我们设置了CPU request为500m，可以看出，CPU request对应了cpu.shares（此时软限制不会起到作用）

# cat cpu.shares 512

此时查看podCPU使用情况，可以看到确实已经被限制住了

# kubectl top pod NAME CPU(cores) MEMORY(bytes) stress-cpu 902m 0Mi request之CPU软限制

在前面讲内存限制的时候说到，如果只设置request，则limit没有限制。

如果CPU只设置request，此时limit也是没有限制。但是不同于内存，CPU request的值会设置到cpu.shares中，也就是说，只设置了request的pod，会有一个CPU软限制。

此时正常情况下，当节点CPU资源充足的时候，设置了request的pod，还是可以正常的请求超出request值的CPU资源，可是当节点可分配的CPU资源不足时，那么CPU软限制就会起到作用，限制pod对CPU的访问。

下面我们测试一下CPU软限制是如何生效的

查看节点可分配的CPU大小

kubectl describe node node01 ... ... Allocatable: cpu: 4 ephemeral-storage: 57971659066 hugepages-2Mi: 0 memory: 8071996Ki pods: 110 ... ... Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 380m (9%) 10m (0%) memory 100Mi (1%) 190Mi (2%) ephemeral-storage 0 (0%) 0 (0%)

目前该节点可用CPU数量为4000m，已使用了380m，也就是剩余可用CPU为3620m

我们先创建一个CPU，设置request为0.5的pod，并通过stress指定分配2个进程去跑满2个CPU

kind: Pod metadata: name: stress-cpu-1 spec: containers: - name: stress-cpu image: vish/stress resources: requests: cpu: "0.5" args: - -cpus - "2"

执行kubectl create命令，运行这个pod

kubectl create -f stress-cpu-1.yaml

查看pod状态

# kubectl get pod NAME READY STATUS RESTARTS AGE stress-cpu 1/1 Running 0 5s

查看podCPU使用情况

# kubectl top pod NAME CPU(cores) MEMORY(bytes) stress-cpu 2001m 0Mi

也可以使用top命令实时查看进程CPU使用情况

# top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30285 root 20 0 5824 3692 3120 R 200.0 0.0 56:18.95 stress

此时我们可以看到，我们进程的CPU使用率达到了2001m，超过了request设置的值

这时候我们再启动一个pod，设置request为2.5的pod，并通过stress指定分配2个进程去跑满3个CPU

apiVersion: v1 kind: Pod metadata: name: stress-cpu-2 spec: containers: - name: stress-cpu image: vish/stress resources: requests: cpu: "2.5" args: - -cpus - "3"

执行kubectl create命令，运行这个pod

kubectl create -f stress-cpu-2.yaml

查看pod状态

# kubectl get pod NAME READY STATUS RESTARTS AGE stress-cpu 1/1 Running 0 15m stress-cpu-2 1/1 Running 0 8s

查看podCPU使用情况，此时由于pod占用了大量的CPU资源，执行kubectl会卡住无法执行，可以通过top命令查看CPU使用情况

# top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20732 root 20 0 5568 3688 3120 R 300.0 0.0 6:04.80 stress 30285 root 20 0 5824 3692 3120 R 96.2 0.0 63:57.08 stress

我们再来回顾一下，首先这台主机可用CPU资源3620m，总的CPU资源为4个CPU（4000m），其中380m的CPU资源已分配给其他pod使用，但是并没有满负载，所以总的资源我们可以按照4个CPU来算。

这里可以看到PID为30285的进程是之前我们创建的pod stress-cpu，当时设置的request是0.5(500m)，并指定分配2个进程去跑满2个CPU(2000m)，也就是软限制在资源充足的情况下，使用率为200%(2000m)，超过了CPUrequest软限制。

后面我们又创建了一个request为2.5(2500m)，并指定分配3个进程去跑满3个CPU(3000m)的pod stress-cpu-2，此时CPU总的CPU使用需求为2+3=5CPU(5000m)，但是CPU的总资源只有4CPU（4000m），此时CPU软限制就会开始发挥作用。

我们查看一下对应的cpu.shares，stress-cpu pod 的cpu.shares的值为512，stress-cpu-2 pod 的cpu.shares的值为2560。

cpu.shares是软限制，理解为CPU的相对权重。根据之前表格中的算法，那么当CPU满负载的情况下（此时假设只有这两个pod正在满负载的运行）：

stress-cpu可以使用4 x 512/(512+2560)≈0.666(666m CPU)

stress-cpu-2可以使用4 x 2560/(512+2560)≈3.333(3333m CPU)