requests:代表容器启动请求的资源限制,分配的资源必须要达到此要求
limits:代表最多可以请求多少资源
单位m:CPU的计量单位叫毫核(m)。一个节点的CPU核心数量乘以1000,得到的就是节点总的CPU总数量。如,一个节点有两个核,那么该节点的CPU总量为2000m。
resources:
requests:
cpu: 50m #等同于0.05
memory: 512Mi
limits:
cpu: 100m #等同于0.1
memory: 1Gi
含义:该容器启动时请求50/2000的核心(2.5%)并且允许最多使用100/2000核心(5%)。
0.05个核除总核数量2就是2.5%了,0.1个核除总核数2 就是 5%了
resources:
requests:
cpu: 100m #等同于0.1
memory: 512Mi
limits:
cpu: 200m #等同于0.2
memory: 1Gi
cpu单位m的含义:该容器启动时请求100/2000的核心(5%)并且允许最多使用200/2000核心(10%)
0.1个核除总核数量2就是5%了,0.2个核除总核数2就是10%了
可以看到下图是限制200m也就是0.2个核,最高可以跑到0.2
CPU的利用率
CPU和内存不一样,它是量子化的,只有“使用中”和“空闲”两个状态。
我和老婆聊了聊CPU和内存的不同,她帮我画了一张插图 图/我的妻子
当我们说内存的使用率是60%时,我们是在说内存有60%在空间上已被使用,还有40%的空间可以放入负载。但是,当我们说CPU的某个核的使用率是60%时,我们是在说采样时间段内,CPU的这个核在时间上有60%的时间在忙,40%的时间在睡大觉。
你设定负载的CPU limit时,这个时空区别可能会带来一个让你意想不到的效果——过分的降速限流, 节点CPU明明不忙,但是节点故意不让你的负载全速使用CPU,服务延时上升。
request和limit
k8s的一大好处就是资源隔离,通过设定负载的request和limit,我们可以方便地让不同程序共存于合适的节点上。
其中,request是给调度看的,调度会确保节点上所有负载的CPU request合计与内存request合计分别都不大于节点本身能够提供的CPU和内存,limit是给节点(kubelet)看的,节点会保证负载在节点上只使用这么多CPU和内存。例如,下面配置意味着单个负载会调度到一个剩余CPU request大于0.1核,剩余request内存大于200MB的节点,并且负载运行时的CPU使用率不能高于0.4核(超过将被限流),内存使用不多余300MB(超过将被OOM Kill并重启)。
resources:
requests:
memory: 200Mi
cpu: "0.1"
limits:
memory: 300Mi
cpu: "0.4"