云计算-k8s超配理论

在很多商业k8s方案中，存在所谓的超配，或者超卖，超售比的配置，只要开启就能大幅度提高k8s资源利用率。这里总结了一些原理概念

概念

当前很多业务有波峰和波谷，部署服务时，为了保证服务的性能和稳定性，通常会按照波峰时需要的资源申请，但是波峰的时间可能很短，这样在非波峰时段就有资源浪费。另外，由于在线作业SLA要求较高，为了保证服务的性能和可靠性，通常会申请大量的冗余资源，因此，会导致资源利用率很低、浪费比较严重。

超配理论及影响分析

超配理论

Kubernetes 生产态和测试态集群是任务态的容器作业执行环境。资源管理组件以资源组为单位对集群计算资源进行管理和分配。

从物理层面看，kubernetes 集群所有node 的可供给资源量（allocatable）可以看作集群的实际资源总量。在大数据云业务逻辑中，正常情况下，总可售资源量总是等于实际资源总量。开启超配后，集群的总可售资源量为集群所有node 的可供给资源量（allocatable）*超配比。

当总可售资源量大于实际资源总量时，理论上容器资源池可以接受更多node 的剩余可分配资源是该node 的可供给资源减去该node 的所有非终止状态的pod 的request 总和的值. 

一个node 的所有非终止状态pod 的request 总和占该node 的可供给资源量的比值就是这个node 的资源分配水位。

因此，仅仅将一个集群的总可售资源量设置为大于实际资源总量并不能使集群接受更多 pod 提交。从node 层面看，只有降低pod 的request 值，kubernetes 调度引擎才能将更多的pod 调度到node. 降低pod 的request 值称为pod 压缩。

pod的 limit 即对应于容器作业配置的资源量，这个limit 值同时也受资源组（namespace）的约束。注意，在大数据云资源组实现中，namespace resourcequota 约束的是该namespace 下pod 的limit. 如图，resourcequota 设定了当前namespace 的limits.cpu（namespace下所有pod的CPU限制总和） 和limits.memory （namespace下所有pod的内存限制总和）的Hard 值，约束当前namespace 下的所有pod 的limits.cpu 和limits.memory. 由于resourcequota 并没有设定任何request 指标，因此并不会约束该namespace 下的pod 的request 项。

正常情况下，一个 namespace 下所有非终止状态的pod 的limits 总和不能超过namespace resourcequota 规定的limits 值。

对于一个 node, 所有pod 的request 资源总量占比不能超过集群可分配资源的100%, 而limit 资源总量可以超过100%, 即overcommitted.

综上所述，一个 Kubernetes 集群要接受更多pod 提交，

• （1）首先要降低pod 的request 值，以使Kubernetes 调度引擎将更多pod 调度到节点上——这是Kubernetes 本身的机制。

• （2）同时，要设置集群的可售资源总量大于集群实际资源总量，即设置sum(namespace quota) > sum(node allocatable)，这一步即大数据云运营侧面向用户的超额配置设置。

以上两项核心措施可以概括为 pod 压缩和集群超配。这两项措施的目标是使集群接受更多的 pod 提交，但跟集群的实际资源利用率(sum(使用量)/集群所有节点的实际物理资源)并没有直接关系。

影响超配的因素

集群超额配置关注的侧重点是资源分配策略，而利用率跟应用程序的业务相关，是动态的。Kubernetes 的用户、应用开发者必须对自己的应用程序的资源需求（主要是 cpu, mem 资源）有深入理解和把握，据此设置合理的container request 和limit, 以向Kubernetes 提供调度和运行依据。

如果 pod 的实际资源利用率总是很低（低于声明的limit 甚至低于request），则开发者应考虑调整pod 声明的request 和limit. 

提升作业的资源利用率

• 调整作业的资源利用率有两个方向：

1、合理分配资源

需要项目的资源运营人员进行资源的把控，根据作业类型和业务量合理分配作业资源。

2、设置合理的request，limit比值

风险及影响

开启超配功能后，当kubernetes集群的内存这种不可压缩的资源出现紧缺时会触发Pod 驱逐。Pod 驱逐策略包括驱逐指标阈值、驱逐监控策略等。kubelet 会将驱逐信号与节点状况对应起来。当节点压力大时，会触发Pod 驱逐。在驱逐Pod 时又会按照Pod 的Qos级别进行驱逐。

QoS（Quality of Service），大部分译为 “服务质量等级”，又译作“服务质量保证”，是作用在Pod 上的一个配置，服务质量等级是通过配置CPU/MEM的limits 与requests 值的大小来确认的，可以是以下等级之一：

• Guaranteed：request=limit

• Burstable：request<limit

• BestEffort：容器必须没有任何内存或者CPU 的限制或请求。

Pod的Qos优先级排名：Guaranteed > Burstable > Best-Effort，即Best-Effort等级的Pod在Node资源紧缺时将会最先被驱逐。