哈啰云原生架构落地实践

罗涛 2024-03-11 11:13:00

 

一、弹性伸缩技术实践

 

 
 
 
1.全网容器化后一线研发的使用问题

 

图片

 

全网容器化后一线研发会面临一系列使用问题,包括时机、容量、效率和成本问题,弹性伸缩是云原生容器化后的必然技术选择。

 

 
2.使用原生弹性HPA遇到的问题

 

图片

 

当时第一时间考虑用原生HPA组件,但在实际调研和小规模使用的时候发现了很多问题。一方面是内置的问题,如原生不支持自定义指标和定时扩缩容,使用率计算基于resources.requests,使用单个Goroutine执行。更大的痛点在业务场景上,微服务在线实例拉出状态,特殊业务Job任务实例不能中断,要考虑下游DB层可用性。

 

 
3.基于业务实例实际水位、有效负载的弹性能力

 

图片

 

我们基于业务实例实际水位、有效负载构建弹性能力。

 

  • 高低双阈值控制,像一些有浮动的业务,可以尽量把底层的稳定性去做有效的约束;

  • 最大可用原则,扩容用Ceil向上取整,缩容使用Floor向下取整;

  • 数据降噪,去除实例状态不ready的,去除强业务关系的实例计算,应用启动毛刺问题缓解,metrics空值、获取不到值;

  • 性能增强,按业务namespace监听,实现并发度控制。

 

 
4.水位阈值弹性和定时弹性的融合实现

 

图片

 

这里同时做了水位阈值弹性和定时弹性的融合,保证单个的应用能够同时使用阈值和定时弹性。基本原则是扩容时大者取大,缩容时不能低于定时副本数。

 

 
5.业务使用弹性后的生产效果

 

图片

 

业务使用弹性后产生了一定的效果,如图是高低阈值和定时的区间。这里解决了一些问题:

 

  • 代码预热,在高峰前准备就绪;

  • 周期性波动型应用变更明显减少;

  • 应用冗余减少,业务“初见原型”;

  • 突发流量应对,稳定性提升;

  • 告警、应用状态可控性。

 

最终弹性接入90%以上,扩缩容消息触达率100%,业务可用算力增加了 30%以上。

 

 
6.混合云模式下的 ClusterAutoScale

 

图片

 

集群可用资源变多,不等于整体开支降低,因此我们考虑去做混合云模式下的ClusterAutoScale。这里有一些关注点,包括镜像即服务、CloudProvider 适配、节点初始化和节点回收。

 

图片

 

右图是基本流程,有两个触发策略,一是基于不可调度事件,二是基于资源池水位阈值。这里我们也解决了一些问题,包括 CloudProvider 对接私有云资源API,Pod网段分配域路由宣告,私有云可用容量评估及资源打散,以及资源灰度回收逻辑。

 

 
7.注意事项

 

图片

 

在实际业务时生产使用的时候,有很多关注点,包括业务池的容量、应用维度的实例波动率标准、存活探测和就绪探测的接口区别、指标阈值和弹性规则的合理性巡检、不做过多filter、不强依赖其他系统平台。

 

二、中间件容器化及混部填谷

 

 
1.业务独立池水位与混部预期

 

图片

 

针对业务特性,将redis和flink资源池进行融合,达到分时复用的效果。之前的形态会带来很多问题:

 

  • 每种业务独占一个资源池或集群,产生大量资源碎片,造成成本浪费;

  • 多个集群多个对外API,数据需要多次聚合计算;

  • 各业务池服务器规格不一致,运维管理复杂。

 

 
2.混部的总体思路

 

图片

 

混部里面这里做了一些思考,考虑了应用分级、资源需求、潮汐分布等等。将这些因子抽象归纳,分为应用分级、混部调度、资源QOS三层。我们也确定了几个总体方向,包括服务资源保障的策略实现和资源分配决策的算法实现。

 

图片

 

在服务资源保障上,主要是对应用分级打标。我们把所有的业务做了S1-S4的分级,并落到了CMDB里,最终落到K8S的优先级标签里面。第二部分是资源池化,优先去考虑以底层的业务为重保,把一些优先级较低的应用分别打散到各个资源池。

 

图片

 

在资源分配决策上, 第一部分是Request推荐。主要基于VPA Histogram计算百分位算法,通过获取7x24小时周期的应用资源量,根据P95百分位数据,再乘以水位系数放大后得到最终推荐值,并结合弹性、coolhealth状态机优化毛刺问题。

 


 

第二部分是实际负载调度,主要基于集群理想值权重算法和BinPacking装箱打分算法。过滤掉高水位节点,避免单node资源打爆;水位偏离度缩小,pod调度尽可能靠近理想水位;历史阈值计算应用负载,对节点未来水位预测;兼顾单node最大pod数限制。

 

图片

 

第三部分是资源打散,通过问题推导,完全打散是不可能的,我们希望尽可能打散,在私有云IDC加入MDU策略。常用的策略有宿主机打散、可用区打散和MDU打散。

 

 
3.成效和问题

 

最终资源使用率有明显提高,成本账单同比持续降低。这里也带来了一个无法回避的问题:物理机宕机。爆炸半径增大,稳定性怎么保障,是我们基础设施的同学都需要去思考的问题。二是对根因下钻和故障定位带来挑战,如何观测和评估影响。

 

三、K8S观测与稳定性

 

 
1.基于Prometheus的容器监控平台

 

图片

 

基于Prometheus构建了监控体系,核心组件包括Thanos + Prometheus 持久化存储、Vertex Exporter 指标采集数据源、SentryD 配置管理、CheckD 告警检测和Alerts 告警系统。

 

 
2.监控高级模式

 

图片

 

我们自研了vertex采集工具,实现了快速生成metrics指标的能力,支持用户自定义指标名称,方便按业务、按分组区分。和exporter算力共享,每个实例 limit 2C/4G就可满足一个物理机的采集任务。

 

 
3.event 事件流持久化

 

图片

 

实现了事件收集器,K8S全资源类型listwatch收集,同时把所有的event全量打印,针对特别的一些探针做了Response信息返回的打印。

 

 
4.logs 日志平台

 

图片

 

系统日志和业务日志等通过一些消费和采集的收集器,推送到kafka,最终聚合成一个平台。

 

 
5.trace链路

 

图片

 

我们通过traceid查询,tags过滤进行数据检索分析;链路拓扑过滤,只看有错误的链路;采样链路搜索,链路分析。

 

 
6.K8S稳定性关注的指标

 

图片

 

这里把K8S稳定性关注的指标分为五类,原生组件可用性、集群容量水位、集群资源负载、业务异常实例和云平台可用性。

 

 
7.稳定性大盘

 

图片

 

云原生系统内维护的组件系统较多,一个原子管理单元发生问题后可能会影响多个上游链路系统。快速论证回答组件域当前是否正常,对于故障分析、问题定位有重要意义。

 

四、未来的展望规划

 

未来规划主要分为四部分,一是在离线的深度混部与调优,下一阶段还要持续推进哈啰内部云化中间件的混部进程,聚焦大算力应用的资源编排和成本优化。

 

二是数据存储容器化,数据库、NoSQL的容器化工作,基于容器Cgroup隔离、以及类K8S资源编排模型的落地。目前哈啰内部已有部分业务开始生产化,还在持续建设中。

 

三是Serverless业务场景模式探索,中后台的算法模型、数据任务job场景有一定的实践,业务大前端BFF层、无代码工程建设上在持续探索。

 

四是基于AIOPS&可观测性的智能故障预测,基于时序预测模型能力,探索metrics异常指标提前发现,收敛告警系统误报、漏报问题,提升故障发现、故障定位能力。

 
作者丨罗涛
来源丨公众号:哈啰技术(ID:gh_426073316492)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告