网页视频下载安卓,长沙优化网站技术厂家,wordpress固定链接404,网络营销策划书的范文简介#xff1a;目前方案已经成熟#xff0c;高峰期已有近万核规模的核心链路在线业务运行在基于阿里云 ACKECI 的 Kubernetes Serverless 虚拟节点。随着业务的放量#xff0c;未来运行在 Serverless 虚拟节点上的服务规模会进一步扩大#xff0c;将节省大量的资源成本。 …简介目前方案已经成熟高峰期已有近万核规模的核心链路在线业务运行在基于阿里云 ACKECI 的 Kubernetes Serverless 虚拟节点。随着业务的放量未来运行在 Serverless 虚拟节点上的服务规模会进一步扩大将节省大量的资源成本。
背景
作业帮的服务端技术体系正向着云原生化发展提升资源利用率是云原生技术栈的核心目标之一资源利用率的提升意味着以更少的计算节点用承载更多的应用实例极大的降低资源开销。而 Serverless 具有弹性伸缩、强隔离性、按量计费、运维自动化等特点带来了降低交付时间、降低风险、降低基础设施成本、降低人力成本等核心优势。Serverless 化一直是作业帮基础架构探索的核心方向。Serverless 化长期来看有两种方案一种是函数计算一种是 Kubernetes Serverless 虚拟节点。Kubernetes Serverless 虚拟节点对已经运行在 Kubernetes 上的服务无实际使用差异用户体验较好业务服务使用无感知可以由基础架构进行调度迁移阿里云 ECI 就是一种典型 Kubernetes 虚拟节点方案。
所以在 2020 年我们就开始尝试将部分密集计算调度到 Serverless 虚拟节点上用 Serverless 虚拟节点底层服务器的强隔离能力来规避服务间相互影响2021 年我们就将定时任务调度到 Serverless 虚拟节点替代节点扩缩容应对短期运行任务提升资源利用率降低成本2022 年我们开始将核心在线业务调度到 Serverless 虚拟节点而在线业务是最敏感、用户易感知的。同时在线业务有着明显的波峰和波谷在高峰期弹性调度到 Serverless 虚拟节点将带来巨大的成本收益随之而来的要求也越高尽可能保证在线业务在性能、稳定性上和物理服务器效果一致业务观测感知上一致也就是让上层业务服务感知不到 Serverless 虚拟节点和物理服务器之间的差异。
Kubernetes Serverless 虚拟节点
虚拟节点并不是真实的节点而是一种调度能力支持将标准 Kubernetes 集群中的 pod 调度到集群服务器节点之外的资源中。部署在虚拟节点上的 pod 具备裸金属服务器一致的安全隔离性、网络隔离性、网络连通性又具有无需预留资源按量计费的特性。 Kubernetes Serverless 虚拟节点 成本优势
作业帮的大部分服务都已经完成容器化在线业务有着典型的高峰期且高峰期持续时间较短4 个小时/每天全部使用裸金属服务器高峰期服务器平均负载接近 60%而低峰期负载只有 10% 左右。此场景就非常适合 Serverless 的弹性伸缩落地可以做一个简单的计算假设全部使用自有服务器每小时的成本为 C平均每天高峰期的时间为 4 小时使用 Serverless 的单位时间成本为 1.5C那么
全部使用自有服务器的总成本为 C * 24 24C保留 70% 的自有服务器高峰期增加 30% 的 Serverless 来应对此时的总成为C * 24 * 0.7 1.5C * 4 * 0.3 18.6C
理论上高峰期波峰部分使用 Serverless 可降低的成本为(24C - 18.6C) / 24C 22.5% 可见将在线服务高峰期弹性调度到 Serverless 可以节省大量的资源成本。
问题和解决方案
虽然 Kubernetes Serverless 虚拟节点拥有诸多优点但也仍存在一些问题目前主要遇到以下一些问题
调度和管控问题
调度层面主要解决两个问题一是扩容时创建 pod 基于何种调度策略调度到虚拟节点二是缩容时应优先缩虚拟节点上的 pod。这两种能力在我们当前使用的 Kubernetes 版本中能力是不足的。
扩容/缩容调度策略
扩容调度策略应该由基础架构和运维来统一把控与业务关联度不大因为业务方不知道底层资源层还有多少服务器计算资源可以被利用。我们理想情况下是希望当本集群池内物理服务器资源达到利用率瓶颈后扩容到 Serverless 虚拟节点上。这样就可以即没有容量风险也可以获得成本优势。
业界使用虚拟节点的演进过程
1. 虚拟节点和标准节点是完全分开的只能调度到指定的池子。
2. 用户不用指定 selector当 pod 因固定节点资源不足调度 pending 的时候会自动调度到虚拟节点上该过程会有延迟。
3. 云厂商比如阿里云 ACK Pro的调度器会当资源不足时自动调度到虚拟节点上这个过程自动且无延迟相对比较理想。
但我们的业务场景需要更精细化的资源管理策略需要我们更紧密结合资源管理述求的调度策略所以我们基于阿里云 ACK 的能力之上研发了我们自己的方案
扩容基于在线服务的波峰波谷进行预测推荐调度预测高峰该服务能在集群物理机上运行的副本数阈值通过自研调度器将超过阈值的 pod 调度到虚拟节点上。该阈值数据即集群物理机上运行副本的最优解既能满足物理机集群的利用率也能满足性能要求。阈值太低则物理机资源浪费阈值太高则物理机部署密度太高资源利用率过高影响业务。
缩容缩容时优先缩 Serverless 虚拟节点上的 pod 很好理解因为常备的资源池是包年包月的单价更低虚拟节点上的资源是按量计费的单价较高优先缩虚拟节点上的 pod 来达到成本最优我们通过自研调度器对虚拟节点上的 pod 注入自定义的注解修改 kube-controller-manager 的缩容逻辑将带有虚拟节点自定义注解的 pod 置于缩容队列的顶部来完成优先缩容虚拟节点上的 pod。
在管控面 DevOps 平台除了支持自动计算调度到虚拟节点的阈值还支持手动设置以便于业务进行更精细的调控。调度到虚拟节点的能力可以结合 hpa、cron-hpa 同时使用来满足业务更灵活的需求。管控面还支持故障场景下一键封锁虚拟节点以及应对更极端情况如机房整体故障的多云调度能力。
观测性问题
我们的观测服务都是自建比如日志检索、监控报警、分布式追踪。因为是虚拟节点pod 里跑的监控组件日志采集是由云厂商内置的。我们需要保证业务感知层面上pod 运行在 Serverless 虚拟节点和物理服务器上一致所有就有一个转化到我们自有观测服务的一个过程。
监控在监控方面云厂商虚拟节点完全兼容 kubelet 监控接口可以无缝接入 Prometheus。完成 pod 实时 CPU/内存/磁盘/网络流量等监控做到了和普通节点上的 pod 一致。
日志在日志采集方面通过 CRD 配置日志采集将日志发送到统一的 Kafka。通过我们自研了日志消费服务消费各云厂商和自有节点上的日志。
分布式追踪在分布式追踪方面由于无法部署 daemonset 形式的 jeager agent我们 jeager client 端做了改造通过环境变量识别 pod 运行的环境如果是在虚拟节点上则跳过 jeager agent直接将分布式追踪的数据推送到 jeager colletror。
性能、稳定性及其他问题
Serverless 虚拟节点底层性能差异由于底层计算资源规格的不同以及虚拟化层带来的开销性能可能和裸金属服务器有所差异这就需要对时延非常敏感的业务在上虚拟节点之前进行充分的测试和评估。
云服务器库存风险高峰期大量扩容如果云厂商某个规格的的资源池水位低可能会扩不出来指定规格的资源。这里我们是开启自动升配也就是申请 2c2G理论上应该匹配 2c2G 的 ECI如果没有库存会匹配到 2c4G 的 ECI。以此类推。
问题定位排查因为虚拟节点本质上使用的是云厂商资源池不在我们自身的管控范围内当业务出现异常时虽然可以自动摘流但无法登陆到机器排查问题比如像查看系统日志、取回 core dump 文件等操作就比较困难。在我们的建议下云服务阿里云 ECI已经支持将 core dump 自动上传到 oss了。
规模和收益
目前方案已经成熟高峰期已有近万核规模的核心链路在线业务运行在基于阿里云 ACKECI 的 Kubernetes Serverless 虚拟节点。随着业务的放量未来运行在 Serverless 虚拟节点上的服务规模会进一步扩大将节省大量的资源成本。 原文链接
本文为阿里云原创内容未经允许不得转载。
