作者：vivo 互联网服务器团队 - Chen Han

容器平台针对业务资源申请值偏大的运营问题，通过静态超卖和动态超卖两种技术方案，使业务资源申请值趋于合理化，提高平台资源装箱率和资源利用率。

一、背景

在Kubernetes中，容器申请资源有request和limit概念来描述资源请求的最小值和最大值。

• requests值在容器调度时会结合节点的资源容量(capacity)进行匹配选择节点。
• limits表示容器在节点运行时可以使用的资源上限，当尝试超用资源时，CPU会被约束(throttled)，内存会终止(oom-kill)。

总体而言，在调度的时候requests比较重要，在运行时limits比较重要。在实际使用时，容器资源规格 request 和 limit 的设置规格也一直都让Kubernetes的用户饱受困扰：

• 对业务运维人员：希望预留相当数量的资源冗余来应对上下游链路的负载波动，保障线上应用的稳定性。
• 对平台人员：集群的资源装箱率高，节点利用率低，存在大量的空闲资源无法调度，造成算力浪费。

二、现状

2.1 vivo容器平台介绍

vivo容器平台基于Kubernetes技术对内部业务提供容器服务。内部业务统一在CICD平台部署和管理容器资源，容器平台自研的caas-openapi组件提供restful接口与CICD交互。

平台通过标签，从资源维度逻辑上可以分为测试池、共享池、专有池、混部池。

• 测试池：为业务部署容器测试，一般非现网业务，为业务测试提供便利。
• 共享池：为业务不感知物理机，类似公有云全托管容器服务。
• 专有池：为业务独享物理机，类似公有云半托管容器服务，业务方独占资源，容器平台维护。
• 混部池：为业务独享物理机，在专有池基础上，混部离线业务，缓解离线资源缺口，提升整机利用率。

2.2 资源部署现状和问题

vivo容器平台的所有在线业务部署均要求设置request和limit，且request <= limit，默认情况request等于limit。在共享池中，常见业务request设置会出现如下情况：