作业帮在线业务 Kubernetes Serverless 虚拟节点大规模应用实践

阅读 3月前 0 28

布景

作业帮的服务端技能系统正向着云原生化发展，提升资源运用率是云原生技能栈的中心方针之一，资源运用率的提升意味着以更少的核算节点用承载更多的应用实例，极大的下降资源开支。而 Serverless 具有弹性弹性、强阻隔性、按量计费、运维主动化等特色，带来了下降交付时间、下降风险、下降根底设施本钱、下降人力本钱等中心优势。Serverless 化一直是作业帮根底架构探究的中心方向。Serverless 化长时间来看有两种计划，一种是函数核算，一种是 Kubernetes Serverless 虚拟节点。Kubernetes Serverless 虚拟节点对现已运转在 Kubernetes 上的服务无实际运用差异，用户体验较好，事务服务运用无感知，能够由根底架构进行调度迁移，阿里云 ECI 便是一种典型 Kubernetes 虚拟节点计划。

所以在 2020 年，咱们就开端尝试将部分密集核算调度到 Serverless 虚拟节点上，用 Serverless 虚拟节点底层服务器的强阻隔才能来躲避服务间相互影响；2021 年，咱们就将定时使命调度到 Serverless 虚拟节点，替代节点扩缩容，应对短期运转使命，提升资源运用率下降本钱；2022 年，咱们开端将中心在线事务调度到 Serverless 虚拟节点，而在线事务是最灵敏、用户易感知的。一起在线事务有着显着的波峰和波谷，在顶峰期弹性调度到 Serverless 虚拟节点将带来巨大的本钱收益，随之而来的要求也越高，尽可能确保在线事务在功能、稳定性上和物理服务器作用共同，事务观测感知上共同，也便是让上层事务服务感知不到 Serverless 虚拟节点和物理服务器之间的差异。

Kubernetes Serverless 虚拟节点

虚拟节点并不是真实的节点，而是一种调度才能，支撑将规范 Kubernetes 集群中的 pod 调度到集群服务器节点之外的资源中。布置在虚拟节点上的 pod 具有裸金属服务器共同的安全阻隔性、网络阻隔性、网络连通性，又具有无需预留资源，按量计费的特性。

KubernetesServerless 虚拟节点本钱优势

作业帮的大部分服务都现已完结容器化，在线事务有着典型的顶峰期，且顶峰期持续时间较短（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了。