项目背景

a19（网易CC）容器集群应用的CPU资源利用率在50%以内，无法被其他工作负载利用的CPU核心高达2000多核

• requests设置过高，requests和实际使用之间的差值无法被其他工作负载利用，出现宿主资源利用率不高但业务需要扩容的情况，造成资源浪费
• requests设置过低，容器CPU利用率过高可能导致业务延时，内存利用率过高可能会导致OOM

项目场景以及算法解决方案

Web场景（微服务）：

Request = P99/Util
Limit = max（Request,Max）*(1+扩大系数)
 

项目成果

Web业务逻辑集成到平台的效果参考腾讯云：

宿主单价：CC项目通过grafana报表分析，帮助业务将总requests从6724C降到了4231C，避免了语音审核业务扩容需要申请额外宿主的情况，约节省了65台【( 6724-4231)/38，1台40核机器有38核可以给业务用】40核物理机，按S1系列宿主538.53元/月台计算，至少节省：65x538.53~=3.25万元/月。

在完成容器服务requests配置优化后省下的资源提供给语音审核服务使用：该服务一共扩容600个pod，单pod cpu配置为request 1核，limit 4核，而该服务可以跑满cpu，因此相当于使用了600*4=2400个核。

AB游戏服场景

可用资源 = 宿主机资源 - K8s调度消耗资源（无法避免）
Request = avg（可用资源*1/3，可用资源*1/2）
Limit = 可用资源-Bmax/冗余值

平台主界面展示

能看到项目架构以及有多少个指标需要修改

点击展开，获取Pod实例详情

可以看到具体宿主机下面哪个pod的指标需要修改，修改的建议值是多少
以及宿主机的资源使用情况是否健康

项目难点：采集数据频率

解决措施：跨过周维护日采集告警