共计 3242 个字符，预计需要花费 9 分钟才能阅读完成。
背景
作业帮的服务端技术体系正向着云原生化倒退，晋升资源利用率是云原生技术栈的外围指标之一，资源利用率的晋升意味着以更少的计算节点用承载更多的利用实例，极大的升高资源开销。而 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 虚构节点上。这样就能够即没有容量危险也能够取得老本劣势。
业界应用虚构节点的演进过程：
- 虚构节点和规范节点是齐全离开的，只能调度到指定的池子。
- 用户不必指定 selector，当 pod 因固定节点资源有余调度 pending 的时候，会主动调度到虚构节点上，该过程会有提早。
- 云厂商比方（阿里云 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 了。
规模和收益
目前计划曾经成熟，高峰期已有近万核规模的外围链路在线业务运行在基于阿里云 ACK+ECI 的 Kubernetes Serverless 虚构节点。随着业务的放量，将来运行在 Serverless 虚构节点上的服务规模会进一步扩充，将节俭大量的资源老本。
点击 此处，疾速理解阿里云容器服务 ACK 弹性调度计划详情！
本篇转载自「作业帮技术团队」，更多相干技术实际分享可返回该公众号进行查阅。
