关于cpu limit 和memory limit 的一些资料

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"

 

如何理解k8s中limit限制cpu单位_GavinYCF的博客-CSDN博客_k8s limit

​​​​​​k8s CPU limit和throttling的迷思 - 知乎