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

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

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

  （1） 较少情况，业务设置较低的 request 值，而实际使用资源远大于它的 request 值，若大量pod调度一个节点，加剧节点热点问题影响同节点其他业务。

  （2）大多情况，业务按最大资源需求设置较高的 request 值，而实际使用资源长期远小于它的 request 值。业务侧账单成本高(按request计费)，且容器异常退出时，重调度时可能因为平台空闲资源碎片，导致大规格容器无法调度。这会导致，平台侧可调度资源少，但平台整体节点资源利用率偏低。

  对平台和用户方，request值设置合理很重要，但平台无法直接判断用户设置request值合理性，所以没办法首次部署时硬限制。

  request值接近业务实际使用量，例如用户申请request为2核，limit为4核，实际线核，那么合理request值设置为1核附近。但是业务真实使用量只有运行一段时间后才能评估，属于后验知识。

  静态超卖方案是将CICD用户申请规格的request按特殊的比例降低，根据平台运营经验设置不同集群不同机房不同环境的静态系数，由caas-openapi组件自动修改。如下图：

  生产环境系数设置保守，导致request依然偏大，且由于内存是不可压缩资源，实际实施时为避免业务实例内存oom-kill，静态超卖只开启了cpu维度，未开启内存静态超卖。

  开发caas-recommender组件，基于业务监控数据的真实资源用量来修正业务request值。

  半衰期滑动窗口模型能够准确的通过数据的时效性对其权重进行衰减，能够完全满足上述要求。

  其中τ为数据样本的时间点，t1/2 为半衰期，表示每经过 t1/2 时间间隔，前一个 t1/2 时间窗口内数据样本的权重就降低一半。

  核心理念：在参考时间点之前的数据点，离的越远权重越低。在参考时间点之后的数据点权重越高。

  参考时间referenceTimestamp：监控数据上的某个时间（一般是监控时间最近的零点00:00）。

  cpu资源的固定权重：CPU 使用量数据对应的固定权重是基于容器 CPU request 值确定的。当 CPU request 增加时，对应的固定权重也随之增加，旧的样本数据固定权重将相对减少。

  memory资源的固定权重：由于内存为不可压缩资源，而内存使用量样本对应的固定权重系数为1.0。

  例如现在的数据点的权重为1，那么24小时之前的监控数据点的权重为0.5，48小时前的数据点的权重为0.25，48小时后的数据权重为4。

  caas-recommender每个扫描周期（默认1min）从 metrics server 或 prometheus 中获取带时间戳的样本数据，如 container 维度的 CPU、Memory 资源使用等。样本数据结合权重值，为每个workload构建指数直方图，指数直方图中每个桶的大小以指数速率逐步提升。指数直方图的样本存储方式也便于定期checkpoint保存，可以显著提升程序recover性能。如下图：

  指数直方图的横轴定义为资源量，纵轴定义为对应权重，资源量统计间隔以5%左右的幅度增加。

  桶的下标为N，桶的大小是指数增加的bucketSize=0.01*(1.05^N)，下标为0的桶的大小为0.01，容纳范围为[0,0.01)，下标为1的桶的大小为0.01*1.05^1=0.0105，容纳范围[0.01-0.0205)。[0.01,173]只需要两百个桶即可完整保存。

  计算出W(95)=95%*所有桶的总权重，如上图仅考虑前4个桶，总权重为20，w(95)权重为19。

  从最小的桶到最大桶开始累加桶的权重，这个权重记为S，当S=W(95)时候，这样一个时间段桶的下标为N，那么下标为N+1桶的最小边界值就是95百分位值，如上图N=3时，S=W(95)，95百分位值即为0.01*1.05^2。

  比如CPU波动较大且可压缩，采用95%分位值（P95），内存采用99%分位值（P99）。最终得到workload的资源推荐值。

  原生Kubernetes的HPA扩缩容利用率计算方式是基于request值。若资源超卖，request值被修改后，那么业务设置的HPA失灵，导致容器不符合预期扩缩容。

  vivo容器平台兼容业务物理机利用率逻辑，规定内部统一监控系统的Pod利用率均基于limit计算。

  通过上述方式解耦HPA与pod request值，这样平台的资源超卖功能修改request不影响HPA自动扩缩预期。

  专有池物理机由业务自行运维管理，从平台角度，不应该随意修改业务的容器request规格。但是专有池业务也有降低容器规格，部署更多业务，复用资源，提高整机利用率的需求。平台默认所有共享池自动开启超卖能力，专有池可配置选择开启超卖能力。

  根据先验知识评估，通过固定静态系数修改request值，再根据部署后各个pod监控用量数据，生成workload的request推荐值。

  原测试机器的静态超卖系数很低，且只缩减cpu维度资源，导致集群内存成为资源瓶颈。

  开启动态超卖能力4个月后，纳管90%的workload，节点pod平均内存request由4.07Gi下降到3.1Gi，内存平台装箱率降低10%，有效缓解集群内存不足问题。

  原生产集群静态超卖系数较高，CPU资源装箱率高，导致集群的CPU成为瓶颈。

  开启动态超卖能力3个月后，纳管60%的workload，节点pod平均cpu request由2.86降低为2.35，整体cpu利用率相比未开启前提升8%左右。

  vivo容器平台通过资源超卖方案，将业务容器的request降低到合理值，降低业务使用成本，缓解了集群资源不足问题，达到了提升节点利用率目的。但是当前仅在生产集群开启了CPU资源超卖，规划近期开启内存资源超卖。

  未来基于上述方法，可以纳管更多维度，比如GPU卡利用率再结合GPU虚拟化能力，来提升GPU资源共享效率。根据动态超卖推荐值能够适用于构建用户画像，区分业务是计算型或内存型，方便平台更好理解用户特性，辅助资源调度等。

  随着分发规模地逐步增长，各企业对CDN带宽的使用慢慢的变多。并且，各类业务使用CDN的场景各式各样，导致带宽会不断地出现骤增骤降等问题。基于成本考虑，国内CDN厂商的计费模式主要用峰值点的带宽来计费，就算不用峰值点的带宽，也会因为峰值问题所产生的成本而抬高带宽单价。基于此，控制CDN带宽的峰谷具备极其重大意义，降低峰值就从另一方面代表着成本节省。