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交互。

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

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

2.2 资源部署现状和问题

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

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

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