Kubenertes资源分配之Request和Limit解析

收录待用，修改转载已取得腾讯云受权

---

Kubernetes是一个容器集群管理平台，Kubernetes须要统计总体平台的资源使用状况，合理地将资源分配给容器使用，而且要保证容器生命周期内有足够的资源来保证其运行。 同时，若是资源发放是独占的，即资源已发放给了个容器，一样的资源不会发放给另一个容器，对于空闲的容器来讲占用着没有使用的资源好比CPU是很是浪费的，Kubernetes须要考虑如何在优先度和公平性的前提下提升资源的利用率。为了实现资源被有效调度和分配同时提升资源的利用率，Kubernetes采用Request和Limit两种限制类型来对资源进行分配。

1、kubenerters中Request和Limit限制方式说明

Request: 容器使用的最小资源需求，做为容器调度时资源分配的判断依赖。只有当节点上可分配资源量>=容器资源请求数时才容许将容器调度到该节点。但Request参数不限制容器的最大可以使用资源。

Limit: 容器能使用资源的资源的最大值，设置为0表示使用资源无上限。

Request可以保证Pod有足够的资源来运行，而Limit则是防止某个Pod无限制地使用资源，致使其余Pod崩溃。二者之间必须知足关系: 0<=Request<=Limit<=Infinity (若是Limit为0表示不对资源进行限制，这时能够小于Request)

在腾讯云容器服务(CCS)中，能够在建立服务，在容器编辑栏中点击显示高级设置，在高级设置中进行CPU和Memory的Request和Limit设置。目前CPU支持设置Request和Limit，用户能够根据业务的特色动态的调整Request和Limit的比例关系。Memory目前只支持设置Request，Limit必须强制等于Request，这样确保容器不会由于内存的使用量超过了Request但没有超过Limit的状况下被意外的Kill掉。

2、kubenerters中Request和Limit使用示例

一个简单的示例说明Request和Limit的做用，测试集群包括一个4U4G的节点。已经部署的两个Pod(1,2)，每一个Pod的资源设置为（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 2U, 1G,1G).
节点上CPU和内存的资源使用状况以下图所示：

已经分配的CPU资源为：1U(分配Pod1)+1U(分配Pod2)=2U，剩余能够分配的CPU资源为2U

已经分配的内存资源为：1G(分配Pod1)+1G(分配Pod2)=2G，剩余能够分配的内存资源为2G

因此该节点能够再部署一个(CPU Requst, Memory Requst)=(2U,2G)的Pod部署，或者部署2个(CPU Requst, Memory Requst)=(1U,2G)的Pod部署

在资源限制方面，每一个Pod1和Pod2使用资源的上限为(2U,1G)，即在资源空闲的状况下，Pod使用CPU的量最大能达到2U，使用内存的最大量为1G。从CPU资源的角度，对于资源使用上线为2U的Pod，经过设置Request为1U，实现了2倍数量的Pod的部署，提升了资源的使用效率。

另一个复杂一点的例子来进一步说明Request和Limit的做用，主要说明Request和Limit都为0的Pod对提升资源使用率的做用。测试集群仍然包含有一个4U4G的Pod。集群中已经部署了四个Pod(1~4)，每一个Pod的资源设置为（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 2U, 512M,512M)。

此时节点上CPU和内存的资源使用状况以下图所示：

此时按照Request的需求，已经没有能够供分配的CPU资源。但因为Pod1~4业务负载比较低，形成节点上CPU使用率较低，形成了资源的浪费。这的时候能够经过将Request设置为0来实现对资源使用率的进一步提升。在此节点上部署4个资源限制为（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (0U, 0U, 512M,512M)。资源的使用状况以下图所示：

Pod(5~8)可以在Pod(1~4)空闲时，使用节点上剩余的CPU资源，从而进一步提升资源的使用率。

3、kubenerters中资源的抢占

Kubernetes中资源经过Request和Limit的设置，可以实现容器对资源的更高效的使用。在若是多个容器同时对资源进行充分利用，资源使用尽可能的接近Limit。这个时候Node节点上的资源总量要小于全部Pod中Limit的总会，就会发生资源抢占。

对于资源抢占的状况，Kubernetes根据资源能不能进行伸缩进行分类，分为可压缩资源和不能够压缩资源。CPU资源--是如今支持的一种可压缩资源。内存资源和磁盘资源为如今支持的不可压缩资源。

可压缩资源的抢占策略---按照Requst的比值进行分配

例如在示例一种，假设在部署了Pod(1,2)的基础上，又部署了资源限制和Pod1相同的两个容器Pod(3,4)。这个时候，节点上的资源模型为。

假设四个Pod同时负载变高，CPU使用量超过1U，这个时候每一个Pod将会按照各自的Request设置按比例分占CPU调度的时间片。在示例中，因为4个Pod设置的Request都为1U，发生资源抢占时，每一个Pod分到的CPU时间片为1U/(1U×4)，实际占用的CPU核数为1U。在抢占发生时，Limit的值对CPU时间片的分配为影响，在本例中若是条件容器Limit值的设置，抢占状况下CPU分配的比例保持不变。

不可压缩资源的抢占策略---按照优先级的不一样，进行Pod的驱逐

对于不可压缩资源，若是发生资源抢占，则会按照优先级的高低进行Pod的驱逐。驱逐的策略为： 优先驱逐Request=Limit=0的Pod，其次驱逐0<Request<Limit<Infinity (Limit为0的状况也包括在内)。 0<Request==Limit的Pod的会被保留，除非出现删除其余Pod后，节点上剩余资源仍然没有达到Kubernetes须要的剩余资源的需求。

因为对于不可压缩资源，发生抢占的状况会出Pod被意外Kill掉的状况，因此建议对于不能够压缩资源(Memory，Disk)的设置成0<Request==Limit。

针对内存抢占，本文进行了一次小的测试，示例中依次部署了Pod(1~3)单个Pod。节点中资源的示例图为：

步骤1: 部署Pod1，资源参数为（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (2U, 2U, 2G,2G)，此时Pod1中进程使用1.9G内存，Pod1运行依然正常。

步骤2: 部署Pod2，资源参数为（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 1U, 1G,2G)，此时Pod2中进程使用0.9G内存，程序运行正常。超过1G，小于2G时程序运行正常，但超过2G程序异常。

步骤3: 部署Pod3，资源参数为（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 1U, 0G,0)。此时保持Pod1中进程使用内存为1.9G，Pod2中内存使用为0.9G，pod3抢占内存，抢占内存大小为2G。这时，Pod3最早会出现因内存不足异常的状况。同时Pod2有时也会出现内存不足异常的状况。但Pod1一直可以正常运行

步骤4：修改Pod2的参数为（CPU Requst,CPU Limit,Memory Requst, Memory Limit）= (1U, 1U, 1G,1G)，仍然保持步骤3中资源的使用量。这时Pod3仍然最早出现内存不足而异常的状况，但Pod1和Pod2一直运行正常。

更多关于不可压缩资源抢占时的资源回收策略，能够参考：

https://www.kubernetes.org.cn/1150.html (Kubernetes 针对资源紧缺处理方式的配置)

---

原文连接：https://www.qcloud.com/community/article/905142