由这个公式可以得知，在软限制的前提下，stress-cpu-2可以跑满3333m CPU，但是我们只分配了3个进程去跑满CPU，也就是说，实际上stress-cpu-2可以跑到3000mCPU ，正好符合我们使用top看到的数据，占用了300%(3000m)，还剩余333m左右的CPU资源未使用，而这部分的资源可以被其他进程使用。那么可以思考一下，stress-cpu可以使用多少CPU资源？
其实从上面top命令的结果就可以知道，stress-cpu使用了近1000mCPU的资源，这是因为，当CPU满负载时，会相应的分配666mCPU的资源，此时stress-cpu-2并没有完全使用完，还剩余333mCPU未被使用，那么由于软限制的作用下，实际上是可以使用这部分未被使用的资源，也就是说，stress-cpu可以使用666m + 333m = 999m(CPU)，也就是符合使用top命令看到的96%CPU使用率。
CPU资源限制的目的如果没有指定CPU限制，则容器可以无限制的使用主机CPU资源。为集群中的pod设置CPU请求和限制，可以有效的利用集群上的CPU资源，防止应用突发高峰期的时候CPU猛涨影响其他应用的稳定运行
QoS前面我们讲了如何通过设置资源的request和limit来限制pod对主机资源的使用，在前面几个例子中，我们看到，当我们设置了资源配额时，查看pod yaml可以看到qosClass的值为 Burstable，这是因为在k8s中，会为pod设置不同的QoS类型，以保证pod的资源可用，其中QoS有三个类型：
Guaranteed：Pod中的所有容器（包括init容器）都必须设置内存和CPU的请求(limit)和限制(request)，且请求和限制的值要相等。（如果只设置limit，则默认request=limit）；
Burstable：Pod中至少有一个容器设置了内存和CPU请求，且不符合Guaranteed QoS类型的标准；
BestEffort：Pod中所有的容器都没有设置任何内存和CPU的限制和请求。
即会根据对应的请求和限制来设置QoS等级，接下来我们分别创建对应的QoS等级来感受一下
Guaranteed定义：Pod中的所有容器（包括init容器）都必须设置内存和CPU的请求(limit)和限制(request)，且请求和限制的值要相等。其中如果只设置limit，则默认request=limit
举个例子：创建一个包含内存和CPU请求和限制的pod，其中内存的请求和限制都为300Mi，CPU的请求和限制都为500m
apiVersion: v1 kind: Pod metadata: name: pod-guaranteed spec: containers: - name: pod-guaranteed image: zerchin/network resources: limits: memory: "300Mi" cpu: "500m" requests: memory: "300Mi" cpu: "500m"创建pod
kubectl create -f pod-guaranteed.yaml查看pod 详细信息
kubectl get pod pod-guaranteed -oyaml输出结果如下，可以看到pod的qosClass为Guaranteed
... ... name: pod-guaranteed uid: 494e608c-d63e-41a9-925c-3ac7acf7b465 ... ... limits: cpu: 500m memory: 300Mi requests: cpu: 500m memory: 300Mi ... ... status: qosClass: Guaranteed根据前面的经验，这里Guaranteed对应的就是pod在CGroup中的路径，对应的CGroup路径如下：
CPU：/sys/fs/cgroup/memory/kubepods/pod494e608c-d63e-41a9-925c-3ac7acf7b465
内存：/sys/fs/cgroup/cpu/kubepods/pod494e608c-d63e-41a9-925c-3ac7acf7b465
Burstable定义：Pod中至少有一个容器设置了内存和CPU请求，且不符合Guaranteed QoS类型的标准；
回顾一下我们前面我们在了解内存和CPU限制的时候，创建的pod都是Burstable Qos类型，包括：
单一设置内存或CPU的request
同时设置了内存或CPU的request和limit，且request≠limit
同时设置了内存或CPU的request和limit，且request=limit
上述这些都是pod中只含有单个容器，还有一种情况就是单个pod包含多个容器，如果一个容器指定了资源请求，另一个容器没有指定任何请求和限制，则也是属于Burstable Qos类型
举个例子：创建一个多容器的pod，其中一个容器设置了内存和CPU的请求和限制且值相等，另一个容器不限制资源
apiVersion: v1 kind: Pod metadata: name: pod-burstable spec: containers: - name: pod-burstable-1 image: zerchin/network resources: limits: memory: "300Mi" cpu: "500m" requests: memory: "300Mi" cpu: "500m" - name: pod-burstable-2 image: busybox:1.28 args: ["sh", "-c", "sleep 3600"]创建pod
kubectl create -f pod-burstable.yaml查看pod 详细信息
kubectl get pod pod-burstable -oyaml