关于腾讯云:降本超30智聆口语通过-TKE-注册节点实现-IDC-GPU-节点降本增效实践

背景介绍

腾讯云智聆书面语评测（Smart Oral Evaluation，SOE）是腾讯云推出的中英文语音评测产品，反对从儿童到成人全年龄笼罩的语音评测，提供单词、句子、段落、自在说等多种评测模式，从发音精准度、流畅度、残缺度等全方位打分机制，与专家打分类似度达 95% 以上，可广泛应用于中英文书面语教学场景中。

在降本增效的大环境下，业务踊跃寻求老本更优的解决方案，且因为曾经积攒了 IDC 物理机、云上虚拟机和云上 Serverless 容器服务等多套部署环境，业务架构非常臃肿，运维难度十分高，业务急需一套更加对立的计划升高零碎复杂度。

问题与挑战

产品侧的降本诉求

问题

在以后 降本增效 大环境下，如何管制产品成本成为一个越来越重要的命题，经验了两个倒退期间后，咱们不得不试着上手抽丝剥茧，尝试解决这个问题

挑战

因为业务倒退历史及业务架构起因，以后资源 buffer 较多，资源利用率较低，零碎老本居高不下，次要有以下两个问题

扩容老本十分高 – 因为自身是 AI 评测类业务，依赖大量 GPU 资源，而 GPU 机器从资源申请到交付，再到服务部署调试与流量接入，周期通常是天级的，无奈应答早晚顶峰的尖峰流量，所以须要为高峰期预留大量 buffer

资源流转效率低 – 同时业务侧存在中英文评测服务，AI 引擎是两套模型，而模型间的部署切换老本也比拟高，这也导致咱们须要预留双份的 buffer

客户侧日渐丰盛的流量模型

问题

日渐丰盛的业务场景 – 在工作日非工作日、早晚顶峰和中英文评测的多种条件组合下产生了十分多场景，通过提前备量去 cover 所有场景老本是不可行的

无奈预估的业务增量 – 局部客户的量受疫情影响十分大，且常常是不可预期的，客户本人也无奈预估评测用量会达到什么量级，这也导致咱们无奈精准地提前备量

削不掉的尖峰流量 – 局部客户存在非常明显的尖峰流量，用户会集中在晚顶峰的某几个工夫点进行评测，尖峰流量通常是平峰期的10 倍 以上，且客户依赖实时后果返回，无奈通过异步评测的形式削峰

挑战

运维难度高 – 以后架构下无奈反对业务侧高效地进行资源流转、更无奈疾速实现弹性扩容

服务质量难保障 – 引擎服务故障节点剔除依赖人工操作，无奈疾速实现故障自愈；引擎服务部署形式多样，物理机 / 虚拟机 / 容器计划并存，无奈搭建对立的可观测体系

3. 新架构

需要

资源利旧：业务侧绝大部分机器还在 IDC 物理机房，且物理机性价比高于虚拟机，上云过程中冀望能把这部分机器利用起来，升高整体老本

网络连通：云上云下服务网络需买通，且业务侧跨地区调度流量容灾的需要，引擎层须要可能被多集群接入层拜访。同时，因为不同机型不同规格的引擎层生产能力不同，至多须要反对自定义权重的动态负载平衡策略

拥抱云原生：降级零碎架构，落地混合云计划，全面拥抱云原生。云原生生态下曾经有十分多最佳实际与解决方案，业务面临的许多问题在云原生场景下都能找到很好地解法，把业务搬迁上云不是目标，上云是更高效、优雅的解决业务面临的服务扩缩容、服务故障自愈、服务可观测等问题的伎俩

选型 – TKE 注册节点集群

能力介绍

注册节点（原第三方节点）是腾讯云容器服务团队针对混合云部署场景，全新降级的节点产品状态，容许用户将非腾讯云的主机，托管到容器服务 TKE 集群，由用户提供计算资源，容器服务 TKE 负责集群生命周期治理。业务侧能够通过注册节点的个性，将 IDC 主机资源增加到 TKE 私有星散群，确保在上云过程中存量服务器资源失去无效利用，同时反对在单集群内同时调度注册节点、云上 CVM 节点及云上超级节点，便于将云下业务拓展至云上，无需引入多集群治理。

增加了注册节点的集群，可能蕴含泛滥不同网络环境的计算节点，如 IDC 网络环境和私有云 VPC 网络环境的计算节点。为了屏蔽底层不同网络环境的差别，TKE 容器团队推出了基于 Cilium Overlay 的混合云容器网络计划。实现在容器层面看到的是对立的网络立体，使得 Pod 无需感知其是运行在 IDC 的计算节点还是私有云的计算节点，加上云梯环境与内网环境本就是互通的，这也就奠定了智聆业务上云选型的根底

TKE 注册节点架构

（图自 [注册节点 - 网络模式] 官网文档：https://cloud.tencent.com/doc…)）

业务架构计划

在新架构各层部署形式较平台期期间都有了较大扭转：

1、接入层部署在超级节点上，充分利用资源弹性能力；

2、引擎层服务通过不同的 Deployment 部署在 IDC 节点、CVM 节点和超级节点上，均以 Pod 的模式对外服务，屏蔽掉部署环境的区别；

3、基于第二点移除了 Serverless 容器服务 Pod 的流量接入层，缩小一次转发，优化流量调度。

流量门路

客户流量就近接入云 API 网关后，云 API 网关通过北极星名字服务进行服务发现，实现流量就近接入业务侧 CLB。业务侧 CLB 直连贯入层 Pod，流量达到业务侧后，接入层服务再次依据名字服务通过北极星进行服务发现，获取 RS IP 后申请引擎层生产。新计划在接入层屏蔽了引擎部署环境和各资源池的区别，接入层仅通过配置去北极星获取对应 RS IP 后申请即可，升高了流量调度的复杂度

服务部署

接入层

接入层通过节点亲和性调度至超级节点部署，通过 HPA 配置利用云上弹性扩缩容能力进行削峰填谷，比照部署在 CVM 节点上的计划有以下几个劣势

1、扩缩容更不便、更灵活。若部署在 CVM 节点上须要配置 Cluster Autoscaler 应用，须要先扩容出 CVM 节点，再扩容 Pod，耗时会达到分钟级，而超级节点能够实现秒级扩容

2、老本更优。CVM 节点退出集群后须要扣除集群治理预留的局部，且集群组件自身有超 10 个 DaemonSet，也会额定再占用一部分资源，理论资源使用率显著低于超级节点

3、治理复杂度更低。不须要保护节点资源，超级节点可按需增加，依据业务状况灵便调整

引擎层

引擎层则须要充分利用 TKE 集群注册节点能力，通过节点亲和性配置别离部署在 IDC 节点、CVM 节点和超级节点上，其中 IDC 节点为利旧资源，CVM 节点为后续常备的根底资源，超级节点为弹性伸缩资源

既然后面接入层部署时讲了那么多超级节点的长处，那引擎层部署时为什么又须要 CVM 节点呢？

老本更优：引擎服务不仅依赖于 GPU 资源，对 CPU/MEM 也有高的需要，而超级节点反对的 GPU 节点规格无限，推理型 GI3X 机型绝对于 Serverless 容器服务 弹性进去的 T4 卡规格具备更强的 CPU 和更多的 CPU/MEM 配比，对于业务侧的性价比更高。

服务发现

北极星

接入层与引擎层整体均借助北极星进行服务发现，但依据接入层与引擎层需要选取了多种裸露服务的形式。

接入层

接入层通过内网 LoadBalancer 型 Service 裸露服务，北极星绑定 LB IP。业务还采纳了 LB 直连 Pod 的模式缩小 NodePort 转发，这里其实最开始没有采纳直连的模式，也是踩了个坑，后文中会提到。

引擎层

IDC 节点与 CVM 节点上的引擎容器通过 Docker Host Network 网络模式与节点共享网络堆栈，使得容器裸露端口可间接映射到节点上，故北极星间接绑定 Pod IP（也是节点 IP）即可，而超级节点上的 Pod IP 为实在的内网 IP，也能间接在北极星上绑定 Pod IP，通过这样选型能够屏蔽掉 Pod 调度到不同节点上的差别，对立上报为容器 IP。

事实上如果要实现以上成果计划是比拟多的，这里也大抵比照了下，能够依据理论状况进行抉择。业务侧刚好单个 IDC/CVM 节点仅运行一个引擎 Pod，且节点上也不会再运行其余服务，故不存在端口争用的问题，比照下来业务侧抉择了性能更优，施行也更为简洁的 hostNetwork 计划。

服务运维

灰度公布

接入层

前文中提到应用 Service 来裸露接入层服务，而 Service 通过 Label Selector 来选取 Pod，咱们能够通过两个 Deployments 来治理这组 Pod，而后通过调整 Pods 数量来调整流量比例，从而实现灰度公布的性能。

须要关注的是咱们采纳 LB 直连 Pod 的计划，这种计划下默认仅在 Pod 被删除后才会从 LB RS 中移除，为实现服务优雅停机需新增两条配置，这样在 Pod 处于 terminating 状态时就会把 CLB RS 的权重调 0，避免流量继续接入。

kind: Service
apiVersion: v1
metadata: 
  annotations: 
    service.cloud.tencent.com/direct-access: "true" ## 开启直连 Pod 模式
    service.cloud.tencent.com/enable-grace-shutdown: "true"  # 示意应用优雅停机
  name: my-service
spec: 
  selector: 
    app: MyApp

引擎层

引擎层的实现更为简略，前文中也提到引擎服务的注册与反注册是由服务本身实现的，咱们只须要与接入层一样调整两组 Deployment 的数量就能实现灰度比例控制。

服务可观测

日志

日志计划对立应用 CLS 采集，并且通过 CLS 跨地区采集的性能采集至同一个日志 topic 中进行检索剖析，简化现网日志检索复杂度。

监控

监控计划对立为云监控计划，通过云 Prometheus 采集根底指标及业务指标进行展现剖析，缩小多套监控体系学习与保护老本。

根底监控 – 云 Prometheus 接入集群监控后自带多个面板，根本合乎需要，业务侧只须要实现 GPU 数据的采集上报即可。

业务监控 – 业务侧引入 Prometheus SDK 裸露并配置 job 进行采集即可。

告警

告警计划也对立为云监控告警，借助云监控的能力笼罩邮件、企微微信、电话等多种渠道，缩小告警渠道保护老本与多套告警规定配置学习老本。

异样节点剔除

当 Pod 异样时应该及时切断流量，保障流量不会继续进到异样 pod 内导致现网服务受损，提供两种计划，经调研业务侧抉择计划二：

计划一：Liveness Probe

配置存活探针，业务健康检查异样时间接杀死 Pod，而后进入上文提到的 Pod 优雅退出流程，阻断流量进入异样 Pod。

计划二（举荐）：Readiness Probe + Readiness Gate

配置就绪探针，业务健康检查异样时将 Pod 状态置为 Not Ready，配合 ReadinessGate 机制，当检测到 Pod 状态为 Not Ready 时将相应 LB RS 权重调 0，阻断流量进入异样 Pod。

该计划的益处是可能 保留事故现场 用于 debug，便于疾速定位问题，配合云监控告警即可实现疾速感知。

调度计划

服务调度 - 动静扩缩容能力

业务侧之所以抉择自研 scheduler 服务是因为业务侧有灵便的扩缩容诉求，除了惯例的 HPA&HPC 的能力，scheduler 服务还有以下性能：

1、HPA&HPC 规定均作用于 资源池级别，原生 HPA&HPC 仅反对 Deployment/StatefulSet 级别；

2、业务侧有 资源流转 的需要，如北京地区早顶峰中文评测的量很高，而英文早顶峰绝对较低，须要反对通过调整中英文引擎 Pod 数量的形式进步资源整体利用率；

3、业务侧有 保障扩容成功率 的需要，因为业务侧须要的 GPU 资源数量较多，故须要通过切换规格和切换地区等形式进步扩容成功率。

流量调度 - 资源隔离

引擎层资源隔离借助北极星动静路由的能力实现，服务（大池子）、别名（公共池 / 各大客户专有池）和别名路由（池子划分规定）须要提前创立好。自研 scheduler 服务依据配置为引擎 Pod 打标并注入别名列表，接入层在拿到对应别名后向北极星获取 RS IP 申请即可，不须要感知流量路由到哪个池子。

前置工作

1、创立对立的北极星服务；

2、创立各资源池北极星别名；

3、在北极星服务下创立各别名路由规定，选取对应 label 的 RS。

引擎启动注册流程

1、引擎服务启动后自行注册至对立的北极星名字服务下；

2、scheduler 服务监听到存在未打 label 的 RS 则依据规定及各资源池以后负载状况进行打标，用于标记是哪个资源池；

3、scheduler 服务依据规定判断以后资源池是否失效，若失效则注入接入层拜访引擎层的别名列表。

用户申请流程

1、接入层获取别名；

2、接入层通过别名向北极星获取 RS IP；

3、接入层申请 RS IP。

获得成果

降本增效

服务扩容到流量接入耗时优化至 分钟级 ，自研 scheduler 服务联合 EKS 弹性扩容能力进行削峰填谷， 升高超 30% 零碎老本，节约 2 个运维人力

自研 scheduler 服务进行资源流转，早高峰期将闲置的英文节点资源转换为中文节点资源，缩小北京地区近 90% 早顶峰扩容需要

（上图是优化后成果，早顶峰仅扩容大量资源，下图是优化前成果，早顶峰须要扩容大量中文节点）

服务质量晋升

接入层异样节点剔除

接入层通过业务侧配置的 Readiness Probe 探测服务存活，当心跳失败时配合 ReadinessGate 机制将 CLB 中对应 RS 的流量路由权重置 0，以此实现异样节点主动剔除，保障现网服务质量

引擎层异样流量剔除

引擎层通过北极星心跳上报的模式探测服务存活，当心跳失败时北极星主动将对应 RS 状态置为异样，以此实现异样节点主动剔除，保障现网服务质量

过程遇到的问题

大集群计划未能实现

冀望

最后构想是由 一个 TKE 集群纳管所有节点（IDC 节点、云上 CVM 节点、云上超级节点），以此来简化整体服务部署，进步集群间资源流转效率，进一步升高整体计划复杂度。

问题

以后集群暂不反对绑定多地区 CLB，也暂不反对退出多地区超级节点，导致 无奈实现服务就近接入和弹性多地资源。

斗争计划

以后 单地区大集群 的计划，各地区均部署一个集群。

5.2. CVM 转发性能瓶颈

问题体现

高峰期呈现 connection reset by peer 的报错，报错比例低于 0.01%，经排查均来自某个 CLB IP。

问题成因

查看 CLB、Pod 的监控均失常，在 Pod 内部署抓包也没发现异常的握手申请，而且业务侧 LB 是内网四层 LB，以后流量应该远没有达到 LB 的性能瓶颈。

正在束手无策之际开始重头排查整条链路，发现业务尽管抉择的是 LB 型 Service，且 Pod 部署在超级节点上，然而 LB RS 却是 CVM 节点，流量还是通过 NodePort 的模式进入集群，再由 K8s 外部网络转发至对应服务 Pod，接入层 Pod 可能借助超级节点的能力弹性扩缩容，然而 CVM 节点数量却是固定的，就成为了零碎的性能瓶颈。

晓得有这么条链路之后再登录 CVM 节点验证，发现的确是 CVM 节点的连接数被打满了，导致局部连贯被回绝。

（图自容器服务官网文档）

解决方案

到这儿解决方案也十分清晰了，借助 TKE 提供的 CLB 直连 EKS Pod 的能力去掉 NodePort 转发，流量平均的打到 Serverless 容器服务 Pod 上，Serverless 容器服务 Pod 又能够弹性扩缩容，以此就解决了性能瓶颈的问题。

（图自容器服务官网文档）

总结

在不同的业务倒退阶段须要抉择适合的架构，没有完满的计划，须要随着技术迭代一直调整，固步自封只会让研发成为业务的短板。业务上云最终导向都应该是业务胜利，服务于降本增效、进步服务质量等指标，上云后业务可能背靠腾讯云，借助各云产品弱小的能力疾速实现业务需要，升高技术应用门槛。

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！