腾小云导读
2022 年 10 月，腾讯自研事务产品全面完结云原生上云。自研事务产品云上规划已打破 5000w CPU，凭借云原生的技能优势，全面提高了腾讯自研事务产品的运营功率，在此进程中咱们也对腾讯云产品进行了打磨和验证。无论是在事务场景、安稳性要求、运维功率等多个方面，大规划容器化进程中都面对不少的技能应战。本篇将进行共享，希望能够给广大开发爱好者带来灵感。
看目录，点收藏
1项目布景
1.1腾讯自研事务产品云原生上云进程简介
1.2腾讯有状况服务的共性
2 腾讯大规划事务容器化面对的几个应战
2.1 容器快速晋级
2.2 容器原地热晋级
2.3 面向事务产品的大局快速扩缩容
2.4对运用屏蔽多样的底层机型，提高资源池利用率
2.5 从面向集群到面向运用的调度编列
3 总结
腾讯自研事务产品历经三年，包括 QQ、微信、王者荣耀、腾讯会议等亿级用户规划的事务产品，都已全面上云。自研事务产品云上的资源规划已打破 5000 万核，打造了国内最大规划的云原生实践典范。各位读者点这儿进入页面，右边扫码重视腾讯云开发者大众号，回复「云原生」可下载鹅厂7w字大规划云原生技能实践事例集、腾讯云技能实践精选文集。
在这个进程中，腾讯做了许多的技能优化和打破，包括优化 K8s 集群、大局的资源办理调度，完结了 65%的 CPU 利用率、提高容器运用链路上各层的安稳性等等。
3 年时刻，腾讯终究达成了全面云原生上云的方针。在容器运用办理上，有几个事情十分要害：
-
最前期需求云原生理念的布道。让一切事务产品”认识“到云原生上云所带来的事务价值。几年前，腾讯内部的 K8s Oteam 联合腾讯书院推出了榜首个面向全公司的 K8s 系列课程。
-
供给易用性和安稳性的容器办理渠道。这处理不同的事务场景容器化上云的痛点并沉积了产品的才能，让一切腾讯事务产品都真实感受到云原生上云的价值。
-
资源调度编列才能。底层海量的资源规划，需求打造极好的资源调度编列才能，提高大局的资源利用率，从集团层面达成上云后的降本增效目的。
-
度量机制。「各个事务产品云原生上云做的怎样样」需求有一套度量机制。例如腾讯的云原生成熟度模型，有用协助各个事务提高了事务产品的云原生成熟度。
下面将主要介绍开发进程中咱们遇到的部分技能应战和处理计划，各位将能看到咱们在此进程中是怎样一步步去夯实产品才能的。
01、项目布景
1.1 腾讯自研事务产品云原生上云进程简介
腾讯自研事务产品容器化上云始终以腾讯云产品为底座，整个进程分为两个阶段，云原生上云 1.0 和 2.0 阶段。2022 年前主要是 1.0 阶段，技能中心在「离线混部、在线混部」场景中，事务产品的容器化形态主要阅历了富容器和微容器 2 个形态。
经过大规划自研事务产品的容器化，团队沉积了各种事务场景下容器化上云的最佳实践计划和产品所需的才能，例如容器调度（单集群和多集群）、弹性弹性、有状况服务容器化、大规划资源办理、安稳性提高、事务运维功率提高等。
上云阶段不仅仅是把事务产品容器化上云，更重要的是要给事务产品带来实际的价值。**这儿有腾讯云原生的成熟度规矩，来查核腾讯自研事务产品和其对应的容器渠道。**主要从四个维度查核：
最大的权重维度是资源利用率，指事务产品容器利用率、渠道资源利用率。还有弹性弹性才能、容器可调度才能以及申请的 Pod 资源是不是小中心的资源。经过这些中心指标来规范和评估事务产品云原生上云的进程和作用。
1.2腾讯有状况服务的共性
|
这些事务产品特性使其在 TKE 办理上面对巨大应战，既要尽量兼容这些事务产品特性，也要坚持其运用镜像发布和晋级的云原生准则。TKEx 运用办理渠道笼统出了这些特性背后的需求，研发了多集群统一灰度发布、多地域多集群作业负载办理、面向运用的多集群协同扩缩容、容器快速晋级、容器热晋级等通用的渠道才能。
02、腾讯大规划事务容器化面对的几个应战
2.1 容器快速晋级
针对「运用 IPC 同享内存，或许有超 GB 的有状况本地数据，晋级时不能丢掉，而且只允许 ms 级的用户无感知颤动」这个事务产品特性，TKEx 运用办理渠道开发团队规划研发了使容器快速晋级的产品才能，供给像进程重启相同的 ms 级事务颤动体会，这也是腾讯会议容器化上云很有应战性的点。
容器原地晋级，也是一种针对有状况服务进行晋级的有用手段。完结在 Pod 不重建的状况下，Pod 内某个 Container 进行重建，坚持了 IPC 同享内存，本地有状况数据不丢掉。可是原地晋级进程中，虽然容器网络和存储不再需求重新分配和挂载，可是仍然需求 ReCreate Container，就会存在 Image Pull 和 Container 销毁和发动的进程。
因而原地晋级的整个流程耗费时刻一定是秒级的，这会形成服务的秒级不可用。结合 ReadinessGateway 能做到按需增加/除掉路由，完结进程中恳求无损。可是用户的有状况数据是在本地的，恳求外表无损，而实际上用户对应的长链接服务已经无法正常供给服务了。这会导致会议秒级中止，是不可行的。
Pod 里有 3 个要害容器，它们的责任分别如下:
| 容器 |
责任 |
| biz-sidecar: Sidercar | 容器责任很简略，供给“ Pod 是否在晋级中”的状况维护。经过 Readiness Probe 比较 EmptyDir Volume 中的事务发布版别文件 version1 和 version2 的内容是否持平，持平则 Ready，不然 notReady。 |
| biz-container | 容器发动脚本会将环境变量（预注入）里的一个版别号写到 versionX 文件中，然后开端循环等候文件锁，假如成功获取文件锁则发动事务进程。文件锁是避免 Pod 内一起运转多个版别，是事务 Container 的要害，用文件锁来做不同版别容器的互斥，能够完结事务新旧主进程的 ms 级切换。 |
| biz-pause | 这是一个占位容器，容器的发动脚本会将环境变量里的一个版别号写到 versionX 文件里，然后就进入无限 sleep 状况。当事务需求晋级时，它就会经过原地晋级的方法切换到 biz-container 的角色。 |
接下来，此处咱们以事务从版别 V1 晋级到版别 V2 为例，阐述晋级流程。
|
值得注意的是，原生 K8s apiserver 允许修正 Pod 的 image 等，不支撑修正 resource 以及环境变量等，所以该计划需求修正 K8s apiserver 的相关代码。别的为了确保 Pod request 资源以及其 Pod qos 不变，StatefulSetPlus-Operator 在晋级时需求对各阶段容器进行 Resource 调整。
最后，依据这个技能原理，咱们封装成 TKEx 运用办理渠道所需才能的产品，供给简略好用的操作体会。用户按规矩编译好镜像后，只需晋级时勾选「快速晋级」，即可完结整个进程。
经过占位容器、状况机 Sidecar 容器、原地晋级、同享 volume、文件锁机制，完结容器晋级时事务进程的快速切换。
坚持镜像发布的云原生体会，完结方法完全是 K8s 原生，回绝把容器当虚拟机运用。
2.2容器原地热晋级
部分模块发布需求坚持同享内存数据不变，而且事务自身要有热重启才能，容器化怎样供给事务热晋级的才能？ 是云直播等事务模块能否顺利容器化的要害。针对 「部分模块的开发结构支撑热晋级，需求在容器晋级时支撑原地热晋级」这一事务诉求，TKEx 运用办理渠道依据 Kubernetes 原地晋级、同享 volume、Probe 和占位容器的要害技能，完结并完结了原生的事务容器原地热晋级的技能计划和渠道才能。
计划阐明：
|
其间，占位容器担任将事务新版别镜像中的新版别事务 bin 复制到同享 volume。事务容器 watch 同享 volume 中相关内容的改变，并能够进行进程 reload 热晋级。
而事务容器的探针 Readiness 要担任感知原地热晋级的状况，然后支撑原地热晋级的时候仍然能进行容器流量办理。但实际上，由于原地热晋级一般是 ms 级的，一般没有必要去在这 ms 级时刻范围内做路由的除掉和增加。
此进程中，需始终坚持以镜像发布的云原生体会，完结方法完全 k8s 原生，回绝把容器当作虚拟机用的方法去做事务进程晋级。遗憾的是现在还没有将这些技能原理封装成渠道才能，所以事务要做原地热晋级的常识门槛仍然较高。
2.3 面向事务产品的大局快速扩缩容
因接入需求和容灾、多活的需求，有些头部事务产品海内外多地域布置单个模块最多的实例数超过 1 万。整个产品的 Workload 万级，散布在上百个集群，和其类似的自研事务产品其实不少。这种事务产品有一个特色，一般对一段时刻的「PCU（一起最大在线人数）」的预估来提早进行扩缩容的决议计划。
例如当时事务产品的 PCU 是 2kw, 需求扩容到 3kw，中心链路上的大部分模块都需求在当时规划的根底上扩容 50%。在如此杂乱的事务散布拓扑中，要提早进行大规划扩缩容会面对许多困难：
|
为此，渠道进行了依据事务自建拓扑的大局快速扩缩容产品才能建造，经过使命的形式办理大局扩缩容，中心才能如下：
榜首，用户挑选一批跨事务、跨集群的 Workload，组成一个大局的事务拓扑 Set，作为事务产品维度的扩缩容使命规划的对象，设置大局扩缩容参数，完结扩缩容下发动作。当时支撑「依据步长」和「依据等份额」两种扩缩容战略，支撑装备 HPA 的 Workload 和未装备 HPA 的 Workload 的提早大局扩缩容。这儿有 2 种状况：
|
第二， 在装备好大局扩容后，资源概览页支撑依照「核算资源」、「IP 资源」、「配额」三个维度展现资源需求、资源库存和详细资源缺口等数据，方便按需补充对应资源。
第三，依据事务大盘视图展现的整个扩缩容使命的一切 Workload 和 Pod 实时状况信息，能够快速找出异常 Pod（状况异常、实时利用率异常），快速掌握全体事务服务扩缩容状况。
第四，供给事务产品的大局 Workload 扩缩容状况视图。支撑依照事务、集群、地域等维度聚合检查整个扩缩容使命中一切 Workload 的扩缩容进展，并有完整的 Workload 列表页展现各 Workload 运转中副本数量、方针副本数量、库存副本数和异常信息。
计划阐明： 在 TKEx 运用办理渠道中，依据 Clusternet 构建的多集群办理计划，事务产品大局快速扩缩容的中心组件 Global Scaler Operator布置在 Clusternet Hub Cluster 中，用户在渠道前端构建生成 ScalerJob CR 后，会主动生成ScalerTemplate。
Global Scaler Operator 中心办理着 2 个 CRD，分别是前面提到的扩缩容使命 ScalerJob 和扩缩容模板 ScalerTemplate 。
| CRD |
解析 |
ScalerJob |
界说大局扩缩容装备，并关联扩缩容模板 ScalerTemplate，为整个大局扩缩容供给按指定战略触发运转、回滚、终止等中心才能的界说和状况办理。 |
|
ScalerTemplate |
定义要扩缩容的 Workloads 对象及其 Scale 参数，也供给大局扩缩容回滚模板的才能。 |
大局快速扩缩容战略：前面提了 2 个事务产品大局扩缩容战略，这儿举个比如做简略阐明。假定事务产品X有 3 个 Workload，散布在广州、上海、北京，副本数分别是10, 20, 30，当时支撑的 PCU 是 10w，需求新增扩容支撑 5w PCU。
| 战略 | 解析 |
| 依据步长战略 |
当事务产品X每增加 1w PCU 时，Workload A 要增加 2 个副本，Workload B 要增加 4 个副本，Workload C 要增加 5 个副本，这便是每个 Workload 独自的步长。事务产品X扩容 5w PCU，依据 1W PCU 的步长，扩容系数便是 5 倍，就意味着 Workload A 要新增 2*5=10 个副本，以此类推。
 |
| 依据等份额扩容战略 |
当时事务产品 X 的 PCU 是 10w，需求新增 5w PCU, 中心链路的模块都要等份额扩容 50%， 则一切 Workload 的副本数在当时根底上都要扩容 50%，扩容系数便是 1.5。
 |
2.4 对运用屏蔽多样的底层机型，提高资源池利用率
底层运用的资源有各代的老旧机型，也有新代机型。怎样让事务能无差异的运用这些资源，是提高整个资源池利用率必需求处理的问题。例如 Application X 的实例散布在北上广 3 个地域，调度在多个集群中运用了腾讯云 S3、S4、S5、S6 多种机型资源。假如不做各个实例的路由权重上的差异化处理，那么必定会呈现每个实例的负载不一致。这就简略呈现老旧代机型高负载，新代机型低负载的状况。而且平均负载并不高，不能触发原生 HPA，然后导致事务服务质量呈现下降。
假如运用的服务路由系统具备「依据实例负载或许自界说指标动态调整服务权重」的才能，这一问题将得到大幅缓解。
为了处理这个问题，现在有 2 个处理计划，分别运用在不同的事务场景中：
【计划1】
|
引入机型族的概念。依据核算、存储、网络等方面的要害功能指标，构建综合性模型，将功能接近的机型放入同一个机型族（普通功能机型族、高功能机型族、指定机型），然后大幅收敛原本露出给用户的底层机型。调度上确保同一个 Workload 都运用一个机型族，终究使得各个事务实例在恳求量一致的状况下负载根本均衡。这样事务的平均负载就与各个实例的负载方差很小，HPA 也能正常作业，以确保事务的服务质量。 这种计划主要适用于批量核算型事务，也适用于事务对机型功能有一定要求的事务，或许有必要指定某个详细机型的通用核算场景，可是或许会面对一些资源调度上的危险，例如事务指定机型或机型族的资源缺乏等问题。这个计划本质上是在缓解这类对资源有功能要求的事务问题。机型族运用越多，该计划对提高底层各种好差料的作用就越好。
|
【计划2】
|
将底层算力规范化、产品化。渠道将底层的一切机型算力都依照预设的模型折算到规范算力，渠道从底层资源池中按需调度算力组合成事务需求的规范算力需求。运用在布置和扩缩容时需求的资源，都以规范算力为单位，不用再重视任何机型信息。 例如，运用X需求在广州任意 2 个可用区等份额算力布置，共需求 32c*200g*(c* 表明规范 cpu 单位，g* 表明规范内存单位)。假定底层资源池中一共有 3 种机型，机型 A 的算力为规范算力的 50%，机型 B 的算力为规范算力的200%，机型 C 的算力正好是规范算力，则运用X或许的布置拓扑如下。
|
这儿还有一个重要的作业，便是需求依据各种底层组合的机型的算力，动态调整对应的服务路由权重。因而 TKEx 运用办理渠道联合北极星 Polaris，将各个机型的算力动态折算成路由权重动，完结了依据机型算力的事务大局动态路由权重才能，终究使得同一个 Workload 下不同机型的负载根本坚持平衡。
2.5 从面向集群到面向运用的调度编列
前几年咱们更多重视的是怎样给用户供给直接面向 K8s 集群的事务办理才能。在小规划事务场景下，这种方法没有痛点。但随着事务规划的增加，这儿的事务办理痛点就逐渐露出。用户要感知底层许多的可用区和集群，对应许多的 Workload、ConfigMap、Service、Ingress 对象的办理。因而这儿要转换思路，由面向集群到面向运用的调度编列，这意味着用户不用再重视集群，不用重视底层资源，不用重视每个集群中的 K8s 对象办理，只需重视运用本身。
举个比如，某个事务产品在全网有上万个 Workloads 和 Pods ，散布在全球十几个地域、近百个集群。要对这个事务某个模块做一次全网晋级改变，依照以前面向集群的方法完结功率较低，当然凭借上层 的 DevOps 流水线能够提高一些功率。所以要笼统出面向运用的办理才能，简化事务产品在布置、扩缩容、晋级改变、装备办理、流量办理、事务看板等方面的操作体会和功率。
要完结这一方针，中心的底层才能建造就在多集群编列调度上，能够依据Clusternet 的多集群办理才能来完结。例如，运用想布置同城多活的场景，TKEx 运用办理渠道直接供给这种布置战略，不用去指定 Region 去找适宜的集群独自布置，直接指定 Region 后，Clusternet 动态拆分调度器 i ，主动依据集群容量、方位拓扑等信息来做调度决议计划，挑选适宜的集群并做好最佳的副本散布决议计划。
再例如，装备运用弹性弹性时，不需求再面向集群装备 HPA。会有一个大局的多集群 HPA Coordinator Controller 做多集群 HPA 协同，能够依据集群容量、集群的可用性做 HPA 参数的动态调整和协同，确保事务扩容时不会由于某个集群的资源缺乏无法扩容，会主动在其他可用集群中扩容。
还有许多重要事务场景，需求在多集群编列中处理。例如面向运用灰度晋级时，运用对应的 Workloads 散布在底层多个集群中，怎样做很多集群的运用灰度发布？ConfigMap 的多集群灰度发布也是相同的道理。别的，给用户供给的大盘视图、监控告警才能等等都不再是面向集群维度的，而是面向运用的多集群聚合维度的。
03、总结
腾讯具有国内最大规划的云原生实践事例，进程中许多的技能和产品才能服务了许多事务场景，包括音视频、游戏、电子商务、社交、工作协同、出行等。咱们正在将这儿积累的各种事务场景的最佳实践经验，例如运用的规范化检测、事务的 QoS 界说、运用多集群灰度发布、运用多集群自愈等等，都输出到云原生运用办理渠道这个公有云产品中。
用相同的运用办理渠道一起服务好腾讯内部和外部客户，与开发者们一起迈入云原生 2.0 年代。以上是本次共享全部内容，欢迎咱们在[大众号]（点这儿进入开发者社区，右边扫码即可进入大众号）谈论区共享交流。假如觉得内容有用，欢迎共享转发～
-End-
原创作者｜王涛
技能责编｜王涛
你怎样看待云原生？云原生未来的发展趋势是什么？ 欢迎在[大众号]（点这儿进入开发者社区，右边扫码即可进入大众号）谈论区评论。咱们将选取1则最有构思的共享，送出腾讯云开发者-文化衫1个（见下图）。5月17日中午12点开奖。
点这儿进入页面，右边扫码重视腾讯云开发者大众号，回复「云原生」检查鹅厂离线学习包：
7w字腾讯大规划云原生技能实践事例集
腾讯云技能实践精选集
阅览原文
