1.前言

近年，云原生技术得到了快速发展和广泛应用，兴盛优选云原生团队及时拥抱变化，基于云原生实现了多云平台(简称：星斗云)，做了很多业务场景落地的实践，并帮助公司实现了非常不错的降本增效，本文将重点将星斗云遇到的大大小小问题与挑战，及对应优雅解决方案一并呈现给大家。

2.背景

随着业务方容器化改造越来越深入，星斗云将多套集群做了合并管理，集群的规模变得非常大，遇到的问题也越来越棘手，其中我们以降本增效为导向，聚焦收敛后，整理了一些代表性问题，如下：

图示说明：

1.残退复用：公司运转多年，存在不少老旧机器、待退役机器或三无组装机，如何通过“法力无边”的云原生技术纳管复用？

2.稳定保障：星斗云除了支持无状态业务部署外，还为业务提供了非常多的有状态组件（如：ceph、kafka、es、hbase、rocketmq、redis等）部署管理，因上面提到的老旧残退机器时不时会出现故障，引起响应的有状态服务大受影响，故亟需做好稳定性保障？

3.耗用管控：业务做容器化改造期间，暂未限制预算与使用，业务服务部署时，资源耗用鲜少评估，也无限制，造成大手大脚，如何管控？

4.资源挖掘：资源利用再利用，公司总希望每一分成本都花在刀刃上，采购一台机器几十万，如何尽可能深入挖掘，高效利用？

5.闲置回收：业务每天开发、测试发版成千上万次，每天生成很多增量镜像，需对镜像仓库老旧镜像清理；另外，部分业务或组件缩容后，PV/PVC许久未用，怎么回收？如何自动智能，一劳永逸？

针对上述各类问题，我们做了深刻地思考和实践性的解决方案，且听娓娓道来。

3.实践

3.1 node超卖

node资源超卖是当前业界通用的资源挖掘方式，通过超卖技术，实现每个node尽可能多的运行服务，提高资源利用率，最大限度的挖掘机器的性能，目前星斗云基于160核1T配置的Dell物理母机，实现了800%的超卖率，为实现降本做出了非常大的共享。

3.1.1 超卖方案

流程说明：

1.kubelet通过apiserver上报node资源信息。

2.上报请求达到apiserver后，对上报请求做认证和鉴权。

3.认证鉴权通过后，将通过validating 和 mutating验证，在mutating阶段将会调用我们webhook server，做资源信息改写。

4.资源改写后，经apiserver落入etcd，实现超卖管理。

核心原理主要是实现一个webhook server，通过mutating webhook劫持node上报的资源信息，然后按指定的系数改写后落入etcd，供后续scheduler调度使用。

3.1.2 超卖方式

针对不同场景，我们实现了两种超卖方式：固定比例和指定系数。

固定比例：内存不超卖，将cpu按mem/cpu的设置比例超卖，如：母机原配置mem 1T内存、cpu 160核，默认比例为6，若我们设置超卖比例为4，则node可用调度资源调整为1T、250核，反之，若设置超卖比例为8，低于实际母机配置，则不超卖。

指定系数：cpu和mem设置指定的系数进行超卖，默认系数均为1即不超卖，且低于1的设置无效，如：母机原配置mem 1T内存、cpu 160核，设置cpu超卖系数为2.0，mem超卖系数为1.2，则超卖出的cpu为320核，mem为1.2T内存。

3.2 自定义HPA

3.2.1 原生HPA

原生的HPA已经比较强大了，能实现多指标、冷却窗口等能力，但在具体业务场景实践中还是稍有欠缺，具体问题如下：

• 无用耗时：每15秒的计算周期，无法满足超大突发场景下秒级甚至ms级响应需求。
• 缺少并发：从队列里获取多个HPA对象，处理完一个再轮到下一个，若同一时刻，业务请求导致微服务调用链上下游均高负载，缺少并发处理能力，无法满足场景需求。
• 指标滞后：通过获取metrics，prometheus周期性抓取、聚合再做计算，每一个流程都是耗时，时效已经偏低，无法做到实时响应，对于电商突发性高负载，太滞后。
• 事件驱动：原生HPA都是事后的处理，即流量突发已成事实，缺少对事前预警性的场景满足，需要类似于KEDA一样的被动感知或事件驱动。
• 零副本：原生HPA暂未支持零副本能力，对于离线计算业务，场景需求明确。

3.2.2 SophonHPA

经过长期需求对接和充分的业界方案调研发现，目前暂无符合我们应用场景的开源HPA方案，故我们重新设计了SophonHPA，方案架构图如下：

图示架构说明：

SophonHPA为Operator，支持自定义CRD以controller方式实现HPA逻辑，同时兼容原生能力。

SophonHPA将HPA拆分为控制面（controller）和执行体（executor），相互独立运行，以保持架构的稳定性及容灾能力，即使其中某个挂掉，HPA功能继续运作，不会造成大面积瘫痪。

controller多副本，支持选举，主要实现针对CRD的Reconcile逻辑，作为控制管理，一旦发现新增CR，创建一个robot实现针对指定workload的HPA专属护航。

robot即executor主要负责每个CR指定workload的HPA实现，以独立pod方式运行，即1个CR会生成1个executor pod，该executor通过直接调用度量系统API获取实时指标或通过apiserver的api service方式获取缓存指标，来判断触发HPA逻辑，过程和原生类似，支持冷却窗口，支持多指标综合等能力。

为尽可能保证实时性，指标获取方式拓展支持实时拉取prometheus或其他自定义监控系统指标，以抽象接口方式实现，executor通过不断循环拉取的方式，保证指标的实时更新，实现弹性伸缩的实时感知与触发。

图示流程说明：

1.用户设置customize-HPA即SophonHPA，生成CR并下发。

2.CR通过apiserver写入etcd。

3.operator监听到CR新增事件，触发Reconcile逻辑。

4.用户每新增部署一个CR，新建一个robot即executor，以pod方式运行，跟随用户CR指定workload，一对一保障其HPA能力。

5.executor以聚合指标接口的方式，从不同的后端获取指标。

6.executor内的Calculator通过获取的指标，根据指定的策略，决策是否做弹性伸缩。

7.executor内的Calculator计算达到触发条件，触发弹性伸缩。

8.executor内的scaler执行对指定workload的弹性伸缩，并通过实现冷却窗口和控制扩缩步伐，保证扩缩节奏。

9.executor内的scaler执行完扩缩后，将状态同步记录到CR中。

3.3 优先级管理

业务有重点、非重点之分，有在线、离线之别，我们对于业务做了细分差异处理，即分级管理。

3.3.1 业务分级

业务按重要程度从高到低依次分为P0-P5共6个等级：

P0：绝对核心业务、公司级平台服务，如：电商、物流等核心业务，ceph存储，网关等

P1：核心支撑系统，如：能效平台、星斗云组件等

P2：重要业务、集群核心组件，如：prometheus，日志平台、镜像仓库等

P3：测试通用通用中间件，非核心通用业务，如：redis、kafka、hbase等

P4：开发测试业务

P5：离线计算业务

3.3.2 QOS策略

我们针对不同级别的业务，会做不同级别的QOS策略保障及资源管控，其中不同的级别对应不同的QOS策略即（Guaranteed、Burstable、BestEffort）：

1.P0：绝对核心业务，QOS为Guarranteed模式，即request和limits的cpu、memory都一样，示例：

a.pod需求评估是4核8G，实际部署时，request和limits都设置成4核8G，即：

2.P1：memory不允许弹性，cpu弹性范围为实际cpu需求的1/2~2倍，QOS为Burstable模式，即request和limits下mem一样，limits的cpu为requests的1-16倍，示例如下：

a.pod需求评估是4核8G，实际部署时，request的cpu、memory设置成2核8G，limits设置为8核8G，即：

3.P2：memory不允许弹性，cpu弹性范围为实际cpu需求的1/4~4倍，QOS为Burstable模式，即request和limits下mem一样，limits的cpu为requests的1-16倍，示例如下：

a.pod需求评估是4核8G，实际部署时，request的cpu、memory设置成1核8G，limits设置为16核8G，即：

4.P3：memory不允许弹性，cpu弹性范围为实际cpu需求的1/4~8倍，QOS为Burstable模式，示例如下：

a.pod需求评估是4核8G，实际部署时，request的cpu、memory设置成1核8G，limits设置为32核8G，即：

5.P4：cpu、memory均允许弹性，memory弹性范围为实际的1/2~2倍，cpu弹性范围为实际cpu的1/4~8倍，QOS为Burstable模式，即request和limits下mem一样，limits的cpu为requests的1-16倍，示例如下：

a.pod需求评估是4核8G，实际部署时，request的cpu、memory设置成1核8G，limits设置为16核16G，即：

6.P5：cpu、memory均不设置，默认BestEffort模式，随时可以销毁回收同node超卖实现机制一样，通过mutating webhook server劫持用户部署的workload，改写resource配置，从而实现不同等级的QOS管控，并做到了较大程度的资源复用，提高了整体负载弹性。

3.4 重点加固

服务器有好、坏之异，业务有绝对核心，要求不可中断，作为平台方，务必重点保障核心业务稳定性，同时尽可能做到容灾高可用，降低风险：

3.4.1 Taint & Toleration

对重点母机打Taint方式，只允许带对应Toleration的pod调度到该机器，保障该母机容量同时，避免其他非核心服务的过度占用，以致相互干扰。

3.4.2 亲和性

对于重点业务服务，我们会通过设置Node Selector和Node Affinity，设置到指定node的调度亲和性，使其能调度到性能更佳、配置更好的母机上去，保证其稳定可靠运行。

3.4.3 打散

核心组件都会做分布式打散部署，常用如：Redis、Kafka、RocketMq、Hbase等，当然还有很多核心业务，也会根据需求做同样的配置管理，打散主要通过反亲和性的方式实现。

3.4.4 抢占

业务做了分级管理，高优先级的业务，必须高优先级保障，通过设置抢占策略，可以对pod部署调度过程做出绝对保障，当资源紧张或某些机器异常时，可以优先保证高优先级的业务服务运行。

3.5 在离线混布

计算资源的深度挖掘，除了超卖以外，就是混布，超卖有其场景限制，超卖容易导致母机整体负载过高，影响业务服务的稳定性，在、离线则不一样，在利用率波谷期，可以完美搭配在线业务体系，实现业务空窗期资源利用填谷的效果，业界共识当然，方向有了，实践效果就取决于管理系统的优劣了，好的离线业务调度管理系统，可以高效的实现离线计算服务高峰下线、低谷运行的目标，基于此我们从以下三个点做了思考、设计及实践。

3.5.1 分级管理

在已有的分级策略中，离线计算业务默认按最低等级P6部署，即Best Effort模式，随时可以中断，在常规场景中，离线计算业务作为最低优先级的服务，混布过程中，即使影响到现网业务，遇到异常情况也会最先被处理，比如：内存占用过多，该类型服务会先触发oom，资源抢占情况下，最先驱逐的也是该类服务，所以分级QOS策略能帮我们实现影响收敛。

3.5.2 CronHPA

有了业务分级QOS管理体系后，我们再通过构建CronHPA的能力，实现定期调度部署任务能力，兴盛业务有明显的高峰、低谷期，周期性很强，夜间电商业务成交冻结，资源都浪费了，我们的离线作业系统，完全可以通过CronHPA的方式，定时扩缩容，如：晚上11:00开始拉起离线作业任务，早上7:00停掉。

3.5.3 调度系统

CronHPA的效果还是相对太大佬粗，一点也不柔和，对过程中的异常处理也不及时，无法根据实时情况，做出响应策略，比如：某台母机突发异常，负载过高，影响在线业务服务响应，就需要有对应的管理系统感知，并停掉对应node上的离线计算服务，此时，一套更全面的离线业务调度管理系统即应运而生。

图示说明：

离线计算作业调度系统共分两套核心流程，图中分别用橙色和蓝色流程给出。

图示橙色流程为支持作业的调度发布及状态同步管理，负责离线计算业务的定时或实时调度、部署、回收等管理，以及运行过程中的作业状态管理。

图示蓝色流程为动态调谐流程，负责服务运行中感知周边系统状态，如：node负载、业务预警、集群巡检异常通知等信息，通过感知这些信息，动态调整运行中的作业，将作业pod做迁移、伸缩，或规避指定node等操作，保障现网业务稳定。

3.6 智能清理

存储资源的回收管理，通过自动化、智能化的方式实现，达成成本管控目标前提下，做到非人工参与。

3.6.1 镜像仓库

业务每天发布几千次，各种镜像数据，如果缺少合理的清理策略，时间久了多大的空间都会被打满，容易导致镜像上传失败或下载效率低harbor镜像仓库支持设置清理策略，并自动执行，但实践中，无论我们怎么设置，如：保留每个镜像最近20个版本、保留最近1个月的镜像，都无法满足需求，经常会出现策略不合理，使得现网在运行服务镜像被清理，导致该服务pod异常重建或扩容时失败，引起事故，所以我们花了很大精力思考如何做到精准清理，实现一劳永逸，最终经过多番探讨和论证，提出了如下方案：

3.6.2 持久存储

业务经常会扩缩容，部分业务会使用持久存储，经常缩容后残留很多pv未清理，基于此我们会考虑如何做好清理，并且关键是不能把业务在用或待用的清理掉，以免导致数据丢失，引起业务故障，清理很简单，但要做到顾全周到，就有很多细节需要把控。

3.7 配额管理

业务总是觉得自己的服务很重要，需要足够资源保证使用，所以经常会分配过多的资源，导致占用膨胀以致浪费，我们会对其使用的计算资源做合理管控，管控策略即限额和弹性，流程包括实时统计、限额预警和弹性借调。

3.7.1 实时统计

集群中会运行一套Controller用于计算实时资源消耗情况，并按小时为周期做流水记录和统计，统计单位为CPU“核小时”或内存“G小时”，配额也是同样的单位，比如：A业务部署了多个实例，累计共10核20G配置使用，每隔1小时，会计算生成20核*小时的消耗流水记录，并落入到数据库。

3.7.2 限额预警

实时流水生成后，星斗云会根据流水记录做统计计算，并与业务配额做比对，按指定条件触发预警，如：当业务资源使用达配额60%时，发送邮件预警，当达到80%时企业微信告警，当达到90%时短信告警，超过100%时电话告警。

图示说明：

1.Report Generater从数据库获取数据统计，并计算是否达到预警限额。

2.Report Generater将触发指定的预警发送到消息队列。

3.Report Pusher从消息队列消费，按指定等级推送预警信息。

3.7.3 弹性借调

顾名思义，弹性借调即根据业务的使用情况动态调整其预算额度，部分业务因持续增长，会导致配额吃紧，相反，部分业务可能因预算评估过高，导致配额冗余，或不同业务波峰波谷错开，可以配额互惠，具体实践则是对指定业务打标，然后按业务树，由下往上借调，如：

1.业务树结构为A->B->C，A是一级业务，B为二级业务，C是三级业务。

2.将C标记为核心业务，可做配额借调，若C的配额耗尽，则会从C上层业务B的范围做借调，即二级业务B下属的可用额度，借调到C业务上。

3.若二级业务B范围内额度不够，则继续往上借调。

4.若A范围内也不够，则告警通知增加配额。

4.展望

通过以上述技术实践，我们沉淀了很多经验和能力，在往后的降本增效路上，还会有更多的云原生技术方向延伸，比如：通过ebpf、NUMA调度等机器性能挖掘技术，及大数据、AI等云原生技术结合方向探索，实现更好地降本增效技术落地，帮助业务更快发展受限于业务形态及发展规模，当前我们在离线混布、大数据、人工智能等云原生技术结合方向尚浅，后续随着业务的持续发展，我们将会投入更多相关实践，期望在高性能计算方向沉淀出更多技术结晶。

5.总结

兴盛优选当前业务稳健发展，为了迎接未来可能会大规模业务增长，我们做了很多技术实践和探索，为未来即将到来的挑战做好准备，希望借助云原生技术的东风，助力业务更好的发展，本文着重将过程中以降本增效为方向的沉淀做了整理归纳，其中涉及超卖、调度、弹性、管控等多方面技术点，希望可以通过此次分享，帮助业界伙伴们提供一些思路和方法参考。