vivo 容器平台资源运营实践
我要评论
一、容器背景
在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交互 。
平台通过标签，从资源维度逻辑上可以分为测试池 、共享池 、专有池 、混部池 。
测试池：为业务部署容器测试 ，一般非现网业务 ，为业务测试提供便利。共享池 ：为业务不感知物理机 ，类似公有云全托管容器服务 。专有池 ：为业务独享物理机 ，类似公有云半托管容器服务 ，业务方独占资源 ，容器平台维护。混部池 ：为业务独享物理机 ，香港云服务器在专有池基础上 ，混部离线业务 ，缓解离线资源缺口，提升整机利用率 。
vivo容器平台的所有在线业务部署均要求设置request和limit ，且request <= limit ，默认情况request等于limit 。在共享池中，常见业务request设置会出现如下情况 ：
（1） 较少情况 ，业务设置较低的 request 值 ，而实际使用资源远大于它的 request 值 ，若大量pod调度一个节点 ，加剧节点热点问题影响同节点其他业务 。建站模板
（2）大多情况 ，业务按最大资源需求设置较高的 request 值，而实际使用资源长期远小于它的 request 值 。业务侧账单成本高(按request计费) ，且容器异常退出时 ，重调度时可能因为平台空闲资源碎片 ，导致大规格容器无法调度 。这会导致 ，平台侧可调度资源少 ，但平台整体节点资源利用率偏低 。
对平台和用户方 ，request值设置合理很重要 ，但平台无法直接判断用户设置request值合理性 ，所以无法首次部署时硬限制 。免费模板
图片
2.3.1 request怎么样才是合理设置
request值接近业务实际使用量，例如用户申请request为2核 ，limit为4核，实际真实使用量最多1核 ，那么合理request值设置为1核附近 。但是业务真实使用量只有运行一段时间后才能评估 ，属于后验知识 。
2.3.2 保障资源最大使用量
不修改limit值就能保障业务最大使用量符合业务预期。
三 、解决方案探索
3.1 静态超卖方案思路 ：
静态超卖方案是将CICD用户申请规格的request按一定比例降低 ，根据平台运营经验设置不同集群不同机房不同环境的静态系数 ，高防服务器由caas-openapi组件自动修改 。如下图 ：
优点 ：
首次部署时可以应用 ，实现简单 。
缺点 ：
生产环境系数设置保守 ，导致request依然偏大 ，且由于内存是不可压缩资源 ，实际实施时为避免业务实例内存oom-kill ，静态超卖只开启了cpu维度，未开启内存静态超卖 。
3.2 动态超卖方案3.2.1 方案思路
开发caas-recommender组件，基于业务监控数据的真实资源用量来修正业务request值 。
从监控组件拉取各个容器资源的真实使用量 。通过算法模型得到业务申请量的推荐值 。业务重新部署时 ，使用推荐值修改业务request值 。3.2.2 半衰期滑动窗口模型
结合容器业务的特点 ，对推荐算法有如下要求：
当workload负载上升时 ，结果需要快速响应变化 ，即越新的数据对算法模型的影响越大；当workload负载下降时 ，结果需要推迟体现，即越旧的数据对算法结果的影响越小 。半衰期滑动窗口模型可以根据数据的时效性对其权重进行衰减 ，可以满足上述要求 。
详细描述参考 ：google Borg Autopilot的moving window模型，参看原论文>>
公式如下 ：
图片
其中 τ 为数据样本的时间点 ，t1/2 为半衰期 ，表示每经过 t1/2 时间间隔 ，前一个 t1/2 时间窗口内数据样本的权重就降低一半 。
核心理念：在参考时间点之前的数据点 ，离的越远权重越低 。在参考时间点之后的数据点权重越高 。
半衰期halfLife：经过时间halfLife后 ，权重值降低到一半 。默认的halfLife为24小时 。
数据点的时间timestamp：监控数据的时间戳 。
参考时间referenceTimestamp ：监控数据上的某个时间（一般是监控时间最近的零点00:00） 。
衰减系数decayFactor ：2^((timestamp-referenceTimestamp)/halfLife)
cpu资源的固定权重 ：CPU 使用量数据对应的固定权重是基于容器 CPU request 值确定的 。当 CPU request 增加时 ，对应的固定权重也随之增加，旧的样本数据固定权重将相对减少。
memory资源的固定权重 ：由于内存为不可压缩资源，而内存使用量样本对应的固定权重系数为1.0 。
数据点权重 = 固定权重*衰减系数
例如现在的数据点的权重为1 ，那么24小时之前的监控数据点的权重为0.5，48小时前的数据点的权重为0.25，48小时后的数据权重为4 。
3.2.3 指数直方图计算推荐值
caas-recommender每个扫描周期（默认1min）从 metrics server 或 prometheus 中获取带时间戳的样本数据 ，如 container 维度的 CPU 、Memory 资源使用等 。样本数据结合权重值 ，为每个workload构建指数直方图，指数直方图中每个桶的大小以指数速率逐步提升 。指数直方图的样本存储方式也便于定期checkpoint保存 ，可以显著提升程序recover性能。如下图 ：
比如CPU波动较大且可压缩，采用95%分位值（P95） ，内存采用99%分位值（P99） 。最终得到workload的资源推荐值 。
3.2.4 caas-recommender组件流程图
1. 启动controller ：profile Controller监听profile template crd ，根据profile crd创建相应维度的recommendation crd，可支持namepace\
workload\pod维度 。
2. 初始化：
判断是否有checkpoint ，若无 ，可以选择从prometheus拉取数据构建直方图 。若有，由checkpoint直接recover 。
3. loop循环：
从recommendation crd中判断哪些pod需要纳管（pod labels）根据pod label从Kubernetes获取pod信息根据pod的namespace从metrics server拉取监控数据 ，由container数据汇聚成pod用量数据 。构建指数直方图，填充pod用量数据和权重值 。根据直方图的分位值计算推荐值存储推荐值和直方图chekpointgc需要删除的recommendation crd或者直方图内存等无用数据 。4.支持原生workload常用类型 ，拓展支持了OpenKruise相关workload类型。
3.2.5 推荐值校正规则
推荐值 = 模型推荐值 * 扩大倍数(可配置) 推荐值 < 原生request值 ：按照推荐值修改推荐值 > 原始request值: 按照原始request修改内存是否修改可以通过配置不修改workload的limit值3.3 HPA利用率计算逻辑改造Pod 水平自动扩缩（Horizontal Pod Autoscaler, 简称 HPA）可以基于 CPU/MEM 利用率自动扩缩workload的Pod数量 ，也可以基于其他应程序提供的自定义度量指标来执行自动扩缩 。
原生Kubernetes的HPA扩缩容利用率计算方式是基于request值 。若资源超卖，request值被修改后 ，那么业务设置的HPA失灵 ，导致容器不符合预期扩缩容 。
关于HPA是基于request还是基于limit ，目前Kubernetes社区还存在争论 ，相关 issue 见72811 。若需要使用limit计算利用率 ，可以修改kube-controller-manager源码 ，或者使用自定义指标来代替 。
vivo容器平台兼容业务物理机利用率逻辑 ，规定内部统一监控系统的Pod利用率均基于limit计算 。
HPA改造思路 ：通过修改kube-controller-manager源码方式实现基于limit维度计算 。
在pod annotation中记录设置值信息（request值和limit值） ，以及维度信息（request或limit维度） 。controller计算pod资源时 ，判断是否有指定annotation ，若有 ，解析annotation记录值和维度信息计算利用率，若无 ，使用原生逻辑 。通过上述方式解耦HPA与pod request值 ，这样平台的资源超卖功能修改request不影响HPA自动扩缩预期 。
3.4 专有池支持超卖能力专有池物理机由业务自行运维管理 ，从平台角度，不应该随意修改业务的容器request规格 。但是专有池业务也有降低容器规格 ，部署更多业务 ，复用资源 ，提高整机利用率的需求 。平台默认所有共享池自动开启超卖能力 ，专有池可配置选择开启超卖能力 。
可自定义开启超卖类型 ：静态、动态 、静态+动态 。可自定义静态系数 、动态超卖扩大系数。可配置是否自动修改超卖值 ，当不自动生效可通过接口查询推荐值 ，由业务自行修改 。3.5 整体方案首次部署 ：
根据先验知识评估 ，通过固定静态系数修改request值，再根据部署后各个pod监控用量数据，生成workload的request推荐值 。
再次部署 ：
若有推荐值 ，使用推荐值部署。无推荐值或者推荐值未生效时，使用静态系数 。
四 、效果和收益
4.1 测试集群收益
原测试机器的静态超卖系数很低 ，且只缩减cpu维度资源 ，导致集群内存成为资源瓶颈 。
开启动态超卖能力4个月后 ，纳管90%的workload ，节点pod平均内存request由4.07Gi下降到3.1Gi ，内存平台装箱率降低10% ，有效缓解集群内存不足问题 。
4.2 共享池生产集群收益
图片
原生产集群静态超卖系数较高 ，CPU资源装箱率高，导致集群的CPU成为瓶颈 。
开启动态超卖能力3个月后 ，纳管60%的workload，节点pod平均cpu request由2.86降低为2.35，整体cpu利用率相比未开启前提升8%左右 。
五 、总结与展望
vivo容器平台通过资源超卖方案，将业务容器的request降低到合理值，降低业务使用成本 ，缓解了集群资源不足问题 ，达到了提升节点利用率目的 。但是当前仅在生产集群开启了CPU资源超卖 ，规划近期开启内存资源超卖 。
未来基于上述方法，可以纳管更多维度 ，比如GPU卡利用率再结合GPU虚拟化能力 ，从而提高GPU资源共享效率 。根据动态超卖推荐值可以用于构建用户画像，区分业务是计算型或内存型 ，方便平台更好理解用户特性 ，辅助资源调度等。
相关文章
将网络安全集成到组织的目标和风险中，如此重要有两个原因。首先，网络安全会影响组织的各个方面。因此，为了正确管理网络安全，必须被整合到组织风险管理和决策中。例如：运营风险可能会受到网络安全的支持，因为依2025-12-07
CloudSEK的XVigil平台近期调查发现，一起针对甲骨文云Oracle Cloud）的网络攻击导致600万条记录被窃取，可能影响超过14万名租户。据报道，一名名为“rose87168”的威胁行为2025-12-07
Windows Defender成攻击者的利器，可禁用EDR
据Cyber Security News消息，安全专家发现了一种复杂的攻击技术，能利用 Windows Defender 应用程序控制 (WDAC) 来禁用 Windows 设备上的端点检测和响应 (2025-12-07
勒索软件已发展成为全球组织面临的最严峻威胁之一，2025年将迎来一个复杂性和破坏性并存的新时代。攻击者不再是单打独斗的黑客，而是装备AI工具的精密犯罪集团和国家行为体，他们利用零日漏洞zero-day2025-12-07
为了直观体现代码审计思想，对漏洞情景进行了简化。一，安全标准不一致一门新的编程语言，作为后端处理程序，肯定是需要与中间件/数据库等其他模块相联系的，如果它们对待请求的安全标准不同，就可能导致安全问题。2025-12-07
Palo Alto Networks近日披露，其下一代防火墙中的PAN-OS软件存在一个高危漏洞，编号为CVE-2024-3393。该漏洞允许未经身份验证的攻击者通过发送精心构造2025-12-07
最新评论