Kubernetes之request 和 limit详解

我们都知道 Kubernetes 中最小的原子调度单位是Pod，那么就意味着资源管理和资源调度相关的属性都应该Pod对象的字段，其中我们最常见的就是 Pod 的 CPU 和内存配置，而为了实现 Kubernetes 集群中资源的有效调度和充分利用，Kubernetes采用 requests 和 limits 两种限制类型来对CPU和内存资源进行容器粒度的分配。

resources:  
    limits:    
        cpu: "1"
        memory: "500Mi"
    requests:    
        cpu: "100m"
        memory: "1000Mi"

下面我们首先来了解一下上面这段 yaml 文件中字段的含义：requests 和 limits：

requests 定义了对应的容器所需要的最小资源量。
limits 定义了对应容器最大可以消耗的资源上限。
cpu 等于1一般等同于1CPU 核心，1个VCPU或者一个超线程，具体要看服务器的CPU。而 limits 这里设置的 100m 则叫做100毫核，100m就表示0.1个核,所以这里也可以用0.1代替。
memory 等于500Mi，（备注：1Mi=10241024；1M=10001000）
接下来我们来初步理解 requests 和 limits 这两个资源限制类型，在 Kubernetes 对 CPU 和内存资源限额的设计，通常是指用户在提交 Pod 时，可以声明一个相对较小的 requests 值供调度器使用，而 Kubernetes 真正设置给容器 Cgroups 的，则是相对较大的 limits 值。所以一般来说，在调度的时候 requests 比较重要，在运行时 limits 比较重要。

而对应实际的业务场景来说，以 java 应用为例，requests 对应的就是JVM虚拟机所需资源的最小值，而 limits 对应的就是 JVM 虚拟机所能够使用的资源最大值。以内存资源为例一般就是指：Xms 和 Xmx，如果 requests 值设置的小于JVM虚拟机 Xms 的值，那么就会导致 Pod 内存溢出，从而导致 Pod 被杀掉，而后重新创建一个Pod。

那么如果 CPU 资源使用超过了 limits，Pod会不会被杀掉呢？答案是不会，但是被限制。如果没有设置 limits ，Pod 可以使用全部空闲的资源。另外如果设置了 limits而没有设置 requests 时，Kubernetes 默认会将 requests 等于 limits。

这里通常还会将 requests 和 limits 描述的资源分为两类：可压缩资源（compressible resources） 和不可压缩资源（incompressible resources）。这里不难看出CPU这类型资源为可压缩资源，而内存这类型资源为不可压缩资源。所以合理设置不可压缩资源的limits值就相当重要了。